Chapter 12: UDDI and Security | Web Services Security

Two words not often found in the same sentence are “UDDI” and “Security.” UDDI is a complex specification and, until the recent version 3, avoided any mention of security. However, security must be applied to UDDI when it is used “in the wild.” This chapter outlines how this might be achieved, using the technologies that the reader has learned about in the book so far.

UDDI Overview

UDDI is the Universal Description, Discovery, and Integration protocol. It is designed to allow Web Services to be easily located and subsequently invoked. UDDI allows companies to make public their contact and organizational details, the Web Services that they offer, and the set of interfaces available for public or private access. The latter is important because UDDI registries can be operated as public or private services, depending on organizational requirements and security concerns.

There are six types of data permitted to reside in a UDDI registry:

businessEntity
businessService
bindingTemplate
tModel
publisherAssertion
operationalInfo

UDDI repositories store both business information and service information. Business information is stored in the white pages and the yellow pages, and uses the businessEntity dataType. The white pages contain data concerning the identity of an organization and appropriate contact information. The yellow pages store information about services provided by a particular organization, and use the businessService data type. The organization of data in traditional telephone directories is also based on white and yellow pages: the former allows organizations to be located through an alphabetical search process. The latter allows for category-based lookups to be performed, utilizing semantic relationships between particular types of goods and services and the providers of those goods and services.

Service information is stored in the green pages. The green pages introduce a new type of service information that’s obviously not part of a traditional phone book: a bindingTemplate data type, and a tModel data type. A bindingTemplate specifies the locations of services provided by an organization and information about the interfaces provided to the service, while the tModel is concerned with defining the precise definition of each service by using a taxonomy. Figure 12-1 shows the structure of the business and service information within a UDDI registry, and the relationships between each page type (white, yellow, and green) and the relevant data models.

click to expand
Figure 12-1: UDDI data structures and service types

The final data type is publisherAssertion, which is a claim to a relationship between two parties asserted by at least one of the parties involved. In a security context, publisherAssertions are obviously important.

A businessEntity element, in the white pages, has three attributes and eight elements. The three attributes are

businessKey Uniquely identified by a universally unique identifier (UUID), and thus uniquely identifies each businessEntity
authorizedName A string containing the person that created the businessData entry
operator A string containing the name of the site that controls the definitive record for the businessEntity

The eight elements are

discoveryURLs Defines file-based discovery procedures
name Name of the businessEntity
description Describes the nature of the organization’s business
contacts Lists any contact persons for the businessEntity
businessServices Describes any services at a high level
identifierBag Contains industry data that uniquely identifies the businessIdentity
categoryBag Contains industry data, using the North American Industry Classification System (NAICS), and product data, using the Universal Standard Products and Services Classification System (UNSPSC)
dsig:SignatureElement Optional digital signature

More information about NAICS can be obtained from http://www.census.gov/epcd/www/naics.html, while UNSPSC definitions are listed at http://www.unspsc.org/.

A businessService element in the yellow pages has two attributes and four elements. The two attributes are

businessKey Uniquely identified by a UUID, and thus individually distinguishes each businessEntity
serviceKey Uniquely identified by a UUID, and thus individually distinguishes each service

The six elements are

name Name of the businessEntity
description Describes the nature of the organization’s business
bindingTemplates Contains a technical description of the services provided
categoryBag Contains industry and product data using NAICS and UNSPSC
dsig:SignatureElement Optional digital signature
A businessService Can be associated with multiple bindingTemplates

To work with UDDI, you will need access to a set of libraries and APIs that map between your particular platform and the XML schema that specifies the data types and operations that can be performed against a registry. For J2EE, this means that you will need a customized third-party API that maps Java methods to the appropriate SOAP calls. IBM has released an API called UDDI4J, which is what we will use for the examples in this chapter.

Let’s examine how UDDI works in practice by performing a search on a UDDI test registry using IBM’s UDDI4J API, which allows J2EE to utilize Web Services. The following code shows a test client that connects to the test registry, and returns details of businesses whose names start with “IBM Software” and “IBM Financial”:

import org.uddi4j.*; import org.uddi4j.client.*; import org.uddi4j.datatype.*; import org.uddi4j.request.*; import org.uddi4j.response.*; import org.uddi4j.util.*; import org.uddi4j.transport.TransportFactory; import java.util.Vector; public class SearchRegistry {    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.setInquiryURL(          "http://www-3.ibm.com/services/uddi/v2beta/inquiryapi");          Vector tokens = new Vector();          tokens.add(new Name("IBM Software"));          tokens.add(new Name("IBM Financial"));          FindQualifiers fq = new FindQualifiers();          Vector q = new Vector();          q.add(new FindQualifier("sortByNameAsc"));          fq.setFindQualifierVector(q);          BusinessList bl = px.find_business(tokens, null, null,          null,null,fq,50);          Vector v  = bl.getBusinessInfos().getBusinessInfoVector();          for (int i = 0; i < v.size(); i++)          {             BusinessInfo bi = (BusinessInfo)v.elementAt(i);             System.out.println(bi.getBusinessKey()+" : "+             bi.getNameString()+" : "+bi.getDefaultDescriptionString());          }       }       catch (Exception e)       {          e.printStackTrace();       }    } }

The program performs the following actions in sequence:

Sets the transport type to be SOAP, provided by Apache Axis.
Enables verbose logging to standard output.
Constructs a new UDDIProxy object, which is used to invoke operations on a remote UDDI server.
Sets the UDDI registry target to be the IBM UDDI v2 test registry.
Creates a vector of search tokens for “IBM Software” and “IBM Financial.”
Sets the result of the search to sort by ascending alphabetical order from the business entity names.
A BusinessList object is returned from a call against the UDDIProxy object, passing the tokens and search qualifiers, such as the maximum number of entries to search for.
A vector v is created, containing the business information details for all business that matches the search tokens.
The business key, business name, and description are then printed to standard output in a colon-delimited format.

A sample output is shown here:

CF23AA90-C706-11D5-A432-0004AC49CC1E : IBM Financial Transaction   Services : IBM Financial Transaction Services 0764DF70-FBA3-11D5-8C49-0004AC49CC1E : IBM Software Enterprise   Integration : We make complex tasks easy. DE10B100-DA6B-11D6-835F-000629DC0A7B : IBM Software Group Canberra :null AB4483A0-F623-11D5-9094-0004AC49CC1E : IBM Software Region North :Test business

The search process implemented in this code demonstrates the Inquirer role of UDDI, and it is described by the underlying UDDI Inquiry API. The complementary role is that of Publisher, where entries are recorded by a service provider using the UDDI Publication API. All of the discussion that follows concerning UDDI security concerns the roles of Inquirer and Publisher.