test

Sun Java System Access Manager 7 2005Q4 Technical Overview

Federation Management Implemented in Access Manager

In Access Manager, the Federation Management feature enables applications to participate in three different frameworks:

These frameworks enable service providers to securely exchange authentication and authorization information. Client APIs are provided for web service consumers to communicate with web service providers. The following figure illustrates the internal architecture of a Liberty Web Services Consumer and a Web Service Provider.

Figure 5–2 Web Services Consumer and Web Service Provider Architecture

This figure illustrates the relationship between components in a Federation Management model.

The Web Service Consumer components and the Web Service Provider components are newly implemented components in Access Manager. The components in the bottom layer of the Web Service Provider were implemented in Access Manager 6.1. These components include Single-Sign On (SS0), the Access Manager SDK, Service Management Services, SAML, Authentication modules, and a Policy Service. In the Identity Web Service Framework, the Data Service and Identity Service represent custom services that you can add to the Web Services Framework.

Identity Federation Framework

The Identity Federation Framework (ID-FF) specifies core protocols, schema and concrete profiles that allow developers to create a standardized, multiple-vendor, identity federation network. These include the following:

Account linking termination.

Users can choose to stop their account federation.

Authentication context.

Service providers with federated accounts communicate the type and level of authentication that should be used when the user logs in.

Affiliation federation

Federation based on group affiliation 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 affiliation, and not the requesting provider. The process allows for a unique identifier that represents the affiliation.

Dynamic identity provider proxying

When one identity provider is asked to authenticate a principal that has already been authenticated by 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.

Identity provider introduction.

This feature provides the means for service providers to discover which identity providers a principal uses. A principal can be an organization or individual who interacts with the system. This is important when there are multiple identity providers in an identity federation network.

Name Identifier Mapping Protocol

Defines how service providers can obtain name identifiers assigned to a principal that has federated in the name space of a different service provider. When a principal that has an identity federation relationship (and therefore a name identifier) with one service provider requests access to a second service provider site that requires a name identifier, the second service provider can use this protocol to obtain the identifier. It allows the requesting service provider to communicate with the second service provider about the principal even though no identity federation for the principal exists between them.

Name Registration

Enables a service provider or identity provider to register with each other a new name identifier for a principal at any time following federation.

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.

Opt-in account linking

Users can choose to federate different service provider accounts.

Single Sign-on and Federation Protocol

The protocol that defines the process that a user at a service provider goes through to authenticate their identity with an identity provider. It also specifies the means by which a service provider obtains an Authentication Assertion from an identity provider to allow single sign-on to the user. Two types of Single Sign-On exist which either the identity or service provider can implement:

  • SOAP-based Single Sign On and Federation Protocol, which relies on a SOAP call from provider to provider. This is primarily the Browser Artifact SSO profile.

  • Form POST-based Single Sign On and Federation Protocol, which rely on an HTTP form POST to communicate between providers.

Single Sign-Out Protocol

The protocol used to synchronize the session log-out functionality across all sessions that were authenticated and created by a particular identity provider. Two types of protocols exist which either the identity or service provider can implement:

  • SOAP-based Single Log-Out Protocol relies on asynchronous SOAP messaging calls between providers.

  • HTTP Redirect-based Single Log-Out Protocol

Identity Web Services Framework

The Web Services Framework (ID-WSF) consists of a set of schema, protocols and profiles for providing a basic identity services, such as identity service discovery and invocation. Three parties are required for identity federation in a basic Liberty Web Services environment: a user agent, a web service consumer, and a web service provider.

The Web Services Framework consists of a set of schema, protocols and profiles for providing a basic identity services, such as identity service discovery and invocation. This framework includes the following:

Authentication Web Service

An identity service that enables a web service consumer to be authenticated using the Simple Authentication and Security Layer (SASL) mechanism. SASL defines a method for adding authentication support to connection-based protocols.

Discovery Service.

An identity service that allows a requester to discover resource offerings.

SOAP Binding.

A set of Java APIs for sending and receiving ID-* messages using SOAP and XML.

Security Mechanisms.

Defines a set of authentication mechanism and security properties which are factored into authorization decisions enforced by the targeting identity-based web services. Each mechanism contains both peer entity authentication (null/TLS/CClientTLS) and message authentication (null/X509/SAML).

Interaction Service.

A protocol for simple interaction of Web Services Framework participants with a Principal.

Trusted Authority.

APIs for creating security tokens used for authentication and authorization in Liberty II-enabled services.

Metadata Service.

A library of command-line tools for loading metadata into the Access Manager data store.

Reverse HTTP Bindings.

A protocol and set of APIs for retrieving data from Access Manager via clients such as cell phones.

SAML Service

SAML defines an eXtensible Markup Language (XML) framework to achieve interoperability across different vendor platforms that provide SAML assertions. SAML is an XML framework for exchanging security information over the Internet. Access Manager SAML Service consists of a web service interface, a SAML core component, and a SAML framework that web services can connect to.

The Access Manager SAML Service enables the following functionality: