In Access Manager, the Federation Management feature enables applications to participate in three different frameworks:
Identity Federation Framework
Identity Web Services Framework
SAML 1.0 and 1.1 Specifications
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.
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.
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:
Users can choose to stop their account federation.
Service providers with federated accounts communicate the type and level of authentication that should be used when the user logs in.
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.
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.
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.
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.
Enables a service provider or identity provider to register with each other a new name identifier for a principal at any time following 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.
Users can choose to federate different service provider accounts.
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.
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
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:
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.
An identity service that allows a requester to discover resource offerings.
A set of Java APIs for sending and receiving ID-* messages using SOAP and XML.
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).
A protocol for simple interaction of Web Services Framework participants with a Principal.
APIs for creating security tokens used for authentication and authorization in Liberty II-enabled services.
A library of command-line tools for loading metadata into the Access Manager data store.
A protocol and set of APIs for retrieving data from Access Manager via clients such as cell phones.
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:
Users can authenticate against Access Manager and access trusted partner sites without having to reauthenticate. This single sign-on process independent of the process enabled by Access Manager user session management.
Access Manager acts as a policy decision point (PDP), allowing external applications to access user authorization information for the purpose of granting or denying access to their resources.
Access Manager acts as both an attribute authority (allowing trusted partner sites to query a subject’s attributes) and an authentication authority (allowing trusted partner sites to query a subject’s authentication information.)
Two parties in different security domains can validate each other for the purpose of performing business transactions.
Access Manager SAML APIs can be used to build Authentication, Authorization Decision and Attribute Assertions.
The Access Manager SAML Service provides pluggable XML-based digital signature signing and verifying.