| Sun ONE Identity Server 6.1 Product Brief |
Chapter 5
Federation ManagementThis chapter introduces the concept of Federation Management and the role Sun ONE Identity Server plays in its implementation. Topics included in this chapter are:
The Need for Federation ManagementConsider the many times an individual accesses services on the Internet in a single day. At work, he uses the company intranet to perform a multitude of business-related tasks such as reading and sending email, looking up information in the company phone book and other internal databases, and submitting expense reports and other business-related online forms. At home after work, he checks his personal email, then logs into an online news service to check his baseball team’s standings, finalizes his travel plans via his travel agent’s website, and does some online shopping at his favorite clothing store. Each time he accesses a service on the Internet, he must log in and identify himself to the service provider.
A local identity refers to the set of attributes or information that identify a user to a service provider. These attributes typically include a name and password, plus an email address, account number or other identifier. For example, the individual in our scenario is known to his company’s network as an employee number, but he is known to his travel agent as Joe Smith. He is known to his online news service by an account number, and he is known to his favorite clothing store by a different account number. He uses one email name and address for his personal email, and a different email name and address for his workplace.
Identity federation allows a user to consolidate the many local identities he has configured among multiple service providers. With one federated identity, the individual can log in at one service provider’s site and move to an affiliated service provider site without having to re-authenticate or re-establish his identity. For example, with a federated identity, the individual might want to access both his personal email account and his business email account from his workplace, and move back and forth between the two services without having to log in each time. Or at home he might want to log in to an online clothing store, then access the online news service, and communicate with his travel agent—all without having to provide different user names and passwords at each service site.
The Liberty Alliance Project was implemented to make this possible.
The Liberty Alliance Project
The goal of the Liberty Alliance Project is to enable individuals and organizations to easily conduct network transactions while protecting the individual’s identity. To accomplish this, the Alliance has established specifications for identity federation that enable the following features:
Users can choose to federate different service provider accounts.
A user can log in, authenticate to one service provider and gain access to other service providers with which they have federated without having to log in again.
Service providers with federated accounts communicate the type and level of authentication that should be used when the user logs in.
A user logs out of an identity or service provider site and is automatically logged out of all sites that maintain a live session.
Users can choose to stop their account federation.
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 indivdual who interacts with the system. This is important when there are multiple identity providers in an identity federation network.
This feature enables a service provider or identity provider to register with each other a new name identifier for a principal at any time following federation.
These capabilities can be achieved when commercial or non-commercial organizations join together into a circle of trust based on Liberty-enabled technology and operational agreements. This circle of trust includes service providers (who offer web-based services to users), identity providers (service providers that also maintain and manage identity information), and the users themselves. Once a circle of trust is established between providers, users can choose to federate any or all identities they might have with the service providers that have joined this circle, enabling them to make use of the federated authentication capabilities.
Liberty Specifications 1.1 Changes
Identity Server 6.0 used Liberty Specifications, v.1.0 as the basis for its Federation Management Service. This Identity Server 6.1 is based on the Liberty Specifications, v.1.1. Some of the changes include the following:
- Name registration can now be initiated both from a service provider and from an identity provider rather than just a service provider.
- The XML Digital Signature requirements have been enhanced for clairty.
- The sample applications are compliant with Liberty 1.1.
- A response message has been added to Logout.
Federation ConceptsThe Federation Management module built into the Identity Server is designed to be compatible with the Liberty Alliance Project’s version 1.1 specifications. A number of concepts are derived from these specifications. For clarification, definitions of these concepts are provided in this section.
Account Federation (Identity Federation)
Account Federation occurs when a user chooses to unite distinct service accounts and identity provider accounts. Users retain the individual account information with each provider in the while, simultaneously, establishing a link that allows the exchange of authentication information between them.
Authentication Domain
See Circle Of Trust.
Circle Of Trust
A Circle Of Trust is a group of service providers who agree to join together in order to exchange user authentication information using Liberty-enabled technologies. This Circle Of Trust must contain at least one Identity Provider. Once a Circle Of Trust is established, single sign-on is enabled between all the providers.
Note
A Circle Of Trust is, at times, referred to as an Authentication Domain although it is not a domain in the Internet sense of the word.
Common Domain
A common domain is a unique, Liberty-specifiedInternet domain between a Service Provider and an Identity Provider in a Circle Of Trust. The CommonDomain(Introduction) protocol helps service providers to find the preferred identity provider in a circle of trust. When a user authenticates to a service provider, a common domain cookie is used to store the user’s identity provider. (_liberty_idp is the cookie name.) When the user attempts to access a new service provider in the circle of trust, the service provider reads the common domain cookie and the request can be forwarded to the correct identity provider.
Federated Identity
A federated identity refers to the amalgamation of the account information in all service providers accessed by one user (personal data, authentication information, buying habits and history, shopping preferences, etc.). The information is administered by the user yet, with the user’s consent, their privilege to access information is securely shared with their providers of choice.
Federation Termination
Users have the ability to terminate federations. Federation termination (or defederation) results in the cancellation of affiliations established between the user’s identity provider and federated service provider accounts.
Identity Provider
Identity providers are service providers that specialize in providing authentication services. As the administrating service for authentication, they also maintain and manage identity information. Authentication accomplished by an Identity Provider is honored by all service providers with whom it is affiliated.
Name Identifier
To help preserve anonymity, identity federation maps a user’s account information across a number of service and identity provider organizations. The user’s identity is exchanged between the identity and service providers using a pseudonym or name identifier. Neither the identity provider nor the service provider should have knowledge of the user’s actual identity.
Service Provider
Service providers are commercial or not-for-profit organizations that offer web-based services. This broad category can include internet portals, retailers, transportation providers, financial institutions, entertainment companies, libraries, universities, and governmental agencies.
Single Logout
When a user logs out from an Identity Provider or a Service Provider, they will effectively be logged out from all service providers or identity providers in that authentication domain.
Single Sign-on
Single sign-on is established when a user with a Federated Identity authenticates to an Identity Provider. Because they have previously opted-in for federation, they are now able to access affiliated service providers without having to re-authenticate.
Trusted Provider
A Trusted Provider is a generic term for one of a group of service and identity providers in an Circle Of Trust. Users can transact and communicate with Trusted Providers in a secure environment.
Federation Management ProcessBy default, Identity Server has two options for user authentication. The first is the proprietary Authentication Service; the second is the Liberty-enabled Federation Management. With the first option when a user tries to access a resource protected by Identity Server, he is redirected to the Authentication Service for authorization using an Identity Server login page. When the user provides credentials, the Authentication Service verifies his identity, and either allows or denies access.
With the second option, Liberty-enabled Federation Management, when a user attempts to access an identity or service provider resource protected by Identity Server, the authentication process begins with a search for a valid Identity Server session token. If a session token is found, the user is granted access to the requested page. This page, belonging to a member of the Circle Of Trust contains a link which will allow the user to federate their identity. If the user clicks this link, they are directed through the Federation Single Sign-On Process process. If, on the other hand, no session token is found, the user moves through the Pre-Login Process.
Pre-Login Process
The purpose of the Pre-Login process is to establish a valid user session at the service provider site. When no Identity Server session token is found, the pre-login process begins with the search for another type of cookie, a Federation cookie.
If, after the search for an Identity Server session token proves null, a Federation cookie is found and its value is “no,” an Identity Server login page is displayed and the user submits credentials to the Authentication Service. When authenticated by the Identity Server, the user is redirected to the requested page which, as above, contains a link to allow the user to federate their identity. If the user clicks this link, they are directed through the Federation Single Sign-On Process.
If, after the search for an Identity Server session token proves null, a valid Federation Cookie is found an its value is “yes,” it means the user has already been federated but not authenticated by an identity provider within the Circle of Trust. This is confirmed by sending a request for authentication to the user’s chose identity provider.
If no Federation Cookie is found at all, a passive authentication request (not allowing IDP interaction with the user) is sent to the user’s chosen identity provider. When an affirmative response is received back from the IDP, the user is redirected to the Identity Server Authentication Service. There, the user is automatically granted a session token and redirected to the requested page. When the response from the identity provider is negative (for example, if the session has timed out), the user is sent to a common login page where he can choose to do a local login or Federation Single Sign-On.
Federation Single Sign-On Process
The Federation Single Sign-On process gives the user the option to authenticate and federate their identity with an identity provider to gain access to all provider sites within the Circle Of Trust (including the service provider which houses the resource originally requested). If an identity provider has responded to a request for authentication confirmation in the negative, the user is directed to authenticate again using the Federation Single Sign-On process. The user selects an identity provider and sends their credentials for authentication. Once authentication is granted, the user is redirected to the Identity Server Authentication Service where they are automatically granted a session token and redirected to the requested page which, as above, contains a link to allow the user to federate their identity for future single sign-on opportunities.
Figure 5-1 Liberty-enabled Identity Server Authentication Process Flow
Federation Management Protocols and APIsThe Federation Management Process is based on the protocols and APIs defined by the Liberty Alliance Project’s specifications. They are:
Identity Server provides the implementation of these Liberty protocols as well as the Federation Management APIs.
Single Sign-on and Federation Protocol
This is the protocol on which Identity Server bases the Federation Management Process. It 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. There are two types of Single Sign-On which either the identity or service provider can implement:
Federation Termination Notification Protocol
This is the protocol used to notify providers when a user’s existing federated identity is terminated. The termination can be initiated at either the identity or service provider. Said provider will notify all other providers in the Circle of Trust when a user defederates. There are two types of notification which either the identity or service provider can implement:
Name Registration Protocol
At the time of federating a user account, the identity provider generates a name identifier, a pseudonym that all providers use when referring to the user during communications. This is the IDP Provided NameIdentifier.
Single Log-Out Protocol
This is the protocol used to synchronize the session log-out functionality across all sessions that were authenticated and created by a particular identity provider. There are two types which either the identity or service provider can implement:
IDP Introduction Protocol
In a Circle of Trus that has more than one identity provider, the service providers need a way to determine which provider is preferred by the user. The Liberty specification defines a protocol which relies on a cookie written in a domain that is common between identity providers and service providers. This predetermined domain is the common domain and the cookie containing the preferred identity provider is known as the common domain cookie. The service provider can read this cookie value to identify a user’s preferred identity provider and get authentication assertions from that identity provider. Both identity providers and service providers can implement this protocol.
Note
It is recommended that the system clocks of all identity provider and service provider servers are synchronized. A time sync server can be used for this purpose.
Federation Management APIs
The LibertyManager class forms the basis of the Federation Management APIs. This interface is instantiated by web applications that want to access the Federation Management module. It contains the methods needed by the module JSPs for account federation, session termination, log in, log out and other actions.
