test

Sun OpenSSO Enterprise 8.0 Technical Overview

Discovery Service

All web services are defined by a Web Services Description Language (WSDL) file that describes the type of data the service contains, the available ways said data can be exchanged, the operations that can be performed using the data, a protocol that can be used to perform the operations, and a URL (or endpoint) for access to the service. Additionally, the WSDL file itself is assigned a unique resource identifier (URI) that is used to locate it in a Universal Description, Discovery and Integration (UDDI) repository. Thus, the web service can now be discovered.

According to the Web Services Glossary, discovery of a web service is the act of locating a WSDL file for it. Typically, there are one or more web services on a network so, a discovery service is required to keep track of them. OpenSSO Enterprise implements the Liberty ID-WSF Discovery Service Specification for its Discovery Service. When a WSC queries the Discovery Service for a WSP that allows access to a particular user's credit card information, the Discovery Service matches the properties in the request against the properties of its registered services and returns the appropriate resource offering (which defines an association between a type of identity data and a URI to the WSDL definition for obtaining access to the data.)

Note –

The Discovery Service is configured using the XML service file amDisco.xml and can be managed using the OpenSSO Enterprise console or this XML file. Additional administration information can be found in the Sun OpenSSO Enterprise 8.0 Administration Guide.

The following sections contain additional information on the Discovery Service.

Discovery Service Process

Figure 12–6 provides an overview of the interactions between the parties in a web services environment using the Discovery Service. In this scenario, the identity provider hosts the Discovery Service and the process assumes that the Discovery Service is not generating security tokens.

Figure 12–6 Discovery Service Process

Discovery Service process

  1. The user logs in to an identity provider, is authenticated, and completes the federation process, enabling single sign-on with other members of the circle of trust. More specifically:

    1. Within a browser, the user types the URL for a service provider.

    2. The service provider collects the user’s credentials and redirects the information to the identity provider for authentication.

    3. If the credentials are verified, the user is authenticated.

    4. Assuming the identity provider is the center of a circle of trust, it will notify the authenticated user of the option to federate any local identities created with circle of trust member organizations. The user would then accept or decline this invitation to federate. If the user accepts this option to federate, single sign-on is enabled. By accepting the invitation, the user will be given the option to federate to a member organization’s web site at each login.

  2. After authentication, the user now requests access to services hosted by another service provider in the circle of trust.

  3. The service provider, acting as a WSC, sends a DiscoveryLookup query to the Discovery Service looking for a pointer to the user's identity provider.

    The service provider is able to bootstrap the Discovery Service using the end point reference culled from the authentication statement.

  4. The Discovery Service returns a DiscoveryLookup response to the service provider that points to the instance of the requested identity provider.

    The response contains the resource offering for the user’s Liberty Personal Profile Service.

  5. The service provider then sends a query (using the Data Services Template Specification) to the Liberty Personal Profile Service.

    The required authentication mechanism specified in the Liberty Personal Profile Service resource offering must be followed.

  6. The Liberty Personal Profile Service authenticates and validates authorization, or policy, or both for the requested user and service provider, and returns a Data Services Template response.

    If user interaction is required for some attributes, the Interaction Service will be invoked to query the user for consents or attribute values. The Data Services Template would then be returned after all required data is collected.

  7. The service provider processes the Liberty Personal Profile Service response and renders HTML pages based on the original request and user authorization.

    A user's actual account information is not exchanged during federation. Thus, the identifier displayed on each provider site will be based on the respective local identity profile.

Discovery Service Architecture

Remote Java applications use the Client SDK to form requests sent to the Discovery Service and to parse the responses received back from it. Requests are initially received by the SOAPReceiver, a servlet which constructs the SOAP message that incorporates the client request.

Note –

The SOAP Binding Service defines how to send and receive messages using SOAP, an XML-based messaging protocol. For more information, see SOAP Binding Service in Sun OpenSSO Enterprise 8.0 Administration Guide.

The SOAP message is then routed to the Discovery Service which parses the resource identifier from it. This identifier is used to find a matching user distinguished name (DN). The necessary information is then culled from the corresponding profile, a response is generated, and returned to the SOAPReceiver which sends the response back to the client. Figure 12–7 illustrates this architecture.

Figure 12–7 Discovery Service Architecture

Illustration depicting the architecture of the Discovery Service.

Discovery Service API

The Discovery Service includes the following Java programming packages:

For more information, see the Sun OpenSSO Enterprise 8.0 Java API Reference and the Sun OpenSSO Enterprise 8.0 Developer’s Guide.