SAML 2.0

Assertions

The assertions created byTivoli® Federated Identity Manager contain authentication statements. These authentication statements assert that the principal (that is, the entity requesting access) was authenticated. Assertions can also carry attributes about the user that the identity provider wants to make available to the service provider.

Assertions are typically passed from the identity provider to the service provider.

The content of the assertions that are created is controlled by the specification (SAML 2.0). You select these assertions when you establish a federation. You also select these assertions by the definitions used in the Tivoli Federated Identity Manager identity mapping method that you configure. The identity mapping method can either be a custom mapping module or an XSL transform file. The identity mapping also specifies how identities are mapped between federation partners.

Protocols

Bindings

When you use SAML 2.0 in Tivoli Federated Identity Manager, you have several binding options. These options specify the way in which messages can be transported:

HTTP redirect

HTTP redirect enables SAML protocol messages to be transmitted within URL parameters. It enables SAML requestors and responders to communicate using an HTTP user agent as an intermediary. The intermediary might be necessary if the communicating entities do not have a direct path of communication. The intermediary might also be necessary if the responder requires interaction with a user agent such as an authentication agent.

HTTP redirect is sometimes called browser redirect in single sign-on operations. This profile is selected by default.

HTTP POST

HTTP POST enables SAML protocol messages to be transmitted within an HTML form using base64-encoded content. It enables SAML requestors and responders to communicate using an HTTP user agent as an intermediary. The agent might be necessary if the communicating entities do not have a direct path of communication. The intermediary might also be necessary if the responder requires interaction with a user agent such as an authentication agent.

HTTP POST is sometimes called Browser POST, particularly when used in single sign-on operations. It uses a self-posting form during the establishment and use of a trusted session between an identity provider, a service provider, and a client (browser).

HTTP artifact

HTTP artifact is a binding in which a SAML request or response (or both) is transmitted by reference using a unique identifier called an artifact. A separate binding, such as a SOAP binding, is used to exchange the artifact for the actual protocol message. It enables SAML requestors and responders to communicate using an HTTP user agent as an intermediary. This setting is used when it is not preferable to expose the message content to the intermediary.

HTTP artifact is sometimes called browser artifact, particularly when used in single sign-on operations. The HTTP artifact uses a SOAP back channel. The SOAP back channel is used to exchange an artifact during the establishment and use of a trusted session between an identity provider, a service provider, and a client (browser).

SOAP

SOAP is a binding that uses Simple Object Access Protocol (SOAP) for communication.

The choice of binding you have depends on the profile you choose to use in your federation.

Profiles

Tivoli Federated Identity Manager supports the configuration of the single sign-on profile on a per-partner basis. The profiles supported are:

Web browser single sign-on

The Web Browser SSO profile is the consolidation of the browser artifact and browser POST profiles that were introduced in SAML 1.x. Using this profile, an authentication request message is sent from a service provider to an identity provider. A response message containing a SAML assertion is sent from the identity provider to the service provider. Additional messages are sent related to artifact resolution, if that binding is used. This profile provides options regarding the initiation of the message flow and the transport of the messages:

Message initiation

The message flow can be initiated from the identity provider or the service provider.

Bindings

In a Tivoli Federated Identity Manager environment, the following bindings can be used in the Web browser SSO profile:

• HTTP Redirect (available only in an identity provider configuration)
• HTTP POST
• HTTP artifact

The choice of binding depends on the type of messages being sent. For example, an authentication request message can be sent from a service provider to an identity provider. The response message can be sent from an identity provider to a service provider using either HTTP POST or HTTP artifact. A pair of partners in a federation do not need to use the same binding.

Options

The Web Browser single sign-on profile in Tivoli Federated Identity Manager also provides the following option:

• Enhanced Client Proxy This profile option enables an enhanced client or proxy (ECP) to communicate with an identity provider and service provider on behalf of a user (client). For example, a user might request a resource from a service provider. The service provider might not know which identity provider to access in order to authenticate the user. Using the ECP profile option, the service provider can contact the ECP, which knows how to locate and access the appropriate identity provider. The ECP profile supports SOAP and reverse SOAP (PAOS) bindings during the processing of authentication requests.

Single Logout

The Single Logout profile is used to terminate all the login sessions currently active for a specified user within the federation. A user who achieves single sign-on to a federation establishes sessions with more than one participant in the federation. The sessions are managed by a session authority, which in many cases is an identity provider. When the user wants to end sessions with all session participants, the session authority can use the single logout profile to globally terminate all active sessions.

Message initiation

The message flow can be initiated from the identity provider or the service provider.

Bindings

In a Tivoli Federated Identity Manager environment, the following bindings can be used in the Single Logout profile:

• HTTP Redirect
• HTTP POST
• HTTP artifact
• SOAP

Name Identifier Management

The Name Identifier Management profile manages user identities that are exchanged between identity providers and service providers. The profile enables identity providers to notify service providers. Service providers are notified when there is a change to the content or format of an identity for a given user (principal). The profile enables service providers to specify unique aliases for the principal. Service providers can also send those aliases to the identity provider to be used instead of the principal name. The profile also enables either provider. The profile notifies its partner when it decides to no longer issue or accept messages that use the identity of the principal.

To manage the aliases, Tivoli Federated Identity Manager uses a function called the alias service. The alias service stores and retrieves aliases that are related to a federated identity. Aliases can be used in the following ways:

Persistent aliases

When persistent aliases are used, the identity of the user is federated by the identity provider to the identity of the user at the service provider. A persistent SAML name identifier is used. The user remains in the federation permanently, that is, until a request is made to terminate the federation.

Transient aliases

When transient aliases are used, a temporary identifier is used to federate between the identity provider and service provider. A temporary identifier is used only for the life of the user's single sign-on session.

In a Tivoli Federated Identity Manager environment, aliases are stored in and retrieved from one of the following types of repositories:

• An LDAP database.
• A relational database that supports JDBC.

During the configuration of Tivoli Federated Identity Manager, you can configure your environment to use one of these repository types.

Message initiation

The message flow can be initiated from the identity provider or the service provider.

Bindings

The following bindings can be used in the Name Identifier Management profile:

• HTTP Redirect
• HTTP POST
• HTTP artifact
• SOAP

Identity Provider Discovery

The Identity Provider Discovery profile is used by service providers to discover which identity provider is used by a user (principal) during Web browser single sign-on. Some deployments have more than one identity provider, and the service provider must be able to determine which identity provider a principal uses. The Identity Provider Discovery profile uses a cookie. The cookie is created in a domain that is common between identity providers and service providers in a given deployment. The cookie contains the list of identity providers and is called the common domain cookie.

Account linkage

In SAML 2.0, account linkage enables a user to link an identity provider account to a service provider. The link happens during the single sign-on initiated at the identity provider and service provider. In both scenarios, account linkage requires a user to be authenticated at both the service provider and identity provider.

An administrator can enable this feature in the partner settings panel. If this feature is enabled, the user must authenticate in the service provider when a persistent alias is received. The alias can not have been previously linked to an account in the service provider for the authentication to occur.

After the user authenticates, the SAML 2.0 implementation stores the alias at the service provider alias service and establishes account linkage.

Handling an unknown alias

SAML 2.0 supports aliases to communicate user identities between partners.