Part III Supported Web Services

• Chapter 5, Authentication Web Service

• Chapter 6, Data Services

• Chapter 7, Discovery Service

• Chapter 8, SOAP Binding Service

Chapter 5 Authentication Web Service

Sun Java™ System Access Manager contains an implementation of the Liberty ID-WSF Authentication Service Specification developed by the Liberty Alliance Project. The implementation of the specifications is called the Authentication Web Service which allows authentication using SOAP messages.

This chapter covers the following topics:

• Authentication Web Service Overview

• Which Authentication Service to Use?

• Authentication Web Service Process

• Authentication Web Service Attribute

• Authentication Web Service API

• Authentication Web Service Sample

Authentication Web Service Overview

The implementation of the Access Manager Authentication Web Service is based on the Liberty ID-WSF Authentication Service Specification. The specification defines a protocol that adds authentication functionality to the SOAP binding discussed in the Liberty ID-WSF SOAP Binding Specification and, Chapter 8, SOAP Binding Service in this guide. The specification also contains an XML schema that defines the authentication protocol.

This XML Schema Definition (XSD) file can be found on the Liberty Alliance Project web site. Version 1.0 is also reproduced in Appendix B, Service Schema Files.

The Authentication Web Service is for provider-to-provider authentication. The Simple Authentication and Security Layer (SASL) is the method used to add this authentication support.

XML Service File

The Authentication Web Service is configured using the XML service file amAuthnSvc.xml. This file defines the attribute for the Authentication Web Service which can be managed through the Access Manager console or the XML file.

For information about service files, see the Sun Java System Access Manager 7 2005Q4 Administration Guide.

Authentication Web Service APIs

The Access Manager Authentication Web Service includes the following Java programming packages:

• com.sun.identity.liberty.ws.authnsvc

• com.sun.identity.liberty.ws.authnsvc.mechanism

• com.sun.identity.liberty.ws.authnsvc.protocol

The first package is a client API for external Java applications to send SASL requests and receive SASL responses. The second package defines an interface to handle different SASL mechanisms. The final package contains classes that represent the SASL request and response. Together, the packages are used to initiate the authentication process and communicate authentication credentials to the Authentication Web Service. For more information, see the Authentication Web Service API.

Which Authentication Service to Use?

The Liberty-based Authentication Web Service is not to be confused with the proprietary Authentication Service discussed in the Sun Java System Access Manager 7 2005Q4 Administration Guide. Architecturally, the Authentication Web Service sits on top of the Access Manager Authentication Service and the Liberty Alliance Project framework. You might use the Authentication Web Service if you are a service provider and want to use a standards-based mechanism to authenticate users.

Following are two use cases where the Authentication Web Service is preferable to the Access Manager Authentication Service:

• A service provider relies on a remote identity provider (not necessarily using Access Manager) for authentication.

• An enterprise in a service-oriented architecture (SOA) environment wants to use nonproprietary mechanisms to authenticate users and web services clients before accessing a protected web service.

In addition to providing an authentication service to verify credentials (for example, user ID and password), the Authentication Web Service provides the web services consumer (WSC) with bootstrap information that contains the endpoint and credentials needed to access the Discovery Service (as discussed in Chapter 7, Discovery Service). The WSC can ignore the bootstrap or use it to access other web services, such as the authenticated user's personal profile or calendar.

An authenticated enterprise might also use the bootstrap information to access a partner in a business-to-business environment.

Following is an example that shows how the Authentication Web Service interacts with the Access Manager Authentication Service. It assumes the following separate entities:

• A user (principal)

• A service provider (acting as a WSC)

• An identity provider hosted by Access Manager where the Access Manager Authentication Service is configured for Certificate and LDAP authentication and the Authentication Web Service has mapped LDAP to its own PLAIN authentication mechanism

• The user's personal profile (hosted by another product)

The WSC delegates all authentication to the identity provider and prefers PLAIN authentication which accepts a user identifier and password.

1. The user attempts access to a service provider (not necessarily hosted by Access Manager).

2. When the service provider finds that the user is not authenticated, it invokes the identity provider's Authentication Web Service by sending it a SOAP request.

3. After inspecting its configuration, the Authentication Web Service sends back a response indicating that it supports Certificate and PLAIN authentication.

4. The service provider decides on PLAIN authentication and prompts the user for an identifier and password.

5. Interactions based on the standard PLAIN authentication mapping ensues between the service provider and identity provider (hosted on Access Manager) using the Authentication Web Service.

   1. The service provider receives the user identifier and password and sends it to the identity provider.

   2. The identity provider passes the credentials to the locally hosted LDAP Authentication module using the proprietary Access Manager Authentication Service's Java API.

   3. The LDAP Authentication module verifies the credentials.

   4. The Authentication Web Service is notified of the verification and sends a response to the service provider indicating successful authentication. If configured to do so, it also includes bootstrap information formatted using XML and containing the Discovery Service endpoint and a token to invoke it.

6. The service provider parses the response, verifies that it is a successful authentication, and provides the service to the user.

At some point the service provider might need to access the user's personal profile. To do this, it will use the bootstrap information received during this process to contact the Discovery Service and find where the profile is stored. The Discovery Service returns a resource offering (containing the location of an endpoint and a token), and the service provider uses that to invoke the Liberty Personal Profile Service.

Authentication Web Service Process

The exchange of authentication information between a web service consumer (WSC) and the web service provider (WSP) is accomplished using SOAP-bound messages. The messages are a series of client requests and server responses specific to the defined SASL mechanism (or mode of authentication).

The authentication exchange can involve an arbitrary number of round trips, dictated by the particular SASL mechanism employed. The WSC might have knowledge of the supported SASL mechanisms, or it might send the server its own list of mechanisms and allow the server to choose one. The list of supported mechanisms can be found at http://www.iana.org/assignments/sasl-mechanisms.

After receiving a request for authentication (or any response from the WSC), the WSP may issue additional challenges or indicate authentication failure or success. The sequence between the WSC and the Authentication Web Service (a WSP) is as follows.

1. The authentication exchange begins when a WSC sends an SASL authentication request to the Authentication Web Service on behalf of a principal.

   The request message contains an identifier for the principal and indicates one or more SASL mechanisms from which the service can choose.

2. The Authentication Web Service responds by asserting the method to use and, if applicable, initiating a challenge.

   If the Authentication Web Service does not support any of the cited methods, it responds by aborting the exchange.

3. The WSC responds with the necessary credentials for the chosen method of authentication.

4. The Authentication Web Service replies by approving or denying the authentication.

   If approved, the response includes the credentials the WSC needs to invoke other web services, such as the Discovery Service.

Authentication Web Service Attribute

The Authentication Web Service attribute is a global attribute. The value of this attribute is carried across the Access Manager configuration and inherited by every organization.

For information about the types of attributes used in Access Manager, see the Sun Java System Access Manager 7 2005Q4 Technical Overview.

The attribute for the Authentication Web Service is defined in the amAuthnSvc.xml service file and is called the Mechanism Handlers List.

Mechanism Handlers List

The Mechanism Handler List attribute stores information about the SASL mechanisms that are supported by the Authentication Web Service.

key Parameter

The required key defines the SASL mechanism supported by the Authentication Web Service.

class Parameter

The required class specifies the name of the implemented class for the SASL mechanism. Two authentication mechanisms are supported by the following default implementations:

The Authentication Web Service layer provides an interface that must be implemented for each SASL mechanism to process the requested message and return a response. For more information, see com.sun.identity.liberty.ws.authnsvc.mechanism Package.

Authentication Web Service API

The Authentication Web Service provides programmatic interfaces to allow clients to interact with it. The following sections provide short descriptions of these packages. For more detailed information, see the Java API Reference in /AccessManager-base/SUNWam/docs or on docs.sun.com. The authentication-related packages include:

• com.sun.identity.liberty.ws.authnsvc Package

• com.sun.identity.liberty.ws.authnsvc.mechanism Package

• com.sun.identity.liberty.ws.authnsvc.protocol Package

com.sun.identity.liberty.ws.authnsvc Package

This package provides web service clients with a method to request authentication credentials from the Authentication Web Service and receive responses back from it using the Simple Authentication and Security Layer (SASL).

com.sun.identity.liberty.ws.authnsvc.mechanism Package

This package provides an interface that must be implemented for each different SASL mechanism to enable authentication using them. Each SASL mechanism will correspond to one implementation that will process incoming SASL requests and generate outgoing SASL responses.

com.sun.identity.liberty.ws.authnsvc.protocol Package

This package provides classes that correspond to the request and response elements defined in the Liberty XSD schema that accompanies the Liberty ID-WSF Authentication Service Specification. This schema is reproduced in Appendix B, Service Schema Files.

Authentication Web Service Sample

A sample authentication client is included with Access Manager. It is located in the /AccessManager-base/SUNWam/samples/phase2/authnsvc directory. The client uses the PLAIN SASL authentication mechanism. It first authenticates against the Authentication Web Service, then extracts a resource offering to bootstrap the Discovery Service. It looks for a SAML Bearer token credential, issues a discovery query request with SAML assertion included, and receives a response.

This sample can be used by a Liberty User Agent Device WSC.

Chapter 6 Data Services

Sun Java System Access Manager contains implementations of the Liberty ID-WSF Data Services Template Specification in addition to instructions on how you can add a custom data service to your deployment.

This chapter covers the following topics:

• Data Services Overview

• Liberty Personal Profile Service

• Liberty Employee Profile Service

• Data Services Template API

• Developing A New Data Service

Data Services Overview

A data service is a web service that supports the query and modification of data regarding a principal. An example of a data service is a web service that hosts and exposes a principal's profile information, such as name, address and phone number. A query is when a web service consumer (WSC) requests and receives the data (in XML format). A modify is when a WSC sends new information to update the data. The Liberty Alliance Project has defined the Liberty ID-WSF Data Services Template Specification (Liberty ID-WSF-DST) as the standard protocol for the query and modification of data profiles exposed by a data service. Using this specification, the Liberty Alliance Project has developed additional specifications for other types of data services: personal profile service, geolocation service, contact service, and calendar service). Of these data services, Access Manager has implemented the Liberty Personal Profile Service and, using the included sample, the Liberty Employee Profile Service.

To develop your own data service see the instructions in Developing A New Data Service.

Liberty ID-WSF Data Services Template Specification

The Liberty ID-WSF-DST specifies a base layer that can be extended by any instance of a data service. An example of a data service is an identity service, such as an online corporate directory. When you want to contact a colleague, you conduct a search based on the individual’s name, and the data service returns information associated with that person's identity. The information might include the individual’s office location and phone number, as well as job title or department name. For proper implementation, all data services must be built on top of the Liberty ID-WSF-DST because it provides the data model and message interfaces. The following figure illustrates how Access Manager uses the Liberty ID-WSF-DST as the framework for data services.

Figure 6–1 Data Service Template as Building Block of Data Services

The Web Services framework in Access Manager uses the Liberty ID-WSF-DST to develop data services. The Access Manager Liberty Personal Profile Service and Liberty Employee Profile Service were developed on top of the Web Services framework, using the specification. Additional data services can also be developed by the customer.

For more information on the data services specification, see the Liberty ID-WSF Data Services Template Specification.

Liberty Personal Profile Service

The Liberty ID-SIS Personal Profile Service Specification (Liberty ID-SIS-PP) describes a data service that provides an identity’s basic profile information, such as full name, contact details, and financial information. This data service is intended to be the least common denominator for holding consumer-based information about a principal. Access Manager has implemented this specification and developed the Liberty Personal Profile Service.

For more information, see the Liberty ID-SIS Personal Profile Service Specification.

XML Service File

The Access Manager Liberty Personal Profile Service is configured using the XML service file amLibertyPersonalProfile.xml. This file defines attributes for the Liberty Personal Profile Service which can be managed through the Access Manager Console or the XML file itself.

For information about service files, see the Sun Java System Access Manager 7 2005Q4 Administration Guide.

XSD Schema Definition

The Liberty ID-SIS-PP also defines an XML schema for use in building a personal profile service. This XML Schema Definition (XSD) file is on the Liberty Alliance Project web site. Version 1.0 is also reproduced in Appendix B, Service Schema Files.

Liberty Employee Profile Service

The Liberty ID-SIS Employee Profile Service Specification (Liberty ID-SIS-EP) describes a data service that provides an identity’s profile information as it relates to employment. An example of a employee profile service might be a corporate calendar or phone book.

Access Manager has implemented this specification by developing a sample that includes the files needed to deploy and invoke a Liberty Employee Profile Service. The Liberty Employee Profile Service is not available when Access Manager is installed. It must first be deployed. For information about accessing the sample files and how to deploy them, see Liberty Employee Profile Service.

For more information, see the Liberty ID-SIS Employee Profile Service Specification.

XML Service File

Among the files included with the sample is the XML service file amLibertyEmployeeProfile.xml. This file defines the attributes for the Liberty Employee Profile Service which, once deployed, can be managed through the Access Manager Console or the XML file itself.

For information about service files, see the Sun Java System Access Manager 7 2005Q4 Administration Guide.

XSD Schema Definition

The Liberty ID-SIS-EP also defines an XML schema for use in building an employee profile service. This XSD file is on the Liberty Alliance Project web site. Version 1.0 is also reproduced in Appendix B, Service Schema Files.

Data Services API

Access Manager data services are built using a Java package called com.sun.identity.liberty.ws.dst. Access Manager provides this package for developing custom services based on the Liberty ID-WSF-DST. Additional information about these interfaces can be found in Data Services Template API and in the Java API Reference at /AccessManager-base/SUNWam/docs or on docs.sun.com.

Liberty Personal Profile Service

The Liberty Personal Profile Service is a default Access Manager identity service. It can be queried for identity data and its attributes can be updated.

For access to occur, the hosting provider of the Liberty Personal Profile Service needs to be registered with the Discovery Service on behalf of each identity principal. To register a service with the Discovery Service, update a resource offering for that service. For more information, see Chapter 7, Discovery Service.

Liberty Personal Profile Service Process

The invocation of a personal profile begins when a WSC posts a query or a modify request to the Liberty Personal Profile Service on behalf of a user. The following process is also illustrated in Figure 6–2.

1. A web services client uses the Data Services Template API to post a query or a modify request to the Liberty Personal Profile Service.

   All the query or modify requests to any identity service are SOAP requests.

2. The client’s SOAP request is received by the SOAP receiver provided by the SOAP Binding Service.

   The SOAP receiver invokes either the Discovery Service, the Authentication Web Service, or the Liberty Personal Profile Service, depending on the service key transmitted as part of the URL. The SOAP Binding Service might also authenticate the client identity.

3. The Liberty Personal Profile Service implements the DSTRequestHandler to process the request.

   The request is processed based on the request type (query or modify) and the query expression. Processing might entail the authorization of a WSC using the Access Manager Policy Service, or it might entail using the Interaction Service for interacting with the user before sending data to the WSC.

4. The Liberty Personal Profile Service builds a service response, adds credentials (if they are required), and sends the response back to the WSC.

   • For a response to a query request, the Liberty Personal Profile Service builds a personal profile container (as defined by the specification). It is formatted in XML and based on the Query Select expression. The Personal Profile attribute values are extracted from the data store by making use of the attribute mapper. The attribute mapper is defined by the XML service file, and the attribute values will be used while building the XML container. The Personal Profile Service then applies xpath queries on the XML and provides us with the resultant XML data node.

   • For a response to a modify request, the Liberty Personal Profile Service parses the Modifiable Select expression and updates the new data from the new data node in the request.

The following diagram illustrates the Liberty Personal Profile Service process.

Figure 6–2 Liberty Personal Profile Service Process

Liberty Personal Profile Service Attributes

The Liberty Personal Profile Service attributes are global attributes. The values of these attributes are carried across the Access Manager configuration and inherited by each configured organization.

For information about the types of attributes used in Access Manager, see the Sun Java System Access Manager 7 2005Q4 Technical Overview.

Attributes for the Personal Profile Service are defined in the amLibertyPersonalProfile.xml service file. The attributes are:

• ResourceID Mapper

• Authorizer

• Attribute Mapper

• Provider ID

• Name Scheme

• Namespace Prefix

• Supported Containers

• PPLDAP Attribute Map List

• Require Query PolicyEval

• Require Modify PolicyEval

• Extension Container Attributes

• Extension Attributes Namespace Prefix

• Is ServiceUpdate Enabled

• Service Instance Update Class

• Alternate Endpoint

• Alternate Security Mechanisms

ResourceID Mapper

The value of this attribute specifies the implementation of com.sun.identity.liberty.ws.interfaces.ResourceIDMapper. Although a new implementation can be developed, Access Manager provides the default com.sun.identity.liberty.ws.idpp.plugin.IDPPResourceIDMapper, which maps a discovery resource identifier to a user identifier.

Authorizer

Before processing a request, the Liberty Personal Profile Service verifies the authorization of the WSC making the request. There are two levels of authorization verification:

• Is the requesting entity authorized to access the requested resource profile information?

• Is the requested resource published to the requestor?

Authorization occurs through a plug-in to the Liberty Personal Profile Service, an implementation of the com.sun.identity.liberty.ws.interfaces.Authorizer interface. Although a new implementation can be developed, Access Manager provides the default class, com.sun.identity.liberty.ws.idpp.plugin.IDPPAuthorizer. This plug-in defines four policy action values for the query and modify operations:

• Allow

• Deny

• Interact For Consent

• Interact For Value

The resource values for the rules are similar to x-path expressions defined by the Liberty Personal Profile Service. For example, a rule can be defined like this:

/PP/CommonName/AnalyzedName/FN    Query   Interact for consent
/PP/CommonName/*                  Modify  Interact for value
/PP/InformalName                  Query   Deny

Authorization can be turned off by deselecting one or both of the following attributes, which are also defined in the Liberty Personal Profile Service:

• Require Query PolicyEval

• Require Modify PolicyEval

Attribute Mapper

The value of this attribute defines the class for mapping a Liberty Personal Profile Service attribute to an Access Manager user attribute. By default, the class is com.sun.identity.liberty.ws.idpp.plugin.IDPPAttributeMapper.

com.sun.identity.liberty.ws.idpp.plugin.IDPPAttributeMapper is not a public class.

Provider ID

The value of this attribute defines the unique identifier for this instance of the Liberty Personal Profile Service. Use the format protocol://hostname:port/deloy-uri/Liberty/idpp.

Name Scheme

The value of this attribute defines the naming scheme for the Liberty Personal Profile Service common name. Choose First Last or First Middle Last.

Namespace Prefix

The value of this attribute specifies the namespace prefix that is used for Liberty Personal Profile Service XML protocol messages. A namespace differentiates elements with the same name that come from different XML schemas. The Namespace Prefix is prepended to the element.

Supported Containers

The values of this attribute define a list of supported containers in the Liberty Personal Profile Service. A container, as used in this instance, is an attribute of the Liberty Personal Profile Service.

The term container as described in this section is not related to the Access Manager identity-related object that is also called container.

For example, Emergency Contact and Common Name are two default containers for the Liberty Personal Profile Service. To add a new container, click Add, enter values in the provided fields and click OK.

This functionality is not yet public.

PPLDAP Attribute Map List

Each identity attribute defined in the Liberty Personal Profile Service maps one-to-one with an Access Manager LDAP attribute. For example, JobTitle=sunIdentityServerPPEmploymentIdentityJobTitle maps the Liberty JobTitle attribute to the Access Manager sunIdentityServerPPEmploymentIdentityJobTitle attribute.

The value of this attribute is a list that specifies the mappings. The list is used by the attribute mapper defined in Attribute Mapper, by default, com.sun.identity.liberty.ws.idpp.plugin.IDPPAttributeMapper.

When adding new attributes to the Liberty Personal Profile Service or the LDAP data store, ensure that the new attribute mappings are configured as values of this attribute.

In the following code sample, the Liberty Personal Profile Service informalName attribute mapping to the LDAP attribute uid is added to the mappings already present in the Liberty Personal Profile Service XML service file, amLibertyPersonalProfile.xml.

Attribute mappings are defined as global attributes under the name sunIdentityServerPPDSAttributeMapList in amLibertyPersonalProfile.xml. This attribute corresponds to that sunIdentityServerPPDSAttributeMapList global attribute.

<AttributeSchema name="sunIdentityServerPPDSAttributeMapList"
          type="list"
          syntax="string"
          i18nKey="p108">
          <DefaultValues>
              <Value>CN=sunIdentityServerPPCommonNameCN</Value>
              <Value>FN=sunIdentityServerPPCommonNameFN</Value>
              <Value>MN=sunIdentityServerPPCommonNameMN</Value>
              <Value>SN=sunIdentityServerPPCommonNameSN</Value>
              <Value>InformalName=uid</Value>
          </DefaultValues>
</AttributeSchema>

Require Query PolicyEval

If selected, this option requires that a policy evaluation be performed for Liberty Personal Profile Service queries. For more information, see Authorizer.

Require Modify PolicyEval

If selected, this option requires that a policy evaluation be performed for Liberty Personal Profile Service modifications. For more information, see Authorizer.

Extension Container Attributes

The Liberty Personal Profile Service allows you to specify extension attributes that are not defined in the Liberty Alliance Project specifications. The values of this attribute specify a list of extension container attributes. All extensions should be defined as:

    /PP/Extension/PPISExtension [@name=’extensionattribute’]

The following sample illustrates an extension query expression for creditcard, an extension attribute.

Example 6–1 Extension Query for creditcard

 /pp:PP/pp:Extension/ispp:PPISExtension[@name=’creditcard’]
Note: The prefix for the PPISExtension is different,
 and the schema for the PP extension is as follows:
<?xml version="1.0" encoding="UTF-8" ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
  xmlns="http://www.sun.com/identity/liberty/pp"
  targetNamespace="http://www.sun.com/identity/liberty/pp">
  <xs:annotation>
      <xs:documentation>
      </xs:documentation>
  </xs:annotation>

  <xs:element name="PPISExtension">
     <xs:complexType>
        <xs:simpleContent>
           <xs:extension base="xs:string">
              <xs:attribute name="name" type="xs:string"
                use="required"/>
           </xs:extension>
        </xs:simpleContent>
     </xs:complexType>
   </xs:element>
</xs:schema>

Extension Attributes Namespace Prefix

The value of this attribute specifies the namespace prefix for the extensions defined in the Extension Container Attributes. This prefix is prepended to the element and helps to distinguish metadata from different XML schema namespaces.

Is ServiceUpdate Enabled

The SOAP Binding Service allows a service to indicate that requesters should contact it on a different endpoint or use a different security mechanism and credentials to access the requested resource. If selected, this attribute affirms that there is an update to the service instance.

Service Instance Update Class

The value of this attribute specifies the default implementation class com.sun.identity.liberty.ws.idpp.plugin.IDPPServiceInstanceUpdate. This class is used to update the information for the service instance.

Alternate Endpoint

The value of this attribute specifies an alternate SOAP endpoint to which a SOAP request can be sent.

Alternate Security Mechanisms

This attribute allows you to choose a security mechanism. For more information about this functionality and the mechanisms, see the Liberty ID-WSF Security Mechanisms specification.

Liberty Employee Profile Service

The Liberty Employee Profile Service sample provides a collection of files that can be used to deploy and invoke a corporate-based data service. The files are located in the /AccessManager-base/SUNWam/samples/phase2/sis-ep directory.

Before implementing this sample, you must have two instances of Access Manager installed, running, and Liberty-enabled. Completing the steps in sample1 Directory will accomplish this.

The Liberty Employee Profile Service is a deployment of the ID-SIS-EP specification as discussed in Liberty Employee Profile Service. The Readme.html file in the sample directory provides detailed steps on how to deploy and configure this sample for use as a data service. See also Appendix A, Liberty-based and SAML Samples.

Data Services Template API

Access Manager contains two packages based on the Liberty ID-WSF-DST. They are:

• com.sun.identity.liberty.ws.dst Package

• com.sun.identity.liberty.ws.dst.service Package

For more detailed API documentation, including methods and their syntax and parameters, see the Java API Reference in /AccessManager-base/SUNWam/docs or on docs.sun.com.

com.sun.identity.liberty.ws.dst Package

The following table summarizes the classes in the Data Services Template client API that are included in the com.sun.identity.liberty.ws.dst package.

com.sun.identity.liberty.ws.dst.service Package

This package provides a handler class that can be used by any generic identity data service that is built using the Liberty Alliance ID-SIS Specifications.

The Liberty Personal Profile Service is built using the Liberty ID-SIS Personal Profile Service Specification, based on the Liberty Alliance ID-SIS Specifications.

The DSTRequestHandler class is used to process query or modify requests sent to an identity data service. It is an implementation of the interface com.sun.identity.liberty.ws.soapbinding.RequestHandler. For more detailed API documentation, see the Java API Reference in /AccessManager-base/SUNWam/docs or on docs.sun.com.

Access Manager provides a sample that makes use of the DSTRequestHandler class. The sis-ep sample illustrates how to implement the DSTRequestHandler and deploy a new identity data service instance. The sample is located in the /AccessManager-base/SUNWam/samples/phase2/sis-ep directory. For more information, see sis-ep Directory.

Developing A New Data Service

In addition to deploying an employee profile service, the Liberty Employee Profile Service sample can be used to deploy other custom data services that are based on the Liberty ID-WSF-DST. Sections 2 and 3 in the Readme.html file in the /AccessManager-base/SUNWam/samples/phase2/sis-ep directory has detailed steps on how to deploy and configure data services. To use those instructions for a new data service, you need to write a new data service schema. This XML Schema Definition (XSD) document (as discussed in Appendix B, Service Schema Files) defines the service’s data and data structure. After you write a new XSD file, use it to deploy your new data service instead of the lib-id-sis-ep.xsd file.

Instructions on writing the XSD file are beyond the scope of this guide.

Chapter 7 Discovery Service

Sun Java System Access Manager contains a Discovery Service defined by the Liberty Alliance Project. The Discovery Service allows a requesting entity to dynamically determine a principal’s registered identity service. It might also function as a security token service, issuing security tokens to the requester that can then be used in the request to the discovered identity service.

This chapter covers the following topics:

• Discovery Service Overview

• Discovery Service Architecture

• Discovery Service Process

• Discovery Service Attributes

• Discovery Entries and Resource Offerings

• Discovery Service APIs

• Discovery Service Sample

Discovery Service Overview

The initial step in accessing identity data (as discussed in Chapter 6, Data Services) is to determine where the information is located. For example, you must determine which identity service holds the principal’s credit card information or which server stores the principal’s calendar service. Typically, there are one or more services on a network that allow other entities to perform an action on identity data. Because clients are not expected to keep track of these services or to know which can be trusted, they require a discovery service. The Liberty ID-WSF Discovery Service Specification defines the framework that enables a client to locate the appropriate web service for retrieving, updating, or modifying a specific piece of identity data.

For more information, see the Liberty ID-WSF Discovery Service Specification.

Discovery Service Concepts

A discoverable web service is assigned a service type unique resource identifier (URI) in the specification that defines it. This URI points to the Web Services Description Language (WSDL) file that describes the service’s data, the operations that can be performed on it, and a protocol to perform the operations. The discoverable service specification itself adds the available ways the data can be exchanged. A discovery service is essentially a web service interface for discovery resources. A discovery resource is a registry of resource offerings. A resource offering defines an association between a piece of identity data and the service instance that provides access to that data. A resource identifier is a URI registered with the discovery service that points to a particular discovery resource.

When a client sends a request for some type of data, it includes a resource identifier that the Discovery Service uses to locate the web services provider (WSP) for the requested attributes. The Discovery Service returns a resource offering that contains the information necessary to locate the data.

Because a provider hosting the Discovery Service can also be fulfilling other roles for an identity (such as a Policy Decision Point or an Authentication Authority), a query response also functions as a security token service. It provides a requester with the means of obtaining security tokens that can be used to invoke service instances returned.

Discovery Entries

One user account has one discovery resource. This discovery resource can include zero or more resource offerings. Storing resource offerings within a user profile supports both entry lookups and updates. Another option is to store discovery entries within a service, and assign that service to an organization or a role. This scenario supports only entry lookups using the discovery protocol although you can still update the entries using the console. For more information about discovery entries, see Discovery Entries and Resource Offerings.

XML Service Files

The Discovery Service is defined using the XML service file amDisco.xml. This file defines the attributes for the Discovery Service. All of the attributes in the Discovery Service can be managed through either the Access Manager Console or this file.

For more information about service files, see the Sun Java System Access Manager 7 2005Q4 Administration Guide.

A second XML file, amDisco_add.xml is in /AccessManager-base/SUNWam/upgrade/services50_sunIdentityServerDiscoveryService/10_20/data. This file is used for upgrading Identity Server 6.2 to Access Manager 6.3. It lists the changes to the amDisco.xml file since the Identity Server release.

Discovery Service APIs

Access Manager contains several Java packages that are used by the Discovery Service. They include:

• com.sun.identity.liberty.ws.disco Package

• com.sun.identity.liberty.ws.disco.plugins Package

• com.sun.identity.liberty.ws.interfaces Package

Additional information is in Discovery Service APIs and the Java API Reference in /AccessManager-base/SUNWam/docs or on docs.sun.com. Information about the com.sun.identity.liberty.ws.common package is in Common Service Interfaces in Chapter 10, Application Programming Interfaces.

com.sun.identity.liberty.ws.disco Package

This package includes a client API that provides interfaces developers can use to communicate with the Discovery Service.

com.sun.identity.liberty.ws.disco.plugins Package

This package includes an interface that can be used to develop plug-ins. The package also contains some default plug-ins.

com.sun.identity.liberty.ws.interfaces Package

This package includes interfaces that can be used to implement functionality common to all Liberty-enabled identity services. Several implementations of these interfaces have been developed for the Discovery Service.

Discovery Service Architecture

The Access Manager Discovery Service includes Java and web services-based interfaces. Java applications use the client API (discussed in Client APIs in com.sun.identity.liberty.ws.disco) to form requests sent to the Discovery Service and to parse the responses received back from it. Requests are received by the Access Manager SOAP receiver, which constructs a SOAP message that incorporates the client request.

The Access Manager SOAP Binding Service defines how to send and receive messages using SOAP, an XML-based messaging protocol. The SOAP receiver is a servlet that constructs the message using these definitions. For more information, see Chapter 8, SOAP Binding Service.

The SOAP message is then sent to the Discovery Service, which parses a discovery resource identifier from it. This identifier is used to find a matching user DN. The necessary information is then culled from the corresponding profile, a response is generated, and the response is sent back to the SOAP receiver. The SOAP receiver then sends the response back to the client. The following figure illustrates this architecture.

Figure 7–1 Discovery Service Architecture

Discovery Service Process

The following figure provides a high-level overview of the interaction between parties in a web services environment using the Discovery Service. In this scenario, the identity provider hosts the Discovery Service. The process is defined in more detail after the figure.

Figure 7–2 Participants and Process of the Discovery Service

1. The user logs in to a Liberty-enabled identity provider, is authenticated, and completes the introduction process, enabling single sign-on with other members of the authentication domain. More specifically, this is the process:

   1. Within a browser, the user types the URL for a Liberty-enabled 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 an authentication domain, that provider will notify the authenticated user of the option to federate any local identities created with member organizations. The user would then accept or decline this invitation to federate. By accepting the invitation, the user will be given the option of federation to a member organization’s web site at each login. If the user accepts this option to federate, single sign-on is enabled.

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

3. The service provider sends a lookup query to the Discovery Service.

   Information used by a client to contact Discovery Service is culled from the authentication statement.

4. The Discovery Service returns a discovery lookup response to the service provider.

   The lookup response contains the resource offering (defining an association between a piece of identity data and the service instance that provides access to it) for the user’s Personal Profile Service.

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

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

6. The Personal Profile Service instance returns a Data Services Template response after collecting all required data.

   The Personal Profile Service authenticates and validates authorization, or policy, or both for the requested user and service provider. If user interaction is required for some attributes, the Interaction Service will be invoked to query the user for consents or for attribute values.

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

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

Discovery Service Attributes

The Discovery Service attributes are global attributes whose values are applied across the Access Manager configuration and inherited by every configured organization.

For information about the types of attributes used in Access Manager, see the Sun Java System Access Manager 7 2005Q4 Technical Overview.

The Discovery Service attributes are:

• Provider ID

• Supported Authentication Mechanisms

• Supported Directives

• Enable Policy Evaluation for DiscoveryLookup

• Enable Policy Evaluation for DiscoveryUpdate

• Authorizer Plugin Class

• Entry Handler Plugin Class

• Classes For ResourceIDMapper Plugin

• Authenticate Response Message

• Generate SessionContextStatement for Bootstrapping

• Encrypt NameIdentifier in Session Context for Bootstrapping

• Use Implied Resource; don’t generate ResourceID for Bootstrapping

• Resource Offerings for Bootstrapping Resources

Provider ID

This attribute takes a URI that points to the Discovery Service. Use the format protocol://host:port/amserver/Liberty/disco. This value can be changed only if other relevant attributes values are changed to match the new location.

Supported Authentication Mechanisms

This attribute specifies the authentication methods supported by the Discovery Service. These security mechanisms refer to the way a web service consumer authenticates to the web service provider or provides message-level security. By default, all available methods are selected. If an authentication method is not selected and a web services consumer (WSC) sends a request using that method, the request is rejected.

Supported Directives

This attribute allows you to specify a policy-related directive for a resource. If a service provider wants to use an unsupported directive, the request will fail. The following table describes the available options.

Enable Policy Evaluation for DiscoveryLookup

If enabled, the service will perform a policy evaluation for the DiscoveryLookup operation. By default, the check box is not selected.

Enable Policy Evaluation for DiscoveryUpdate

If enabled, the service will perform a policy evaluation for the DiscoveryUpdate operation. By default, the check box is not selected.

Authorizer Plugin Class

The value of this attribute is the name and path to the class that implements the com.sun.identity.liberty.ws.interfaces.Authorizer interface used for policy evaluation of a WSC. The default class is com.sun.identity.liberty.ws.disco.plugins.DefaultDiscoAuthorizer.

Entry Handler Plugin Class

The value of this attribute is the name and path to the class that implements the com.sun.identity.liberty.ws.disco.plugins.DiscoEntryHandler interface. This interface is used to set or retrieve a principal’s discovery entries. To handle discovery entries differently, implement the com.sun.identity.liberty.ws.disco.plugins.DiscoEntryHandler interface and set the implementing class as the value for this attribute. The default implementation for the Discovery Service is com.sun.identity.liberty.ws.disco.plugins.UserDiscoEntryHandler.

Classes For ResourceIDMapper Plugin

The value of this attribute is a list of classes that generate identifiers for a resource offering configured for an organization or role. com.sun.identity.liberty.ws.interfaces.ResourceIDMapper is an interface used to map a user identifier to the resource identifier associated with it. The Discovery Service provides two implementations for this interface:

• com.sun.identity.liberty.ws.disco.plugins.Default64ResourceIDMapper assumes the format to be providerID + "/" + the Base64 encoded userIDs

• com.sun.identity.liberty.ws.disco.plugins.DefaultHexResourceIDMapper assumes the format to be providerID + "/" + the hex string of userIDs

Different implementations may also be developed with the interface and added as a value of this attribute by clicking New and defining the following attributes:

• Provider ID takes as a value a URI that points to the Discovery Service. Use the format http://host:port/amserver/Liberty/disco. See Provider ID.

• ID Mapper takes as a value the class name and path of the implementing class.

Authenticate Response Message

If enabled, the service authenticates the response message. By default, the function is not enabled.

Generate SessionContextStatement for Bootstrapping

If enabled, this attribute specifies whether to generate a SessionContextStatement for bootstrapping. A SessionContextStatement conveys the session status of an entity. By default, this function is not enabled.

Encrypt NameIdentifier in Session Context for Bootstrapping

If enabled, the service encrypts the name identifier in a SessionContextStatement. By default, this function is not enabled.

Use Implied Resource; don’t generate ResourceID for Bootstrapping

If enabled, the service does not generate a resource identifier for bootstrapping. By default, this function is not enabled.

Resource Offerings for Bootstrapping Resources

This attribute defines a resource offering for bootstrapping a service. After single sign-on (SSO), this resource offering and its associated credentials will be sent to the client in the SSO assertion. Only one resource offering is allowed for bootstrapping. By default, this offering contains information about the Discovery Service. For more information, see Discovery Entries and Resource Offerings.

The value of the Resource Offerings for Bootstrapping Resources attribute is a default value configured during installation. If you want to define a new resource offering, you must first delete the existing resource offering, then click New to define the attributes. If you want to edit an existing resource offering, click the name of the existing Service Type to modify the attributes.

Discovery Entries and Resource Offerings

In Access Manager, a discovery entry can be stored as a user attribute or as a dynamic attribute. When storing a discovery entry as a user attribute, one user account has one discovery resource that can include zero or more resource offerings. Storing resource offerings within a user profile supports both entry lookups and updates. When storing a discovery entry as a dynamic attribute, the entry can be assigned to a realm or a role. This scenario only supports entry lookups using the discovery protocol. More information is provided in the following sections:

• Storing Discovery Entries as User Attributes

• Storing Discovery Entries as Dynamic Attributes

• Storing Discovery Entries for Bootstrapping

Storing Discovery Entries as User Attributes

Discovery entries can be stored as a user attribute under a user’s distinguished name (DN) using the Lightweight Directory Access Protocol (LDAP). Storing resource offerings within a user profile supports both entry lookups and updates. The following procedure explains how to access and create a user’s resource offerings.

To Access and Create a User's Resource Offerings

1. In the Access Manager Console, click the Access Control tab.

2. Select the name of the realm that contains the user you want to modify.

3. Select Subjects to access user information.

4. Select the name of the user profile that you want to modify.

5. Select Services to access the user's services.

6. Click Add to configure the Discovery Service for this user.

7. Select Discovery Service and click Next.

   The Discovery Service is added to the user's services.

8. Select General to access the user's User Discovery Resource Offering attribute.

9. Click Edit.

   A User Discovery Resource Offering window opens.

10. Click Add in the User Discovery Resource Offering window.

11. (Optional) Type a value for the Resource ID Attribute.

    This field defines an identifier for the resource offering.

12. Type the Resource ID Value.

    This field defines the resource identifier. A resource identifier is a URI registered with the Discovery Service that point to a particular discovery resource. It is generated by the profile provider. The value of this attribute must not be a relative URI and should contain a domain name that is owned by the provider hosting the resource. If a discovery resource is exposed in multiple Resource Offerings, the Resource ID Value for all of those resource offerings would be the same. An example of a valid Resource ID value is http://profile-provider.com/profiles/14m0B82k15csaUxs.

    ---

    Tip –

    urn:libery:isf:implied-resource can be used as a Resource ID Value when only one resource can be operated upon at the service instance being contacted. The URI only implicitly identifies the resource in question. In some circumstances, the use of this resource identifier can eliminate the need for contacting the discovery service to access the resource.

    ---

13. (Optional) Enter a description of the resource offering in the Description field.

14. Type a URI for the value of the Service Type attribute.

    This URI defines the type of service. It is recommended that the value of this attribute be the targetNamespace URI defined in the abstract WSDL description for the service. An example of a valid URI is urn:liberty:id-sis-pp:2003-08.

15. Type a URI for the value of the Provider ID attribute.

    This attribute contains the URI of the provider of the service instance. This information is useful for resolving trust metadata needed to invoke the service instance. A single physical provider may have multiple provider IDs. An example of a valid URI is http://profile-provider.com.

    ---

    Note –

    The provider represented by the URI in the Provider ID attribute must also have a class entry in the ResourceIDMapper attribute. For more information, see Classes For ResourceIDMapper Plugin.

    ---

16. Click Add Description to define the Service Description.

    For each resource offering, at least one service description must be created.

    1. Select the values for the Security Mechanism ID attribute to define how a web service client can authenticate to a web service provider.

       This field lists the security mechanisms that the service instance supports. Select the security mechanisms that you want to add and click Add. To prioritize the list, select the mechanism and click Move Up or Move Down.

    2. Type a value for the End Point URL.

       This value is the URL of the SOAP-over-HTTP endpoint. The URI scheme must be HTTP or HTTPS as in https://soap.profile-provider.com/soap.

    3. (Optional) Type a value for the SOAP Action.

       This value is the equivalent of the wsdlsoap:soapAction attribute of the wsdlsoap:operation element in the service's concrete WSDL-based description.

    4. Click OK to complete the configuration.

17. Check the Options box if there are no options or add a URI to specify options for the resource offering.

    This field lists the options that are available for the resource offering. Options provide hints to a potential requestor about the availability of certain data or operations to a particular offering. The set of possible URIs are defined by the service type, not the Discovery Service. If no option is specified, the service instance does not display any available options. For a standard set of options, see the Liberty ID-SIS Personal Profile Service Specification.

18. Select a directive for the resource offering.

    Directives are special entries defined in SOAP headers that can be used to enforce policy-related decisions. You can choose from the following:

    • GenerateBearerToken specifies that a bearer token be generated.

    • AuthenticateRequester must be used with any service description that use SAML for message authentication.

    • EncryptResourceID specifies that the Discovery Service encrypt the resource ID.

    • AuthenticateSessionContext is specified when a Discovery Service provider includes a SAML assertion containing a SessionContextStatement in any future QueryResponse messages.

    • AuthorizeRequester is specified when a Discovery Service provider wants to include a SAML assertion containing a ResourceAccessStatement in any future QueryResponse messages.

    If you want to associate a directive with one or more service descriptions, select the check box for that Description ID. If no service descriptions are selected, the directive is applied to all description elements in the resource offering.

19. Click OK.

20. Click Close to close the User Discovery Resource Offering window.

21. Click Save to save the configuration.

Storing Discovery Entries as Dynamic Attributes

Due to the repetition inherent in storing discovery entries as user attributes, Access Manager has established the option of storing a discovery entry as a dynamic attribute within a role or a realm. The role or realm can then be assigned to an identity-related object, making the entry available to all users within the object. Unlike storing a discovery entry as a user attribute, this scenario only supports entry lookups, not updates.

For more information about services, see the Sun Java System Access Manager 7 2005Q4 Administration Guide.

There are two ways in which you can store discovery entries as dynamic attributes. You can store them in a realm or in a role. The following sections describe the procedures:

• To Store Discovery Entries as Dynamic Attributes in a Realm

• To Store Discovery Entries as Dynamic Attributes in a Role

To Store Discovery Entries as Dynamic Attributes in a Realm

To create a discovery entry as a dynamic attribute in a realm, the Discovery Service must first be added and a template created.

1. In the Access Manager Console, click the Access Control tab.

2. Select the name of the realm you want to modify.

3. Select Services to access the realm's services.

4. Click Add to add the Discovery Service to the realm.

   A list of available services is displayed.

5. Select Discovery Service and click Next to add the service.

   A list of added services is displayed including the Discovery Service.

6. Select Subjects to access user information.

7. Select the name of the user you want to modify.

8. Select Services to add the Discovery Service to the user.

9. Click Add to add the Discovery Service to the user.

   A list of available services is displayed.

10. Select Discovery Service and click Next to add the service.

    A list of added services is displayed including the Discovery Service.

11. Using the path displayed on top of the Access Manager Console, click Edit Realm.

12. Click Services to access the realm's services.

13. Select Discovery Service to add a resource offering to the service.

14. Click Add.

15. (Optional) Enter a description of the resource offering in the Description field.

16. Type a URI for the value of the Service Type attribute.

    This URI defines the type of service. It is recommended that the value of this attribute be the targetNamespace URI defined in the abstract WSDL description for the service. An example of a valid URI is urn:liberty:id-sis-pp:2003-08.

17. Type a URI for the value of the Provider ID attribute.

    The value of this attribute contains the URI of the provider of the service instance. This information is useful for resolving trust metadata needed to invoke the service instance. A single physical provider may have multiple provider IDs. An example of a valid URI is http://profile-provider.com.

    ---

    Note –

    The provider represented by the URI in the Provider ID attribute must also have an entry in the ResourceIDMapper attribute. For more information, see Classes For ResourceIDMapper Plugin.

    ---

18. Click Add Description to define the Service Description.

    For each resource offering, at least one service description must be created.

    1. Select the values for the Security Mechanism ID attribute to define how a web service client can authenticate to a web service provider.

       This field lists the security mechanisms that the service instance supports. Select the security mechanisms that you want to add and click Add. To prioritize the list, select the mechanism and click Move Up or Move Down.

    2. Type a value for the End Point URL.

       This value is the URL of the SOAP-over-HTTP endpoint. The URI scheme must be HTTP or HTTPS as in https://soap.profile-provider.com/soap.

    3. (Optional) Type a value for the SOAP Action.

       This value is the equivalent of the wsdlsoap:soapAction attribute of the wsdlsoap:operation element in the service's concrete WSDL-based description.

    4. Click OK to complete the configuration.

19. Check the Options box if there are no options or add a URI to specify options for the resource offering.

    This field lists the options that are available for the resource offering. Options provide hints to a potential requestor about the availability of certain data or operations to a particular offering. The set of possible URIs are defined by the service type, not the Discovery Service. If no option is specified, the service instance does not display any available options. For a standard set of options, see the Liberty ID-SIS Personal Profile Service Specification.

20. Select a directive for the resource offering.

    Directives are special entries defined in SOAP headers that can be used to enforce policy-related decisions. You can choose from the following:

    • GenerateBearerToken specifies that a bearer token be generated.

    • AuthenticateRequester must be used with any service description that use SAML for message authentication.

    • EncryptResourceID specifies that the Discovery Service encrypt the resource ID.

    • AuthenticateSessionContext is specified when a Discovery Service provider includes a SAML assertion containing a SessionContextStatement in any future QueryResponse messages.

    • AuthorizeRequester is specified when a Discovery Service provider wants to include a SAML assertion containing a ResourceAccessStatement in any future QueryResponse messages.

    If you want to associate a directive with one or more service descriptions, select the check box for that Description ID. If no service descriptions are selected, the directive is applied to all description elements in the resource offering.

21. Click OK.

22. Click Close to close the Discovery Resource Offering window.

23. Click Save to save the configuration.

To Store Discovery Entries as Dynamic Attributes in a Role

To create a discovery entry as a dynamic attribute in a role, the Discovery Service must first be added and a template created.

1. In the Access Manager Console, click the Access Control tab.

2. Select the name of the realm you want to modify.

3. Select Subjects to access the realm's identity information.

4. Select Role to access the realm's role information.

5. Select the name of the role you want to modify.

   Alternately, you can create a new role and then select the name of this new role.

6. Under Services, click Add to add the Discovery Service to the role.

   A list of available services is displayed.

7. Select Discovery Service and click Next to add the service.

   A list of added services is displayed including the Discovery Service.

8. Select Discovery Service to add a resource offering to the service.

9. Click Add.

10. (Optional) Enter a description of the resource offering in the Description field.

11. Type a URI for the value of the Service Type attribute.

    This URI defines the type of service. It is recommended that the value of this attribute be the targetNamespace URI defined in the abstract WSDL description for the service. An example of a valid URI is urn:liberty:id-sis-pp:2003-08.

12. Type a URI for the value of the Provider ID attribute.

    The value of this attribute contains the URI of the provider of the service instance. This information is useful for resolving trust metadata needed to invoke the service instance. A single physical provider may have multiple provider IDs. An example of a valid URI is http://profile-provider.com.

    ---

    Note –

    The provider represented by the URI in the Provider ID attribute must also have an entry in the ResourceIDMapper attribute. For more information, see Classes For ResourceIDMapper Plugin.

    ---

13. Click Add Description to define the Service Description.

    For each resource offering, at least one service description must be created.

    1. Select the values for the Security Mechanism ID attribute to define how a web service client can authenticate to a web service provider.

       This field lists the security mechanisms that the service instance supports. Select the security mechanisms that you want to add and click Add. To prioritize the list, select the mechanism and click Move Up or Move Down.

    2. Type a value for the End Point URL.

       This value is the URL of the SOAP-over-HTTP endpoint. The URI scheme must be HTTP or HTTPS as in https://soap.profile-provider.com/soap.

    3. (Optional) Type a value for the SOAP Action.

       This value is the equivalent of the wsdlsoap:soapAction attribute of the wsdlsoap:operation element in the service's concrete WSDL-based description.

    4. Click OK to complete the configuration.

14. Check the Options box if there are no options or add a URI to specify options for the resource offering.

    This field lists the options that are available for the resource offering. Options provide hints to a potential requestor about the availability of certain data or operations to a particular offering. The set of possible URIs are defined by the service type, not the Discovery Service. If no option is specified, the service instance does not display any available options. For a standard set of options, see the Liberty ID-SIS Personal Profile Service Specification.

15. Select a directive for the resource offering.

    Directives are special entries defined in SOAP headers that can be used to enforce policy-related decisions. You can choose from the following:

    • GenerateBearerToken specifies that a bearer token be generated.

    • AuthenticateRequester must be used with any service description that use SAML for message authentication.

    • EncryptResourceID specifies that the Discovery Service encrypt the resource ID.

    • AuthenticateSessionContext is specified when a Discovery Service provider includes a SAML assertion containing a SessionContextStatement in any future QueryResponse messages.

    • AuthorizeRequester is specified when a Discovery Service provider wants to include a SAML assertion containing a ResourceAccessStatement in any future QueryResponse messages.

    If you want to associate a directive with one or more service descriptions, select the check box for that Description ID. If no service descriptions are selected, the directive is applied to all description elements in the resource offering.

16. Click OK.

17. Click Close to close the Discovery Resource Offering window.

18. Click Save to save the configuration.

Storing Discovery Entries for Bootstrapping

Before a WSC can contact the Discovery Service for a resource offering, the WSC needs to find the Discovery Service. Thus, an initial resource offering for locating the Discovery Service is sent back to the WSC in a single sign-on assertion. The following procedure describes how to configure a global attribute for bootstrapping the Discovery Service. Unlike storing a discovery entry as a user attribute, this scenario only supports entry lookups, not updates.

To Store Discovery Entries for Bootstrapping

1. In the Access Manager Console, select the Web Services tab.

2. Under Web Services, click the Discovery Service tab.

3. Choose New under the Resource Offerings for Bootstrapping Resources attribute.

   By default, the resource offering for bootstrapping the Discovery Service is already configured. In order to create a new resource offering, you must first delete the default resource offering.

4. (Optional) Type a description of the resource offering.

5. Enter a URI for the value of the Service Type attribute.

   This field defines the type of service. It is recommended that the value of this attribute be the targetNamespace URI defined in the abstract WSDL description for the service. An example of a valid URI is urn:liberty:disco:2003-08.

6. Enter a URI for the value of the Provider ID attribute.

   This attribute contains the URI of the provider of the service instance. This is useful for resolving trust metadata needed to invoke the service instance. A single physical provider may have multiple provider IDs. An example of a valid URI is http://sample_disco.com.

   ---

   Note –

   The provider represented by the URI in the Provider ID attribute must also have an entry in the Classes for ResourceIDMapper Plugin attribute. For more information, see Classes For ResourceIDMapper Plugin.

   ---

7. Click Add Description to define a security mechanism ID.

   For each resource offering, at least one service description must be created.

   1. Select the values for the Security Mechanism ID attribute to define how a web service client can authenticate to a web service provider.

      This field lists the security mechanisms that the service instance supports. Select the security mechanisms you wish to add and click the Add button. To arrange the priority of the list, select the mechanism and use the Move Up or Move Down buttons.

   2. Type a value for the End Point URL.

      This value is the URL of the SOAP-over-HTTP endpoint. The URI scheme must be HTTP or HTTPS as in https://soap.profile-provider.com/soap.

   3. (Optional) Type a value for the SOAP action.

      This field contains the equivalent of the wsdlsoap:soapAction attribute of the wsdlsoap:operation element in the service's concrete WSDL-based description.

   4. Click OK to save the configuration.

8. Check the Options box if there are no options or add a URI to specify options for the resource offering.

   This field lists the options that are available for the resource offering. Options provide hints to a potential requestor about the availability of certain data or operations to a particular offering. The set of possible URIs are defined by the service type, not the Discovery Service. If no option is specified, the service instance does not display any available options. For a standard set of options, see the Liberty ID-SIS Personal Profile Service Specification.

9. Select a directive for the resource offering.

   Directives are special entries defined in SOAP headers that can be used to enforce policy-related decisions. You can choose from the following:

   • GenerateBearerToken specifies that a bearer token be generated.

   • AuthenticateRequester must be used with any service description that use SAML for message authentication.

   • EncryptResourceID specifies that the Discovery Service encrypt the resource ID.

   • AuthenticateSessionContext is specified when a Discovery Service provider includes a SAML assertion containing a SessionContextStatement in any future QueryResponse messages.

   • AuthorizeRequester is specified when a Discovery Service provider wants to include a SAML assertion containing a ResourceAccessStatement in any future QueryResponse messages.

   If you want to associate a directive with one or more service descriptions, select the check box for that Description ID. If no service descriptions are selected, the directive is applied to all description elements in the resource offering.

10. Click OK to complete the configuration.

Discovery Service APIs

By default, a discovery service is implemented as one of the identity web services in Access Manager. The Discovery Service APIs provide the following implementations and interfaces:

• com.sun.identity.liberty.ws.interfaces.Authorizer Interface

• com.sun.identity.liberty.ws.interfaces.ResourceIDMapper Interface

• com.sun.identity.liberty.ws.disco.plugins.DiscoEntryHandler Interface

• Client APIs in com.sun.identity.liberty.ws.disco

com.sun.identity.liberty.ws.interfaces.Authorizer Interface

This interface is used to enable an identity service to check the authorization of a WSC. The DefaultDiscoAuthorizer class is the default implementation of this interface. The class uses the Access Manager Policy Service for creating and applying policy definitions.

The Policy Service looks for an SSOToken defined for Authenticated Users or Web Service Clients. For more information on this and the Policy Service in general, see the Sun Java System Access Manager 7 2005Q4 Administration Guide.

Policy definitions for the Discovery Service are configured using the Access Manager Console. The procedure is as follows.

To Configure Policy Definitions

1. In the Access Manager Console, click the Access Control tab.

2. Select the name of the realm in which the policy definitions will be configured.

3. Select Policies to access policy configurations.

4. Click New Policy to add a new policy definition.

5. Type a name for the policy.

6. (Optional) Enter a description for the policy.

7. (Optional) Select the check box next to Active.

8. Click New to add rules to the policy definition.

9. Select Discovery Service for the rule type and click Next.

10. Type a name for the rule.

11. Type a resource on which the rule acts.

    The Resource Name field uses the form ServiceType + RESOURCE_SEPARATOR + ProviderID. For example, urn:liberty:id-sis-pp:2003-08;http://example.com.

12. Select an action and appropriate value for the rule.

    Discovery Service policies can only look up or update data.

13. Click Finish to configure the rule.

    The com.sun.identity.liberty.ws.interfaces.Authorizer interface can be implemented by any web service in Access Manager. For more information, see Common Service Interfaces and the Java API Reference in /AccessManager-base/SUNWam/docs or on docs.sun.com.

14. Click New to add subjects to the policy definition.

15. Select the subject type and click Next.

16. Type a name for the group of subjects.

17. (Optional) Click the check box if this is an exclusive group.

18. Select the users and click to add them to the group.

19. Click Finish to return to the policy definition screen.

20. Click New to add conditions to the policy definition.

21. Select the condition type and click Next.

22. Type values for the displayed attributes.

    For more information, see the Sun Java System Access Manager 7 2005Q4 Administration Guide.

23. Click Finish to return to the policy definition screen.

24. Click New to add response providers to the policy definition.

25. Type a name for the response provider.

26. (Optional) Add values for the StaticAttribute.

27. (Optional) Add values for the DynamicAttribute.

28. Click Finish to return to the policy definition screen.

29. Click Create to finish the policy configuration.

com.sun.identity.liberty.ws.interfaces.ResourceIDMapper Interface

This interface is used to map a user ID to the resource identifier associated with it. Access Manager provides two implementations of this interface.

• com.sun.identity.liberty.ws.disco.plugins.Default64ResourceIDMapper assumes the format to be providerID + "/" + the Base64 encoded userIDs

• com.sun.identity.liberty.ws.disco.plugins.DefaultHexResourceIDMapper assumes the format to be providerID + "/" + the hex string of userIDs

A different implementation of the interface may be developed. The implementation class should be given to the provider that hosts the Discovery Service. The mapping between the providerID and the implementation class can be configured through the Classes For ResourceIDMapper Plugin attribute.

The com.sun.identity.liberty.ws.interfaces.ResourceIDMapper interface is common to all identity services in Access Manager not only the Discovery Service. For more information, see Common Service Interfaces and the Java API Reference in /AccessManager-base/SUNWam/docs or on docs.sun.com.

com.sun.identity.liberty.ws.disco.plugins.DiscoEntryHandler Interface

This interface is used to get and set discovery entries for a user. A number of default implementations are provided, but if you want to handle this function differently, implement this interface and set the implementing class as the value of the Entry Handler Plugin Class attribute as discussed in Entry Handler Plugin Class. The default implementations of this interface are described in the following table.

Client APIs in com.sun.identity.liberty.ws.disco

The following table summarizes the client APIs in the package com.sun.identity.liberty.ws.disco. For more information, including methods and their syntax and parameters, see the Java API Reference in /AccessManager-base/SUNWam/docs or on docs.sun.com.

Discovery Service Sample

A sample that shows the process for querying and modifying the Discovery Service is included with Access Manager in the /AccessManager-base/SUNWam/samples/phase2/wsc directory. The sample initially shows how to deploy and run a WSC. The final portion queries the Discovery Service and modifies identity data in the Liberty Personal Profile Service. For more information, see Appendix A, Liberty-based and SAML Samples.

Chapter 8 SOAP Binding Service

Sun Java System Access Manager contains an implementation of the Liberty ID-WSF SOAP Binding Specification from the Liberty Alliance Project. The specification defines a transport layer for sending and receiving SOAP messages.

This chapter covers the following topics:

• SOAP Binding Service Overview

• SOAP Binding Process

• SOAP Binding Service Attributes

• SOAP Binding Service Package

SOAP Binding Service Overview

The Liberty Identity Web Services Framework (Liberty ID-WSF) and Liberty Identity Service Interface Specifications (Liberty ID-SIS) components of the Liberty Alliance Project specifications use messages to convey identity data between providers. Access Manager has implemented the Liberty ID-WSF SOAP Binding Specification (Liberty ID-WSF-SBS) as the method of transport for this purpose. The specification defines SOAP as the binding to the Hypertext Transport Protocol (HTTP), which is itself layered onto the TCP/IP stack.

For more information, see the Liberty ID-WSF SOAP Binding Specification.

XML Service File

The Access Manager SOAP Binding Service is defined using the XML service file amSOAPBinding.xml. This file defines the attributes for the SOAP Binding Service which can be managed through the Access Manager Console or the XML file.

For more information on service files, see the Sun Java System Access Manager 7 2005Q4 Administration Guide.

The Liberty ID-WSF-SBS also defines an XML schema for use in building the SOAP messages. This XML Schema Definition (XSD) file is on the Liberty Alliance Project web site. Version 1.0 is also reproduced in Appendix B, Service Schema Files.

SOAP Binding Service APIs

The Access Manager SOAP Binding Service includes a Java package named com.sun.identity.liberty.ws.soapbinding. For more information about these interfaces, see SOAP Binding Service Package.

SOAP Binding Process

In the SOAP Binding process, an identity service calls the client-side application programming interface (API) to construct a message and send it to the SOAP endpoint URL. The URL is, in effect, a servlet that receives and processes SOAP messages.

The Discovery Service, implemented Data Services Template services (including the Liberty Personal Profile Service and the sample Employee Profile Service), and the Authentication Web Service use the SOAP Binding Service client API.

The SOAP Receiver servlet receives the message, verifies the signature, and constructs a second message. The SOAP Receiver servlet then invokes the correct request handler class to send this second message to the corresponding service for a response.

com.sun.identity.liberty.ws.soapbinding.RequestHandler is an interface that must be implemented on the server side by any Liberty-based web service using the SOAP Binding Service. For more information, see Request Handler List.

The service processes the second message, generates a response, and sends that response back to the SOAP Receiver servlet. The SOAP receiver, in turn, sends the response back to the service for processing.

Before invoking a corresponding service, the SOAP framework might also do the following:

• Authenticate the sender identity to verify the credentials of a WSC peer, probably by verifying its client certificate.

• Authenticate the invoking identity to verify the credentials of a WSC on behalf of a user to verify whether the user has been authenticated. This depends on the security authentication profile.

• Granular authorization to authorize the WSC before processing a service request.

SOAP Binding Service Attributes

The SOAP Binding Service attributes are global attributes. The values of these attributes are carried across the Access Manager configuration and inherited by every organization.

For information about the types of attributes used in Access Manager, see the Sun Java System Access Manager 7 2005Q4 Technical Overview.

Attributes for the SOAP Binding Service are defined in the amSOAPBinding.xml service file. The SOAP Binding Service attributes are as follows:

• Request Handler List

• Web Service Authenticator

• Supported Authentication Mechanisms

Request Handler List

The Request Handler List stores information about the classes implemented from the com.sun.identity.liberty.ws.soapbinding.RequestHandler interface. The SOAP Binding Service provides the interface to process requests and return responses. It must be implemented on the server side for each Liberty-based web service that uses the SOAP Binding Service.

The Discovery Service, implemented Data Services Template (DST) services (including the Liberty Personal Profile Service and the sample Employee Profile Service, if deployed), and the Authentication Web Service use the SOAP Binding Service client API.

To add a new implementation, click New and define values for the following parameters.

Key Parameter

The Key parameter is the last part of the URI path to a SOAP endpoint. The SOAP endpoint in Access Manager is the SOAP Receiver servlet. The URI to the SOAP Receiver uses the format protocol://host:port/deloy-uri/Liberty/key. If you define disco as the Key, the URI path to the SOAP endpoint for the corresponding Discovery Service would be protocol://host:port/amserver/Liberty/disco.

Different service clients use different keys when connecting to the SOAP Receiver.

Class Parameter

The Class parameter specifies the name of the class implemented from com.sun.identity.liberty.ws.soapbinding.RequestHandler for the particular web service. For example, class=com.example.identity.liberty.ws.disco.DiscoveryService.

SOAP Action Parameter

The optional SOAP Action can be used to indicate the intent of the SOAP HTTP request. The SOAP processor on the receiving system can use this information to determine the ultimate destination for the service. The value is a URI. No defined value indicates no intent.

SOAP places no restrictions on the format or specificity of the URI or that it is resolvable.

Web Service Authenticator

This attribute takes as a value the implementation class for the Web Service Authenticator interface. This class authenticates a request and generates a credential for a WSC.

This interface is not public. The value of the attribute is configured during installation.

Supported Authentication Mechanisms

This attribute specifies the authentication mechanisms supported by the SOAP Receiver. Authentication mechanisms offer user authentication as well as data integrity and encryption. By default, all available authentication mechanisms are selected. If a mechanism is not selected and a WSC sends a request using it, the request is rejected. Following is a list of the supported authentication mechanisms:

• urn:liberty:security:2003-08:null:null

• urn:liberty:security:2003-08:null:X509

• urn:liberty:security:2003-08:null:SAML

• urn:liberty:security:2004-04:null:Bearer

• urn:liberty:security:2003-08:TLS:null

• urn:liberty:security:2003-08:TLS:X509

• urn:liberty:security:2003-08:TLS:SAML

• urn:liberty:security:2004-04:TLS:Bearer

• urn:liberty:security:2003-08:ClientTLS:null

• urn:liberty:security:2003-08:ClientTLS:X509

• urn:liberty:security:2003-08:ClientTLS:SAML

• urn:liberty:security:2004-04:ClientTLS:Bearer

For more complete information about authentication mechanisms and their level of security, see the Liberty ID-WSF Security Mechanisms specification.

SOAP Binding Service Package

The Access Manager SOAP Binding Service includes a Java package named com.sun.identity.liberty.ws.soapbinding. This package provides classes to construct SOAP requests and responses and to change the contact point for the SOAP binding. The following table describes some of the available classes. For more detailed information, see the Java API Reference in /AccessManager-base/SUNWam/docs or on docs.sun.com.

See Appendix A, Liberty-based and SAML Samples for sample code and files to help you understand the implementation of the Liberty Alliance Project specifications.

See PAOS Binding for information on this reverse HTTP binding for SOAP.