Securing Transactions with the UDDI Services

UDDI has been widely touted by vendors and commentators as a method of automating business processes on a grand scale by enabling the automatic discovery of new business partners and the subsequent invocation of the appropriate remote services. While it’s true that UDDI does have the potential to automate business processes, trust relationships are typically developed over many years between businesses rather than by a simple search process. For example, by using the white and yellow pages, your local “agent” software may identify ten different suppliers of a set of widgets, and the green pages may identify the interfaces and data models required for the invocation process. However, if you don’t have a trust relationship with any of the vendors, how can you be assured that they will be able to deliver? While this issue is not unique to UDDI, because all new business partners need to be vetted as per normal business practices, the level of automation in identifying potential partners means that some kind of certification authority or business brokerage may need to act as an intermediary before public UDDI registries are used to the full extent.

Underlying these concerns about trust are some key security issues that need to be addressed by developers. These concerns revolve around the roles of Publishers and Inquirers, authentication of Publishers and methods for authorizing their ability to publish, and authentication of Inquirers and their ability to access published services that they know about—or services that they discover. By focusing on understanding the implicit and explicit issues surrounding authentication and authorization of UDDI users, the potential of UDDI may become more of a reality than the current hype.

Explaining the UDDI Roles

Like a telephone book, a UDDI registry defines two types of access to the data contained within the registry: an Inquirer, which can search for information but cannot update or insert records, and a Publisher, which can update or insert records. Clearly, allowing an Inquirer to update or insert records in the registry would be disastrous: competitors would be able to undermine each other’s entries to prevent potential customers (Inquirers) from reliably retrieving details of Publishers. In turn, Publishers should only be able to insert new records when authorized to do so, and should only be able to update their own records.

Publishers

UDDI Publishers are allowed to insert new records into the registry, and are allowed to update existing records that they own. In order to perform insertions or updates, Publishers must be authenticated. This requires registration at the registry site to be performed before publishing can occur. Authentication is through a simple username/password token combination. When invoking a Publisher API call, these credentials are passed to the server, requiring Secure HTTP (HTTPS) transport to ensure that the plaintext form of authentication credentials cannot be sniffed. For the IBM test registry, the Publisher API can be accessed through https://www-3.ibm.com/services/uddi/testregistry/protect/publishapi. Alternatively, authentication can be performed by some other means such as SAML or Kerberos. As we will see in the “Authenticating and Authorizing Publishers” section of this chapter, a key issue is authorizing what activities authenticated Publishers can engage in.

Inquirers

UDDI Inquirers are allowed to access the UDDI registry in a read-only form. Inquirers can search for business organization details, services offered by individual businesses, and the invocation format of those services. By default, UDDI Inquirers are not authenticated, since they are not allowed to publish data in the registry. However, this is problematic because there may be service types and registry entries that should only be available to registered users, rather than the general public. Access to the registry is usually provided by vanilla HTTP, because there is no exchange of authentication credentials. For the IBM test registry, the Inquiry API can be accessed through http://www-3.ibm.com/services/uddi/v2beta/inquiryapi.

Subscribers

Subscribers play a special inquiry role, where they are notified about specific types of insertions and updates made to a registry, including the businessEntity, businessService, bindingTemplate, tModel, and publisherAssertion entries. Subscription is based on a set of preferences that determine the extent of the subscription. Support for subscription is not a requirement for supporting UDDI v3, so you may need to check with your vendor and/or service provider that subscription is supported. Unlike a normal Inquirer, a Subscriber is generally a piece of software.

One of the key differences between a Subscriber and an Inquirer is that Subscribers must be authenticated by a registry node before their requests can be honored: the authInfo token may be used with the subscription API to transmit authentication tokens.

Subscription allows the following operations on the registry:

• Subscribers can be alerted to new businesses that are entered into the registry. This may be useful for the formation of dynamic virtual enterprises, where runtime binding of services is supported by discovery of new partners and the services they offer.

• Changes to existing services and service definitions can be monitored by service owners, and by service users. This allows service owners to be alerted to any unauthorized changes that are made to their services, and allows service users to be notified of any modifications required to continue to successfully interface with the service.

• Integration of public and private registry data is possible, because private registries can subscribe to receive updates on changes to public data, while not compromising their own security by allowing public access to their data and interfaces.

• Subsets of public registries can be maintained and updated on a subscription basis, without data having to be reloaded manually.

• Integration of data from multiple registries can be automated to a large extent, allowing specific industries and portals to reduce duplication and detect inconsistencies more quickly.

Authenticating and Authorizing Publishers

Authentication services are available to Publishers by using the get_authToken interface. Authentication is typically performed by using a simple username and password combination. To prevent the possible interception of cleartext usernames and passwords, HTTPS is always used to publish data to the registry. This provides security at the transport layer. The SOAP request looks like this:

<get_authToken cred="XYZ123" generic="2.0" user xmlns="urn:uddi-org :api_v2"/>

In this example, the username is “wattersp” and the password is “XYZ123.” The SOAP response looks like this:

<authToken xmlns="urn:uddi-org:api_v2" generic="2.0" operator="  www.ibm.com/services/uddi">     <authInfo> ...     </authInfo> </authToken>

The <authInfo> token that is returned can then be used for subsequent operations that require authentication on the server. The following messages require the Publisher to be authenticated according to the Publisher API:

• add_publisherAssertions Adds an assertion about two businesses, defined by a publisherAssertion document, to a Publisher’s set of stored assertions.

• delete_binding Removes a bindingTemplate from the registry based on the company’s UUID.

• delete_business Removes a businessEntity from the registry based on a UUID. Associated businessServices, publisherAssertions, and bindingTemplates will also be deleted.

• delete_publisherAssertions Removes publisherAssertions from the registry based on the UUID of a specific publisherAssertion.

• delete_service Deletes a specific businessService from the UDDI registry given a UUID.

• delete_tModel Prevents tModels identified by a UUID from being used, while not actually deleting them.

• discard_authToken Ends an authenticated session for the current client.

• get_assertionStatusReport Returns a report on all publisherAssertions owned by a specific businessEntity identified by a UUID.

• get_authToken Retrieves an authentication token based on a username and password.

• get_publisherAssertions Retrieves a list of publisherAssertions for a specific businessEntity.

• get_registeredInfo Retrieves the business registration and tModel data for a specific businessEntity.

• save_binding Inserts a new bindingTemplate into the registry.

• save_business Inserts a new businessEntity into the registry.

• save_service Inserts a new businessService into the registry.

• save_tModel Inserts a new tModel into the registry.

• set_publisherAssertions Inserts a new publisherAssertion into the registry.

Authenticating the Publishers

The following code sample demonstrates how Publishers are authenticated to perform restricted operations within the UDDI registry:

 public static void main (String args[]) {     System.setProperty(TransportFactory.PROPERTY_NAME,     "org.uddi4j.transport.ApacheAxisTransport");       System.setProperty("org.uddi4j.logEnabled","true");       UDDIProxy px = new UDDIProxy();         try       {             px.setPublishURL(config.getProperty( "https://www-3.ibm.com/services/uddi/v2beta/protect/publishapi"));             AuthToken t = proxy.get_authToken("wattersp",             "XYZ123");             String a=t.getAuthInfoString());             System.out.println("get_authToken: "+a);       }        catch (Exception e)       {             e.printStackTrace();       } }

The program performs the following actions in sequence:

1. Sets the transport type to be SOAP, provided by Apache Axis.

2. Enables verbose logging to standard output.

3. Constructs a new UDDIProxy object, which is used to invoke operations on a remote UDDI server.

4. Sets the UDDI registry target to be the IBM UDDI v2 test publishing registry over HTTPS.

5. Creates a new AuthToken object by the response from a get_authToken message.

6. Assigns the AuthInfo data to a string variable and prints it to standard output.

Every publishing operation—whether inserting records for new businesses, services, tModels, or assertions—must use this authentication method.

Determining if the Publisher Is Authorized to Publish a Web Service

Using the XML-Signature Syntax and Processing specification, UDDI allows the elements businessEntity, businessService, bindingTemplate, tModel, and publisherAssertion to be digitally signed in UDDI v3. This is in contrast to the fairly open identification model of prior versions of UDDI, where almost anyone could register a businessEntity or other element with no identification requirements. By digitally signing these elements, Subscribers and Inquirers can place a higher level of trust in material received from the registry that purports to be published by a specific company or organization.

In terms of authority to publish information in the registry, a list of business organizations that are responsible for creating all of the businessEntity and tModel objects is maintained. Thus, when a Publisher is authenticated, they have direct access to the entries that they have created in the registry. Figure 12-2 shows the interface for the IBM test registry. Here, a new businessEntity is being defined by an authenticated Publisher. When the Publisher has completed the definition, it will be published, but only that Publisher will be able to modify or delete the businessEntity and its associated objects.

Figure 12-2: Inserting a new businessEntity record into the IBM test registry

A similar interface is provided for defining tModels by authorized Publishers, as shown in Figure 12-3. Here, an authenticated Publisher can define the tModel name, description, overview URL, and a UNSPSC description of the associated industry. Once again, only the authenticated Publisher can modify this data once it has been saved to the registry.

Figure 12-3: Inserting a new tModel record into the IBM test registry

Every site that runs a UDDI registry (whether private or public) must decide on policies for authenticating Publishers and authorizing their activities. Typically, these controls will be implemented through native services—Active Directory, for example, implements many of the security elements associated with the Microsoft UDDI implementation. The methods for authenticating Publishers require standards wherever an assertion is made about the identity of a Publisher from registry to registry. This is where the Secure Assertions Markup Language (SAML) can play a key role in providing “single sign-on” authentication services. SAML is described in more detail in the section “The Role of SAML in UDDI.”

One of the benefits of placing strict controls on the authentication and authorization of entries being published in the directory is the increased authenticity that can be established for both Subscribers and Inquirers. For example, if a Subscriber can trust the fact that an authenticated company has digitally signed content in the directory, then a manual check of credentials by the Subscriber is no longer required (as may have been necessary in UDDI v2). In addition, Inquirers can specify that only signed entries be returned as a result of directory queries. This reduces the time required to process requests, since only verified data is returned. The increased confidence associated with digital signing may convince more organizations to participate in the public directory scheme.

Because only authentic Publishers can sign content by using their own private key, a UDDI registry cannot claim to be holding entries from a company unless they have illegally obtained access to the private key. This scenario is unlikely because private keys are not released in the public domain. In addition, when data is moved between registries as a result of entity promotion, any tampering can be automatically detected by Subscribers and Inquirers, and the results of a search containing invalid data can be ignored.

Nonrepudiation of transactions is also critical for commercial transactions, because different parties can sign data to ensure that a record of all electronic contracts, for example, can be stored with integrity. Being able to prove that an agreement was accepted through digital signing of UDDI data is critical to the development of dynamic virtual enterprises in the commercial arena.

Signing the Published WSDL File

Digital signing is a key issue to ensure the integrity of data in a registry. However, what about the integrity of interfaces that involve the dynamic lookup of services through WSDL? As with all networked services, there is a potential for spoofing to occur—that is, for a wily cracker to replace a genuine WSDL file containing valid interface definitions with a fake WSDL file containing invalid interface definitions. For example, a money market service might process electronic cash transactions between member banks. If the interface for transferring millions of dollars electronically was slightly tampered with to point to a spoof site that provided technically correct interfaces for the transaction, the money would be incorrectly transferred without the knowledge of the sender. How can this problem be overcome? Again, digital signing provides a solution by allowing WSDL files to be signed as a means of establishing the authenticity of the interface definitions.

XML digital signatures have a specific syntax associated with a set of processing rules. While this is fairly complicated, most applications only require a subset of all possible elements to be implemented. The basic procedure for signing an object—such as any of the main UDDI registry objects—is that a message digest is computed from the data and then added to a new element from which a new digest is then computed. It is this second digest that is then signed. The <Signature> element is used to represent the output of this process. Elements that can be encapsulated by a <Signature> element include the following:

• <SignedInfo> Contains the signed data.

• <CanonicalizationMethod> Defines the algorithm that is used to canonicalize the data to be signed.

• <SignatureMethod> Specifies the algorithm used to sign the data, including implementations of the DSA and RSA methods.

• <DigestMethod> Algorithm used to compute the message digest, such as SHA-1 or MD5.

• <SignatureValue> The actual signature data.

• <DSAKeyValue> Contains a key that can be used to confirm the signature.

The Role of XML Encryption in UDDI: Screening Services

The XML encryption syntax and processing specification (http://www.w3.org/TR/xmlenc-core/) defines some standard methods for encrypting data that is embodied in XML. The output of the encryption process is yet another XML element that contains a secure version of the original element. Encryption, in the context of UDDI, can be a useful way of protecting data against accidental interception by an unauthorized party, or against deliberate attempts at seizure. In order to use XML encryption, the following steps must be implemented by an application:

1. An encryption algorithm must be selected.

2. A key must be acquired or generated.

3. The data must be encrypted.

4. The output must be encoded as part of an EncryptedType structure.

5. The EncryptedData element is then created.

Let’s look at an example where two strings need to be entered into a UDDI registry, or any other SOAP application. Now, imagine that two parameters were to be transmitted to the registry: the first, to be encrypted, contains the string “Security reports - top secret” (param1), while the second contains the string “Security reports - public access” (param2). The request looks like this:

<SOAP-ENV:Body > <mns:someMethod xmlns:mns="http://www.cassowary.net/xml/SOAPTest.xsd" SOAP- ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Type="http://www.w3.org/2001/04/xmlenc#Element"> <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" /> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:KeyName>cassowary.net</ds:KeyName> <ds:KeyValue>AQIAAANmAAAApAAA5K/BnmTnOlaIklEQGEfk4oN/D/l2QeU7LQzGgT8CiC+u7CZm 2S6gGcLhvtU6SJyoLoFPIFcD5X8E2ego/qzAhX3XEGMOJJb48RbVuFZpr0Utl2Py K+i9c0giA4htBx/M2/0qsYZIPigN+x6DdbjVfsF3dvkFRw1nUdurU1XZxZw=</ds:KeyValue> </ds:KeyInfo> <CipherData> <CipherValue>V5lJ64cqW46ETzSYuzWVqjPEbJm+DRDP0PpbsqoT6QCYlONEwr4wO2py3NFQHvdm jkH9S13wmkmT1UfvMFShwMwx6WNH7KKZly/qQAhfw+c=</CipherValue> </CipherData> </EncryptedData> <param2 xsi:type="xsd1:string">Security reports - public access</param2> </mns:someMethod> </SOAP-ENV:Body> 

This request uses 3DES to encrypt the contents of param1 and supplies the appropriate <KeyValue> and <CipherData>, as well as passing the contents of param2 in the clear. The response is as follows:

<SOAP-ENV:Body> <tns:someMethodResponse SOAP-     ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"     Type="http://www.w3.org/2001/04/xmlenc#Element"> <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#     tripledes-cbc" /> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:KeyName>paulwatters.com</ds:KeyName> </ds:KeyInfo> <CipherData> <CipherValue>LKnCWXepHRS8ararQo8WiuqnUfcO+PKZyt5ok8fRlTnAiNqgAdwW qv/kX4YhAoFcxepWMslqnkRvkbTU+LztN9477URhVY2xWZ1AKgKlJI7w4MjeDtMx pKiSuqaf/S4ET8Yi5lfN9mrBiW44DvKqMB6ZDsgZipY4Ec7Un5kM1pjkjKmr9KjlY eqygBk8Nlu8</CipherValue> </CipherData> </EncryptedData> </tns:someMethodResponse> </SOAP-ENV:Body>

In this example, the data returned from the method call is also encrypted.

Authenticating and Authorizing Subscribers

As described earlier, the Subscriber role differs from the Inquirer role because the former must be authenticated, while the latter does not have to be. While the UDDI v3 specification provides for optional access control on the basis of X.509 certificates, there may be some differences in the way that authentication and access control are handled internally by different products. It is likely that some form of inquiry-driven authentication and authorization would be required by some businesses before access to any registry could be granted. A further level of authenticity for Publishers that may be useful to Subscribers is the XML-Signature Syntax and Processing specification (http://www.w3.org/TR/xmlsig-core?), which allows Publishers to digitally sign their own content stored in a registry, providing a level of authenticity beyond that which is available in current public test registries.

Authenticating the Subscriber

In order to create a subscription, a service needs to be developed to process notifications from the registry as they are received, using only one bindingTemplate. Generally, these notifications will be received from the registry using SOAP. A set of criteria defined by a subscriptionFilter must be developed, to ensure that the notifications only contain data relevant to the application. An authInfo token is required for authenticating the client in all cases. The following shows one example of how a subscription can be implemented securely:

<save_binding xmlns="urn:uddi-org:api_v3">          <authInfo>...</authInfo>          <bindingTemplate bindingKey=""serviceKey="uddi:myServiceKey">             <description>secure subscription service</description>             <accessPoint URLType="https">                  https://cassowary.net/notify_subscriptionListener             </accessPoint>         <tModelInstanceDetails>          <tModelInstanceInfo tModelKey=            "uddi:uddi.org:v3_subscriptionListener" />            </tModelInstanceDetails>       </bindingTemplate> </save_binding>

In this example, a secure subscription service is made available on https://cassowary.net/notify_subscriptionListener along with the appropriate authInfo token.

Determining if the Subscriber Is Authorized to “Discover” a Web Service

Subscribers do not have free and open access to changes that occur within a registry. They must be authenticated, and their access may be still further restricted. Different registries may or may not support subscription at all. Rules may also be defined that determine the level of access given to Subscribers, and in the future billing services for access subscriptions may also be imposed. (The latter certainly opens up opportunities for creating new businesses using UDDI.)

There are two forms of subscription that are supported: asynchronous and synchronous. Asynchronous subscriptions use the notify_subscriptionListener API to automatically alert Subscribers when a notifiable activity occurs. Alternatively, synchronous subscription uses the get_subscriptionResults API and allows regular polling of the directory to receive notification of all changes made to the registry since the previous access. Subscriptions can be identified by the subscriptionKey element.

Subscribers can be authorized for specific time periods, from seconds to years. This prevents default access to Subscribers who have not actively resubscribed and who may need to be authenticated again.

The Role of SAML in UDDI

Access control in UDDI registries is controlled by a set of optional authorization policies. The element authInfo is used to provide information that can be used for authorization decisions for a specific type of user, whether Subscriber, Publisher, or Inquirer. The SAML markup language can be used to assert authorizations in the form of X.509 attribute certificates.

One important aspect of UDDI is the fact that multiple registries can be used concurrently. For example, in a financial application, one registry might contain customer records while another registry might contain supplier records. While it’s possible that an Inquirer could be authenticated separately by each registry, it would be much easier if a single sign-on process could be implemented. More importantly, some registries might only allow access to their data if you have been authenticated by a separate registry. Authentication procedures for secure group communications currently require new keys to be issued to group members if a change is made to the group’s membership. While techniques for dynamically modifying group membership without having to issue new keys is an area of active research ^[1],centralizing authentication reduces the proliferation of keys and authentication tokens (which change over time). This approach reduces administrative costs because a single authentication server can be utilized by a number of different registries, and ensures consistency of access granted across multiple services.

The Security Assertion Markup Language (SAML) uses XML to pass authentication tokens and authorization data between different Web Services, including UDDI. A SAML assertion can be made about users or systems, and typically concerns the identity of the user or system. Assertions can also be made about the types of access that a correctly identified user should be able to access. SAML supports quite complex types of assertions about users, systems, and their attributes, and uses SOAP over HTTP to service authentication requests. SAML requires that individual authorities take responsibility for authentication and authorization.

One of the interesting applications of SAML to UDDI is the ability for a user to be authenticated locally, and for that authentication to be asserted later to a business partner’s application. Because the user, once authenticated, can have their access controls enforced by the remote system, the business partner’s systems are protected from incorrectly identified external users. In addition, the usage of the external user can be strictly controlled. The authentication can be time-based, so that the identity of an external user may only be validated for a certain time period. Most importantly, because the user has been authenticated by a trusted business partner, their identity and actions cannot be repudiated.

A sample SAML request is shown here:

<samlp:Request MajorVersion="1" MinorVersion="0"   Request>   <samlp:RespondWith>AuthenticationStatement</samlp:RespondWith>     <samlp:AuthenticationQuery>       <saml:Subject>         <saml:NameIdentifier Name="SecureDatabase"/>         <saml:SubjectConfirmation>           <saml:ConfirmationMethod>             http://www.oasis-open.org/committies/security/                    docs/draft-sstc-core-25/password           </saml:ConfirmationMethod>           <saml:SubjectConfirmationData>             AbcDEf43a445A=           </saml:SubjectConfirmationData>         </saml:SubjectConfirmation>       </saml:Subject>     </samlp:AuthenticationQuery> </samlp:Request>

The different elements in this request can be described as follows:

• AuthenticationQuery An authentication query

• AuthenticationStatement A statement of authentication

• RequestID A unique token that identifies the authentication query, and that matches the InResponseTo field in the response

• Subject Describes the system or user to be authenticated

The response for this request is shown here:

<samlp:Response InResponseTo="6fbhGHH7g76628+/sdas2nfDDSSW="   MajorVersion="1" MinorVersion="0"   Response>   <samlp:Status>     <samlp:StatusCode Value="samlp:Success"/>   </samlp:Status>   <saml:Assertion Assertion     IssueInstant="2002-11-01T12:00:00.001" Issuer="cassowary.net"     MajorVersion="1" MinorVersion="0">     <saml:Conditions NotBefore="2002-11-01T12:00:00.001"       NotOnOrAfter="2002-03-03T15:03:58.466"/>       <saml:AuthenticationStatement         AuthenticationInstant="2002-03-03T14:33:55.201"         AuthenticationMethod="http://www.oasis-open.org/committies/security/ docs/draft-sstc-core-25/password">           <saml:Subject>             <saml:NameIdentifier Name="SecureDatabase"              SecurityDomain="card:SQLDatabase"/>             <saml:SubjectConfirmation>               <saml:ConfirmationMethod>                 http://www.oasis-open.org/committies/security/docs/draft-sstc-                 core-25/password               </saml:ConfirmationMethod>             </saml:SubjectConfirmation>           </saml:Subject>         </saml:AuthenticationStatement>   </saml:Assertion> </samlp:Response>

Here, the Subject element is authenticated, with a set of time restrictions and a unique AssertionID, which is an identifier for the assertion being made.

^[1]I have to confess that I am currently working on secure group communications.