The Liberty Alliance Project was formed to develop technical specifications that would solve business process issues including single sign-on, federation and consent. The Liberty Alliance Project Identity Federation Framework (Liberty ID-FF) uses a name identifier to pass identity data between identity providers and service providers. The name identifier is a randomly generated character string that is assigned to a principal and used to federate the principal's accounts at the identity provider and service provider sites. This pseudonym allows all providers to identify a principal without knowing the user's actual identity. The name identifier has meaning only in the context of the relationship between providers. SAML v1.x is used for provider interaction.
Liberty ID-FF was initially defined as an extension of SAML 1.0 (and later SAML 1.1). The extensions have now been contributed back into SAML v2 which, going forward, will be the basis on which the Liberty Alliance Project builds additional federated identity applications. See Using SAML for more information on this convergence.
The following sections contain information about the Liberty ID-FF and the features implemented in OpenSSO Enterprise.
The following sections contain information about the Liberty ID-FF features implemented in OpenSSO Enterprise.
Let's assume that a principal has separate user accounts with a service provider and an identity provider in the same circle of trust. In order to gain access to these individual accounts, the principal would authenticate with each provider separately. If federating with the Liberty ID-FF though, after authenticating with the service provider, the principal may be given the option to federate the service provider account with the identity provider account. Consenting to the federation of these accounts links them for SSO, the means of passing a user's credentials between applications without the user having to reauthenticate. SSO and federated SSO have different processes. With OpenSSO Enterprise, you can achieve SSO in the following ways:
Install a policy agent in a web container to protect the application and pass the HTTP_HEADER and REMOTE_USER variables to the application to capture the user credentials. You may or may not need a custom authentication module.
Customize the application's authentication module to create an SSOToken from the request object or from the SSO cookie. Afterwards, retrieve the user credentials using the SSO API and create a session data structure using the application's API.
To set up federated SSO, you must first establish SSO. Following that, enable federation in the metadata for the service provider entity and the identity provider entity using OpenSSO Enterprise. Liberty ID-FF providers differentiate between federated users by defining a unique identifier for each account. (They are not required to use the principal's actual provider account identifier.) Providers can also choose to create multiple identifiers for a particular principal. However, identity providers must create one handle per user for service providers that have multiple web sites so that the handle can be resolved across all of them.
Because both the identity provider entity and the service provider entity in a federation need to remember the principal's identifier, they create entries that note the value in their respective user repositories. In most scenarios, the identity provider's identifier is conveyed to a service provider and not visa versa. For example, if a service provider does not maintain its own user repository, the identity provider's identifier is used.
OpenSSO Enterprise can accommodate the following SSO and federation-related functions:
Providers of either type notify the principal upon identity federation or defederation.
Providers of either type notify each other regarding a principal's defederation.
Identity providers notify the appropriate service providers regarding a principal's account termination.
Providers of either type display a list of federated identities to the principal.
Users can terminate federations or defederate identities.
Additionally, OpenSSO Enterprise can accommodate the federation features explained in the following sections.
Auto federation will automatically federate a user's disparate provider accounts based on a common attribute. During SSO, if it is deemed a user at provider A and a user at provider B have the same value for the defined common attribute (for example, an email address), the two accounts will be federated without consent or interaction from the principal. For more information, see Part II, Federation, Web Services, and SAML Administration, in Sun OpenSSO Enterprise 8.0 Administration Guide.
Federating one user's service provider account with their identity provider account generally requires the principal to visit both providers and link them. An organization though needs the ability to federate user accounts behind the scenes. OpenSSO Enterprise provides a script for federating user accounts in bulk. The script allows the administrator to federate many (or all) of a principal's provider accounts based on metadata passed to the script. Bulk federation is useful when adding a new service provider to an enterprise so you can federate a group of existing employees to the new service. For more information, see Part II, Federation, Web Services, and SAML Administration, in Sun OpenSSO Enterprise 8.0 Administration Guide.
SSO is the means by which a provider of either type can convey to another provider that a principal has been authenticated. Authentication is the process of validating user credentials; for example, a user identifier accompanied by an associated password. You can authenticate users with OpenSSO Enterprise in the following ways:
Use a policy agent to insert HTTP header variables into the request object. This functions for web applications only.
Use the authentication API to validate and retrieve user identity data. This will work with either web or non-web applications.
Identity providers use local (to the identity provider) session information mapped to a user agent as the basis for issuing SAML authentication assertions to service providers. Thus, when the principal uses a user agent to interact with a service provider, the service provider requests authentication information from the identity provider based on the user agent's session information. If this information indicates that the user agent's session is presently active, the identity provider will return a positive authentication response to the service provider. OpenSSO Enterprise allows providers to exchange the following minimum set of authentication information with regard to a principal.
Authentication status (active or not)
Instant (time authenticated)
Authentication method
Pseudonym (temporary or persistent)
SAML v1.x is used for provider interaction during authentication but not all SAML assertions are equal. Different authorities issue SAML assertions of different quality. Therefore, the Liberty ID-FF defines how the consumer of a SAML assertion can determine the amount of assurance to place in the assertion. This is referred to as the authentication context, information added to the SAML assertion that gives the assertion consumer the details they need to make an informed entitlement decision. For example, a principal uses a simple identifier and a self-chosen password to authenticate to a service provider. The identity provider sends an assertion to a second service provider that states how the principal was authenticated to the first service provider. By including the authentication context, the second service provider can place an appropriate level of assurance on the associated assertion. If the service provider were a bank, they might require stronger authentication than that which has been used and respond to the identity provider with a request to authenticate the user again using a more stringent context. The authentication context information sent in the assertion might include:
The initial user identification mechanism (for example, face-to-face, online, or shared secret).
The mechanisms for minimizing compromise of credentials (for example, private key in hardware, credential renewal frequency, or client-side key generation).
The mechanisms for storing and protecting credentials (for example, smart card, or password rules).
The authentication mechanisms (for example, password or smart card with PIN).
The Liberty ID-FF specifications define authentication context classes against which an identity provider can claim conformance. The Liberty ID-FF authentication contexts are listed and described in the following table.
Table 11–2 Authentication Context Classes
Class |
Description |
---|---|
MobileContract |
Identified when a mobile principal has an identity for which the identity provider has vouched. |
MobileDigitalID |
Identified by detailed and verified registration procedures, a user's consent to sign and authorize transactions, and DigitalID-based authentication. |
MobileUnregistered |
Identified when the real identity of a mobile principal has not been strongly verified. |
Password |
Identified when a principal authenticates to an identity provider by using a password over an unprotected HTTP session. |
Password-ProtectedTransport |
Identified when a principal authenticates to an identity provider by using a password over an SSL-protected session. |
Previous-Session |
Identified when an identity provider must authenticate a principal for a current authentication event and the principal has previously authenticated to the identity provider. This affirms to the service provider a time lapse from the principal's current resource access request. Note – The context for the previously authenticated session is not included in this class because the user has not authenticated during this session. Thus, the mechanism that the user employed to authenticate in a previous session should not be used as part of a decision on whether to now allow access to a resource. |
Smartcard |
Identified when a principal uses a smart card to authenticate to an identity provider. |
Smartcard-PKI |
Identified when a principal uses a smart card with an enclosed private key and a PIN to authenticate to an identity provider. |
Software-PKI |
Identified when a principal uses an X.509 certificate stored in software to authenticate to the identity provider over an SSL-protected session. |
Time-Sync-Token |
Identified when a principal authenticates through a time synchronization token. |
For more information, see the Liberty ID-FF Authentication Context Specification and . Additionally, there is an XML schema defined which the identity provider authority can use to incorporate the context of the authentication in the SAML assertions it issues.
Service providers need a way to determine which identity provider in a circle of trust is used by a principal requesting authentication. Because circles of trust are configured without regard to their location, this function must work across DNS-defined domains. A common domain is configured, and a common domain cookie written, for this purpose.
Let's suppose a circle of trust contains more than one identity provider. In this case, a service provider trusts more than one identity provider so, when a principal needs authentication, the service provider with which the principal is communicating must have the means to determine the correct identity provider. To ascertain a principal’s identity provider, the service provider invokes a protocol exchange to retrieve the common domain cookie, a cookie written for the purpose of introducing the identity provider to the service provider. If no common domain cookie is found, the service provider will present a list of trusted identity providers from which the principal can choose. After successful authentication, the identity provider writes (using the configured Writer Service URL) a common domain cookie and, the next time the principal attempts to access a service, the service provider finds and reads the common domain cookie (using the configured Reader Service URL), to determine the identity provider. More information on the Common Domain for Identity Provider Discovery is available in the following sections, and in Finding an Identity Provider for Authentication in Sun OpenSSO Enterprise 8.0 Administration Guide.
The common domain is established for use only within the scope of identity provider discovery in a defined circle of trust. In OpenSSO Enterprise deployments, the identity provider discovery WAR is deployed in a web container installed in a predetermined and preconfigured common domain so that the common domain cookie is accessible to all providers in the circle of trust. For example, if an identity provider is available at http://www.Bank.com, a service provider is available at http://www.Store.com, and the defined common domain is RetailGroup.com, the addresses will be Bank.RetailGroup.com and Store.RetailGroup.com, respectively. If the HTTP server in the common domain is operated by the service provider, the service provider will redirect the user agent to the appropriate identity provider.
After an identity provider authenticates a principal, the identity provider sets a URL-encoded cookie defined in a predetermined domain common to all identity providers and service providers in the circle of trust. The common domain cookie is named _liberty_idp for Liberty ID-FF and _saml_idp for SAML v2. After successful authentication, a principal’s identity provider appends their particular encoded identifier to a list in the cookie. If their identifier is already present in the list, the identity provider may remove the initial appearance and append it again. The intent is that the service provider reads the last identifier on the cookie’s list to find the principal’s most recently established identity provider.
The identifiers in the common domain cookie are a list of SuccinctID elements encoded in the Base64 format. One element maps to each identity provider in the circle of trust. Service providers then use this SuccinctID element to find the user's preferred identity provider.
After a principal authenticates with a particular identity provider, the identity provider redirects the principal's browser to the configured Writer Service URL using a parameter that indicates they are the identity provider for this principal. The Writer Service then writes a cookie using the parameter. Thereafter, all providers configured in this common domain will be able to tell which identity provider is used by this principal. Thus, the next time the principal attempts to access a service hosted by a service provider in the same common domain, the service provider retrieves and reads the common domain cookie, using the configured Reader Service URL, to determine the identity provider.
The Writer Service URL and the Reader Service URL can be defined for use with the Liberty ID-FF or the SAML v2 federation protocol. The URLs are defined when you create a circle of trust for federation. The Common Domain for Identity Provider Discovery for Liberty ID-FF is based on the Identity Provider Introduction Profile detailed in the Liberty ID-FF Bindings and Profiles Specifications. The Common Domain for Identity Provider Discovery for SAML v2 is an implementation of the Identity Provider Discovery Profile as described in the Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0 specification.
OpenSSO Enterprise supports name identifiers that are unique across all providers in a circle of trust. This identifier can be used to obtain information for or about the principal without requiring the user to consent to a long-term relationship with the service provider. When beginning federation, the identity provider generates an opaque value that serves as the initial name identifier that both the service provider and the identity provider use to refer to the principal when communicating with each other. After federation, the identity provider or the service provider may register a different opaque value. If a service provider registers a different opaque value for the principal, the identity provider must use the new identifier when communicating with the service provider about the principal. The reasons for changing an identifier would be implementation-specific. The initial name identifier defined by the identity provider is always used to refer to the principal unless a new name identifier is registered.
A principal may establish authenticated sessions with both an identity provider and individual service providers, based on authentication assertions supplied by the identity provider. When the principal logs out of a service provider session, the service provider sends a logout message to the identity provider that provided the authentication for that session. When this happen, or the principal manually logs out of a session at an identity provider, the identity provider sends a logout message to each service provider to which it provided authentication assertions under the relevant session. The one exception is the service provider that sent the logout request to the identity provider.
An identity provider can choose to proxy an authentication request to an identity provider in another authentication domain if it knows that the principal has been authenticated with this identity provider. The proxy behavior is defined by the local policy of the proxying identity provider. However, a service provider can override this behavior and choose not to proxy. This function can be implemented as a form of authentication when, for instance, a roaming mobile user accesses a service provider that is not part of the mobile home network. For more information see ID-FF Federation Operations in Sun OpenSSO Enterprise 8.0 Administration Guide.
The Liberty ID-FF is designed to work with heterogeneous platforms, various networking devices (including personal computers, mobile phones, and personal digital assistants), and emerging technologies. The process of Liberty ID-FF federation begins with authentication. A user attempting to access a resource protected by OpenSSO Enterprise are redirected to the proprietary Authentication Service via an OpenSSO Enterprise login page. After the user provides credentials, the Authentication Service allows or denies access to the resource based on the outcome.
For more information about the proprietary Authentication Service, see the Chapter 7, Authentication and the Authentication Service.
When the user attempts access to a resource that belongs to a trusted member provider of a configured circle of trust, the process of user authentication begins with the search for a valid OpenSSO Enterprise session token from the proprietary Authentication Service. The process can go in one of two directions based on whether a session token is found.
If no session token is found, the principal is redirected to a location defined by the pre-login URL to establish a valid session.
If a session token is found, the principal is granted (or denied) access to the requested page. Assuming access is granted, the requested page contains a link so the principal may federate the OpenSSO Enterprise identity with the identity local to the requested site. If the principal clicks this link, federation begins.
Figure 11–5 illustrates these divergent paths. The process shown is the default process when no application has been deployed. When an application is deployed and using OpenSSO Enterprise, the process will change based on the query parameters and preferences passed to OpenSSO Enterprise from the participating application. For more information, see Sun OpenSSO Enterprise 8.0 Administration Guide.
As illustrated, the pre-login process establishes a valid OpenSSO Enterprise session. When a principal attempts to access a service provider site and no OpenSSO Enterprise session token is found, OpenSSO Enterprise searches for a federation cookie. A federation cookie is implemented by OpenSSO Enterprise and is called fedCookie. It can have a value of either yes or no, based on the principal’s federation status.
A federation cookie is not defined in the Liberty Alliance Project specifications.
At this point, the pre-login process may take one of the following paths:
If a federation cookie is found and its value is no, a OpenSSO Enterprise login page is displayed and the principal submits credentials to the proprietary Authentication Service. When authenticated by OpenSSO Enterprise, the principal is redirected to the requested page, which might contain a link to allow for identity federation. If the principal clicks this link, federation begins.
If a federation cookie is found and its value is yes, the principal has already federated an identity but has not been authenticated by an identity provider within the circle of trust for this OpenSSO Enterprise session. Authentication to OpenSSO Enterprise is achieved on the back end by sending a request to the principal’s identity provider. After authentication, the principal is directed back to the requested page.
If no federation cookie is found, a passive authentication request (one that does not allow identity provider interaction with the principal) is sent to the principal’s identity provider. If an affirmative authentication is received back from the identity provider, the principal is directed to the OpenSSO Enterprise Authentication Service, where a session token is granted. The principal is then redirected to the requested page. If the response from the identity provider is negative (for example, if the session has timed out), the principal is sent to a common login page to complete either a local login or Liberty ID-FF federation.