Securing Web Services with WS-Security: Demystifying WS-Security, WS-Policy, SAML, XML Signature, and XML Encryption

 <  Day Day Up  >  

Universal Description, Discovery, and Integration (UDDI) is an advertising and discovery service for Web services. UDDI was a collaborative effort of Ariba, CommerceOne, Accenture, Microsoft, IBM, and others. It has roots in Discovery of Web Services (DISCO) from Microsoft and Advertisement and Discovery of Services (ADS) from IBM. These efforts and similar ones elsewhere were coalesced into UDDI for a system of directories.

The purpose of UDDI is to register and publish Web services definitions. A UDDI repository manages information about service types and service providers and makes this information accessible through a well-defined protocol to potential Web service clients .

The UDDI specification is a format for registering a business, an API for SOAP access, and rules to operate a registry. Each service is given a unique identifier called a tModel . A tModel points to the specification that defines a resource.

You can search for a specific service in a registry through UDDI white pages, where basic identity and contact information is found. UDDI yellow pages categorize the business and services into taxonomies. Such categorization helps service consumers find a particular service that matches their requirements. The UDDI green pages provide binding details for a service. That is, they allow you to access the WSDL for the service.

UDDI can be used inside corporations as a single place to advertise and find any available services. This is the most useful role for UDDI in our view. Larger organizations that want to achieve all the benefits of reuse will find UDDI to be the best standard way to register and then search for those reusable services.

UDDI can also be used on the public Web to discover public Web services. This vision for UDDI will require the longest amount of time to take hold because Web services that are of significant value will not be free and open to any and all potential users. They will be subject to contracts, payments, liabilities ”the sorts of things that contracts and lawyers are involved with. Ultimately, this model will require automated contract negotiation and a highly secure UDDI.

Security is critical in all UDDI registries. For example, who is authorized to publish, use, and update Web service descriptions? Business relationships require trust. Without a trust relationship, you will not enter into any transactions. The authentication and authorization of publishers and inquirers and their authority to access published services must be explicitly handled by UDDI, especially when it is used on the public Internet.

UDDI attempts to deal with these issues by leveraging strong security standards used throughout XML and Web services security. It uses XML Signature to establish the identity of publishers and subscribers. Published WSDL files are signed using XML Signature as well. UDDI uses SAML to establish authorization and to provide access control for UDDI registries. To control who can see or utilize an entry, UDDI uses XML Encryption of its elements to keep them confidential.

Is There Any Real Utility to UDDI?

Of all the standard Web services vocabulary terms discussed so far, UDDI has the least immediate utility. Its most legitimate purpose is to create a class browser for WSDL schemas. However, it was conceived and is still touted as the way to build distributed registries of Web services. The question is whether you need distributed registries of Web services. Will people have their systems go out on the World Wide Web and discover services and start using them automatically?

We all lived through the overblown hype of B2B. That is when the concepts for a UDDI global business repository were born. It is not clear whether UDDI will even become an accepted standard in the first place. Is the concept even useful? It will be hard to trust the information in such a repository. The need to go out to a repository to find a service that you want to use as a Web service in an application is questionable. The way information is categorized into white pages (business name , address, contact information, DUNS number), yellow pages (type of business, location, products, industry), and green pages (business services, business process definitions, their WSDL files) is not obviously useful. Because no authenticated identity protocol exists, if knowing whose service you are actually using is important, you cannot use UDDI. The standard is so extensible with so many options that it is impossible to predict the dialect you would happen upon.

Most people don't see this scenario happening. UDDI is more likely to be used in closed but large and distributed environments. The most likely use would be within a large enterprise that is promoting sharing across all development projects within the same company. When Web services provide an API that business partners will integrate into their applications, the interfaces do not need to be discovered ; their location and much more will be specified in a negotiated contract.

When thought of as a public directory of Web services, UDDI leaves a lot to be desired, making it the least accepted of all the standards. If you need a service, as a developer, you go to places you know have services and find what you need, such as salcentral.com or xmethods.com .

As an internal ”inside the firewall ”directory of Web services, UDDI may excel. Using it may be the best way for an organization to actually achieve reuse of Web service components . Applications can be wrapped using XML integration technologies and registered with the internal UDDI. Now, when integrating internal applications, other departments can come along and discover applications that are ready to be integrated. If UDDI is to be successful, this is how we think it will happen.

UDDI is a critical enabling technology for the vision of a service-oriented architecture. The basic operations that define SOA are register, find, and bind. The process of tying SOA back to Web services is as follows : The Web service provider publishes a contract in the form of WSDL. This contract is then registered with a service broker via UDDI. A Web service consumer queries the UDDI registry broker to find the desired service, which locates directions to the WSDL contract. These directions are then used to bind the client to the service using SOAP so that the client and service can now communicate. These steps are shown in Figure 2.6.

Figure 2.6. UDDI service discovery in service-oriented architectures.

SOA is talked about now more than in any previous generation of distributed computing because Web services deliver a much better SOA than any previous architecture could deliver. The reason is that the Web services model provides something much more flexible, much more pervasive, much lighter weight and supported from any language, working with any platform, and requiring no special homogeneous software installs .

SOA has enormous security implications by having services that are shared among numerous service consumers whose data must be kept confidential from other service consumers and who might have very different trust models. SOA also has security implications due to the fact that it will drive the use of multi-hop Web services that cannot be accomplished by simple point-to-point connections. SOA takes an "outside-in" approach. In traditional RPC-style interfaces, the interfaces were data-centric. In a true SOA, the interfaces are process-centric; that means the data structures and their handling are a black box to the client. This is even more true for document-style interfaces. All this means that, for SOA to work, Web services security must be built in at the message level. As you will see, that will be the emphasis in all the Web services security discussions throughout this book.

 <  Day Day Up  >  
Related

Категории