Sun Java logo     Previous      Contents      Index      Next     

Sun logo
Sun Java Systems Access Manager 6 2005Q1 Federation Management Guide 

Chapter 2
Implementation of the Liberty Specifications

Sun Java™ System Access Manager contains Sun Microsystems’ implementation of the Liberty Alliance Project specifications. This chapter is an overview of how these specifications have been implemented. It contains the following sections:


Overview

Sun Java System Access Manager is a software product that helps organizations manage secure access to the resources and Web applications both within the company and across the Internet. The initial releases of Access Manager (formerly Sun™ ONE Identity Server) implemented the Liberty Alliance Project (LAP) Identity Federation Framework (ID-FF) specifications, focusing on account federation, authentication domains and single sign-on.


Note

The administration interface for managing the ID-FF implementation can be found in the Access Manager console by clicking the Federation Management tab in the Header frame.


Subsequently, Identity Server 2004Q2, added new features defined in version 1.2 of the ID-FF specifications as well as the version 1.0 specifications of the Liberty Identity Web Services Framework (ID-WSF). These Web services included a framework for the retrieval and update of identity data (attributes stored in identity-based Web services across the Internet), and a client application programming interface (API) for intracommunication between providers.


Note

The Web interface for the ID-WSF implementation can be found in the Access Manager console by clicking the Service Management tab in the Header frame. Implemented Liberty-based services are listed amongst the other Web services.


This release, Sun Java System Access Manager 2005Q1, continues the implementation of Liberty-based features. The following sections detail features added to this latest version of Access Manager 2005Q1.


Note

The full scope of Liberty Alliance Project features are discussed in Chapter 1, "Introduction to the Liberty Alliance Project."


Name Identifier Mapping Protocol

The new Name Identifier Mapping Protocol, a full protocol in the Liberty ID-FF Protocols and Schema Specifications (http://www.projectliberty.org/specs/draft-liberty-idff-protocols-schema-1.2-errata-v1.0.pdf), allows a service provider to obtain a name identifier for a principal that has federated in the name space of a different service provider. Implementing this protocol allows the requesting service provider to communicate with the second service provider without an identity federation having been enabled. The NameIdentifier Mapping Profile can be found in the Liberty ID-FF Bindings and Profiles Specification (http://www.projectliberty.org/specs/draft-liberty-idff-bindings-profiles-1.2-errata-v1.0.pdf).

Single Sign-on and Federation Protocol

The following sections detail changes to the Single Sign-on and Federation Protocol, part of the Liberty ID-FF Protocols and Schema Specifications (http://www.projectliberty.org/specs/draft-liberty-idff-protocols-schema-1.2-errata-v1.0.pdf).

Dynamic Identity Provider Proxying

Dynamic Identity Provider Proxying can be enabled in an authentication request. For example, one identity provider might be asked to authenticate a principal that has already been authenticated via a second identity provider. In this case, the first identity provider may request authentication information from the second identity provider on behalf of the service provider. Proxy behavior can be controlled by indicating a list of preferred identity providers, and a value that defines the maximum number of proxy steps that can be taken. Proxy behavior is defined locally by the proxying identity provider, although a service provider controls whether or not to proxy.

Affiliation Federation

Federation based on affiliation to a specified group can be enabled in an authentication request. If enabled, it would indicate that the requester is acting as a member of the affiliation group identified. Federations are then established and resolved based on the specified affiliation, and not the requesting provider. The process allows for a unique identifier that represents the affiliation.

One-Time Federation

The ability to federate for one session only can be enabled in an authentication request. This is useful for service providers with no user accounts, for principals who wish to act anonymously, or for dynamically-created user accounts. It allows for one-time federation, rather than a one-time name identifier for a session.

Name Identifier Encryption Profile

The Name Identifier Encryption profile allows for a principal’s name identifier to be encrypted so that only the provider possessing the decryption key can realize the identity. The encrypted identifier is a different value when requested by different providers or multiple times, reducing the chance for correlation of the encrypted value across multiple logical transactions. The Name Identifier Encryption Profile can be found in the Liberty ID-FF Bindings and Profiles Specification (http://www.projectliberty.org/specs/draft-liberty-idff-bindings-profiles-1.2-errata-v1.0.pdf).

Liberty Metadata Description and Discovery Specification

The Liberty Metadata Description and Discovery Specification, one of the Liberty Alliance Support Documents, (http://www.projectliberty.org/specs/draft-liberty-metadata-1.0-errata-v1.0.pdf) has been upgraded to reflect added profiles, to support identity provider and service provider descriptors in the same metadata XML file, and to query metadata over the DNS.


Note

Due to changes in the Liberty Metadata specification, the Service Management (SM) Configuration schema in Identity Server 6.2 is not compatible with that in Identity Server 6.1. SM versioning will be used to support coexistence of the two when running against an instance of Sun Java System Directory Server. When upgrading from Identity Server 6.1 to 6.2, metadata migration is required.



Liberty Use Cases

Identity data consists of all the information that companies capture and maintain about individual customers, corporate partners, and employees. Federating sources of identity data allows for accessing, transporting, sharing, and managing the data across and between partnered organizations and applications without weakening existing security safeguards. Federation management establishes this unifying network from multiple data stores. There are many ways to use Access Manager and its Liberty-based implementations to federate sources of identity data. The following sections detail just a few ways in which the product can be used.

Unified Access to Intranet Resources

Many corporations provide access to outsourced human resources services, such as health benefits and 401K plans. The corporate intranet offers central access to these services, but employees have to log-in and authenticate themselves every time they access each service. Employees may not want to share the same profile and password with both their 401K provider and their healthcare provider. Federation of identity data can also provide seamless integration of Web resources across multiple security domains within the same enterprise making employee ease-of-use and control possible.

Integrated Partner Networks

Enterprises can construct a network of partnered services for securely exchanging customer account information, transaction data, and credentials via a set of interoperable Web services. Federating among partner networks allows identities to share key pieces of their respective data without sharing control. For example, logging onto one Web site that represents an authentication domain consisting of an airline, a car rental company, and a hotel chain allows an identity to make travel plans even if one of the sites does not contain an identity data store.

Sample Use Case Process

Figure 2-1 illustrates the process of requesting a service and being authenticated for access. MyRingtones is a service provider in a federation framework that also acts as a Web service consumer in a Web services framework. MyWireless is an identity provider in a federation framework that contains access to the Discovery Service in a Web services framework. MyBank is a Web service provider in a Web services framework.


Note

The same Web service can act as a different entity in different frameworks.


The user attempts to access MyRingtones and, after being prompted for credentials stored in MyBank, receives authorization through MyWireless. Single sign-on is accomplished in the back-end, and the entire process is based on the implementations of the ID-FF, ID-WSF, and ID-SIS specifications of the LAP.

Figure 2-1  Process of Federation, Web Services & Service Instances Framework

A diagram that details the steps when requesting a service and being authenticated for access.


Access Manager Implementations

Access Manager is installed with a set of default Liberty-based Web services. They, and the larger Federation Management module, are introduced in the following sections.

Web Services

Liberty-based Web services (based on the Liberty Identity Web Services Framework) are accessible from the Access Manager console by clicking the Service Management tab in the Header frame. Implemented services are listed alphabetically among other Access Manager Web services. Figure 2-2 is a screen shot of this.

Figure 2-2  Web Services Listed in Access Manager Console

A screenshot of Liberty-based Web Services in the Access Manager console.

Authentication Web Service

The Authentication Web Service provides Web service-based authentication to a Web service consumer (WSC), allowing the WSC to obtain security tokens for further interactions with other services at the same provider. These other services may include a discovery service or single sign-on service. The implementation of the Access Manager Authentication Web Service is based on the Liberty Alliance Project (LAP) Authentication Service Specification. The Access Manager Authentication Web Service is for service-to-service (non-user) authentication. More information can be found in Chapter 4, "Authentication Web Service."


Caution

The Liberty-based Authentication Web Service is not to be confused with the proprietary Access Manager Authentication Service discussed in the Sun Java System Access Manager Developer’s Guide (http://docs.sun.com/doc/817-5710).


Discovery Service

The Discovery Service is an identity service that allows a requesting entity, such as a service provider, to dynamically determine a principal’s registered attribute provider. Typically, a service provider queries the Discovery Service, which responds by providing a resource offering describing the requested attribute provider. (A resource offering defines associations between a piece of identity data and the service instance that provides access to it.) The implementation of the Access Manager Discovery Service is based on the LAP Discovery Service Specification and includes Java and Web-based interfaces. More information can be found in Chapter 6, "Discovery Service."


Note

By definition, a discoverable service is assigned a service type URI (typically done in the specification defining the service) allowing their registration in Discovery Service instances.


Liberty Personal Profile Service

The Liberty Personal Profile Service is an identity service that supports the storage and modification of identity data attributes regarding principals. Identity data attributes might include information such as first name, last name, home address, and emergency contact information. The Liberty Personal Profile Service is queried or updated by a WSC acting on behalf of the principal. The implementation of the Access Manager Liberty Personal Profile Service is based on the LAP Personal Profile Service. More information can be found in Chapter 5, "Data Services."

SOAP Binding

The SOAP Binding is a set of Java APIs used by the developer of a Liberty-enabled identity service that describes how to send and receive identity-based messages using SOAP, an XML-based messaging protocol. The implementation of the Access Manager SOAP Binding Service is based on the LAP SOAP Binding Specification. More information can be found in Chapter 7, “SOAP Binding Service.”

Application Programming Interfaces

A number of the Liberty-based Web services specifications have also been implemented in the back end of the Access Manager product as APIs. They include the interaction service, and PAOS binding. More information can be found in Chapter 8, "Application Programming Interfaces."

Federation Management Module

The Federation Management module (based on the Liberty Identity Federation Framework) provides an interface for creating, modifying, and deleting authentication domains and, service and identity providers (both remote and hosted types) for a federated model. It is accessible through the Federation Management tab in the Header frame of the Access Manager console. Figure 2-3 is a screen shot of this.

Figure 2-3  Federation Management Module in Access Manager Console

A screenshot of the Federation Management module in the Access Manager console.

The following steps illustrate the basic procedure for creating a federation model.

  1. Create an authentication domain.
  2. Create one or more hosted providers that belong to the authentication domain.
  3. Create one or more remote providers that belong to the authentication domain. You must also include the metadata for the remote providers.
  4. Establish a trusted relationship between the providers. A hosted provider can choose to trust a subset of providers, either hosted or remote, that belong to the same authentication domain.

  5. Note

    The Federation Management module is the Web interface for the Access Manager implementation of the Liberty Identity Federation Framework.



Packages and Global Interfaces

Table 2-1 summarizes the public application programming interface (API) you can use to deploy Liberty-enabled components or extend the core services. For detailed API reference that includes classes, methods and their syntax and parameters, see the Javadocs in /AccessManager_base/SUNWam/docs.

Table 2-1  Summary of Liberty-based Packages

Package Name

Description

com.sun.identity.liberty.ws.common

Defines common classes used by many of the Access Manager Liberty-based Web service components. See Common Service Interfaces.

com.sun.identity.liberty.ws.common.wsse

Provides an interface to parse and create a X.509 Certificate Token Profile. See Interaction Service API.

com.sun.identity.liberty.ws.disco

Provides interfaces to manage the Discovery Service. See Chapter 6, "Discovery Service".

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

Provides a plugin interface for the Discovery Service. See Chapter 6, "Discovery Service".

com.sun.identity.liberty.ws.dst

Provides classes to implement an identity service on top of the Access Manager framework. The Data Services Template (DST) specification defines how to query and modify data stored in a data service, and provides some common attributes for the data services. From the implementation point of view, all the identity services must be built on top of the DST which provides the data model and message interfaces for all identity services. See Interaction Service API.

com.sun.identity.liberty.ws.interaction

Provides classes to support the Interaction RequestRedirect Profile. See Interaction Service API.

com.sun.identity.liberty.ws.interfaces

Provides interfaces common to all Access Manager Liberty-based Web service components. Common Service Interfaces.

com.sun.identity.liberty.ws.paos

Provides classes for Web applications to construct and process PAOS requests and responses. See PAOS Binding of Chapter 8, "Application Programming Interfaces."

com.sun.identity.liberty.ws.security

Provides interface to manage Liberty-based Web service security mechanisms. See Common Security API.

com.sun.liberty

Provides interfaces common to the Access Manager Federation Management module. See Federation Management API.


Liberty-based Samples

Access Manager has included sample code and files that can be used to understand the implementation of the LAP specifications. Information on the specifics of these samples can be found in Appendix A, "Included Samples."



Previous      Contents      Index      Next     


Part No: 817-7648.   Copyright 2005 Sun Microsystems, Inc. All rights reserved.