Sun ONE Identity Server Programmer's Guide
|
Sun ONE Identity Server Programmer's Guide |
Chapter 9 Federation Management
Sun™ One Identity Server 6.0 contains a Federation Management module which implements the open standards for federated network identity being developed by the Liberty Alliance Project. This chapter explains the Liberty Alliance Project and the concept of federated network identity as well as describing how it is integrated within the Identity Server. It contains the following sections:
Overview
Federation Management Process
Federation Management API
Customizing The Module
Federation Management Samples
Overview
On the Internet, one person might have a multitude of accounts set up to access various business, community and personal service providers; for example, the person might have used different names, user IDs, passwords or preferences to set up accounts for a news portal, a bank, a retailer, and an email provider. A local identity refers to the set of attributes that an individual might have with each service provider. These attributes serve to uniquely identify the individual with that provider and may include a name, phone number, social security number, address, credit records, bank balances or bill payment information.
Because the Internet is fast becoming the prime vehicle for business, community and personal interactions, it has become necessary to fashion a system for online users to aggregate their local identities, enabling them to have one network identity. This system is identity federation. Identity federation allows a user to associate, connect or bind multiple Internet service providers' local identities. A network identity allows users to login at one service provider's site and then go to an affiliated site without having to re-authenticate or re-establish their identity. The Liberty Alliance Project was implemented to make identity federation a reality.
The Liberty Alliance Project
The goal of the Liberty Alliance Project is to enable individuals and organizations to more easily conduct transactions while protecting the individual's identity. To accomplish this, the Alliance has established specifications for identity federation that enables:
Opt-in account linking where users can choose to federate different internet service provider accounts.
Simplified single sign-on where a user can log in and authenticate with one provider's federated account and navigate to another account without having to log in again.
Authentication context where organizations with linked accounts communicate the type and level of authentication that should be used when the user logs in.
Global log-out where a user logs out of the site to which they initially logged in and is automatically logged out of all sites that maintain a live session.
A client feature which can be implemented in fixed and wireless devices to facilitate use of the Liberty specifications.
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' is referred to as an authentication domain. The authentication domain includes service providers (who offer web-based services to users), identity providers (service providers who also offer federated authentication), and the users themselves. Once an authentication domain is established, users can federate any or all identities they might have with the service providers that have joined this domain, enabling them to make use of the federated authentication capabilities.
Liberty Specification Concepts
The Federation Management module built into the Identity Server is designed to be compatible with the Liberty Alliance Project's Version 1.0 specifications. A number of concepts are derived from these specifications. They include:
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, and governmental agencies.
Identity Provider
Identity providers are service providers that specialize in providing authentication services. In the Liberty context, authentication done by an identity provider is honored by all service providers with whom it is affiliated.
Authentication Domain
An Authentication Domain is a group of affiliated service providers consisting of one or more identity providers. The group is also referred to as a `circle of trust'. Once established, single sign-on is enabled within the authentication domain.
Trusted Provider
A Trusted Provider is one of a group of service and identity providers, affiliated together based on the Liberty architecture and operational agreements, with whom users can transact and communicate in a secure environment.
Account Federation (Identity Federation)
Account federation occurs when a user unites accounts that were initially set up with distinct service and identity providers. Users retain their individual accounts with each provider in the Authentication Domain while, simultaneously, establishing a link that allows the exchange of user information between them.
Federated Identity
A federated identity refers to the amalgamation of a user's distinct service provider's account attributes (personal data, online configurations, buying habits and history, shopping preferences, etc.). The information is still administered by the user, yet it is securely shared with the organizations of their choosing.
Federation Termination (Defederation)
Users have the ability to terminate federations. Federation termination results in the cancellation of affiliations established between the user's identity provider account and federated service provider accounts.
Single Sign-on
Single sign-on (SSO) is established when a user with a federated identity authenticates to an identity provider and is then able to access affiliated service providers without having to authenticate again.
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.
Common Domain
When authenticated, an identity provider writes a cookie stating the user's preferred identity provider (itself). However, due to the constraints in cookie standards, there is no way for an identity provider in one DNS domain to write a cookie that a service provider in another DNS domain can read. To work around this situation, the Liberty specification advocates the use of a Common Domain (also known as third level domain).
Name Identifier
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 as a name identifier, and is stored in the Directory Server data store.
Federation Management Process
Out of the box, Identity Server has two options for user or application authentication. The first is the Identity Server Authentication Service and the second is the Liberty-enabled Federation Management Service. In an Identity Server scenario when a user or application tries to access a resource protected by the Identity Server, the user is redirected to the Authentication Service via a Login page for access authorization. When the user provides credentials, the authentication module verifies them and either allows or denies access.
|
More information on the Authentication Service can be found in Chapter 3 "Authentication Service." |
In a scenario where the Identity Server is Liberty-enabled and a user or application attempts to access a protected resource, the user is redirected to a Pre-Login page which invokes the Federation Management Service's Pre-Login servlet. This servlet searches for either a valid Identity Server single sign-on token or a valid Federation Cookie (which indicates that a user has federated his account using this Identity Server provider). If an SSO token is found, the user's Federation information is retrieved, and the user is authenticated; a Federation Cookie is also set and the user is returned to the target resource. If a Federation Cookie is found, the user is directed to the Federation Single Sign-On Service which provides an Authentication Assertion allowing the user access to the target resource. If neither of these items is found, the user is redirected to the Identity Server Authentication Service where, upon successful authentication, they are directed to the Post-Login page which invokes the Post-Login servlet. This servlet processes the user's Identity Server authentication and initiates the Federation Management Single Sign-On Service which, once again, provides an Authentication Assertion to allow the user access to the target resource. Figure 9-1 illustrates this flow.
Figure 9-1 Liberty-enabled Identity Server Authentication Process Flow
Federation Management Protocols
In order to enable the federation process, the Liberty Alliance Project's Phase I Specifications define the following protocols that are implemented by the Identity Server:
Single Sign-on and Federation Protocol
This is the protocol used to federate a user's identity for a service provider with their identity for an identity provider, thus enabling single sign-on. It also specifies the means by which a service provider obtains an Authentication Assertion from an identity provider to provide single sign-on to the user. There are two types which either the identity or service provider can implement:
SOAP - based Single Sign On and Federation Protocol relies on a SOAP call from the service provider to the identity provider.
Form POST - based Single Sign On and Federation Protocol relies on a form POST to communicate between the service provider and the identity provider.
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. The provider will notify all other providers in the Authentication Domain when a user defederates their identity. There are two types of notification which either the identity or service provider can implement:
SOAP - based Federation Termination Notification Protocol relies on a SOAP call from the service provider to the identity provider.
Form POST - based Federation Termination Notification Protocol relies on a form POST to communicate between the service provider and the identity provider.
Name Registration Protocol
At the time of federating a user account, the identity provider generates a name identifier that serves as the term the identity provider and the service provider use in referring to the user when communicating. This is the IDP Provided NameIdentifier. Subsequent to federation, however, the service provider may register a different name identifier with the identity provider. This is the SP Provided NameIdentifier. The identity provider must use the SP Provided NameIdentifier when communicating with the service provider about the user until after federation when they will both use 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 opened by a particular identity provider. There are two types which either the identity or service provider can implement:
SOAP-based Single Log-Out Protocol relies on asynchronous SOAP messaging between service providers and identity providers.
Form POST-based Single Log-Out Protocol relies on a form POST to communicate between service providers and identity providers.
IDP Introduction Protocol
In federation networks having more than one identity provider, the service providers need a way to determine which identity provider(s) is the user's preferred identity provider. 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 implement this protocol.
Federation Management API
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. These methods include:
getSPList()—which returns a list of all trusted service providers.
getSPList(String hostedProviderID)—which returns a list of all trusted service providers for the specified hosted provider.
getIDPList()—which returns a list of all trusted identity providers.
getIDPList(String hostedProviderID)—which returns a list of all trusted identity providers for the specified hosted provider.
getSPFederationStatus(String user, String provider)—which retrieves the federations status of a user with a service provider. This method assumes that the user is already federated with the provider.
getIDPFederationStatus(String user, String provider)—which retrieves the federation status of a user with an identity provider. This method assumes that the user is already federated with the provider.
getFederatedProviders(String userName)—which returns a specific user's federated providers.
getProvidersToFederate(String providerID, String userName)—which returns the list of all trusted identity providers to which the specified user is not already federated.
getListOfCOTs(String providerID)—which returns a list of authentication domains for the given provider.
Customizing The Module
The Federation Management module uses JSP files to define the look and feel of its pages. An administrator can customize the JSPs by changing the tags accordingly. The JSPs can be found in the <identity_server_root>/SUNWam/web-apps/ services/config/federation/default/ directory and include:
CommonLogin.jsp—displays links to the login pages of the trusted identity providers as well as the local login link. It is displayed when the user is not locally logged in or not logged in at the identity provider site. The list of trusted identity providers is obtained by the getIDPList(hostedProviderID) method.
Error.jsp—displays an error page when one has occurred.
Federate.jsp—is displayed when the user clicks the Federate link in the index.jsp. It displays a drop-down menu that lists all providers with which the user is not yet federated. This list is constructed from the getProvidersToFederate(userName, providerID) method which returns all active providers to which the user is not yet federated.
FederationDone.jsp—displays the status of federation (success or cancelled). It checks this status using the isFederationCancelled(request) method.
Footer.jsp—displays a branded footer.
Header.jsp—displays a branded header.
ListOfCOTs.jsp—displays multiple authentication domains (or circles of trust) when the service provider belongs to more than one. When a user is authenticated by an identity provider and the provider belongs to more than one authentication domain, they will be shown the ListOfCOTs.jsp to select one domain as the preferred domain. In the case that the provider belongs to only one domain, then this page will not display as, by default, the one domain is the preferred domain. The list of authentication domains is obtained by using the getListOfCOTs(providerID) method.
LogoutDone.jsp—displays the status of the local logout.
Termination.jsp—is displayed when the user clicks the defederate link. It shows a drop-down menu of all providers to which the user has already federated; from this list, the user can choose to defederate. The list is constructed using the getFederatedProviders(userName) method which returns all active providers to which the user is already federated.
TerminationDone.jsp—displays the status of federation termination (success or cancelled). It checks this status using the isTerminationCancelled(request) method.
The files in this directory provide a default GUI for the module. To customize it for a specific organization, this default directory can be copied and renamed to reflect the name of the organization (or any value). It would then be placed at the same level as the default directory and the files within this directory could then be modified as needed.
Federation Management Samples
There are a number of samples included with the Identity Server that demonstrate the different protocols used in the Federation Management module. They are located in the <identity_server_root>/SUNWam/samples/liberty/ directory. Instructions on how to implement the samples can be found in the README file.
Sample 1 illustrates a scenario with one Service Provider and one Identity Provider configured on two separate Identity Server installations. Two server machines are required.
Sample 2 illustrates a scenario with one Service Provider whose resources are deployed on a Sun ONE Web Server protected by an Identity Server Policy Agent and one Identity Provider. At least two server machines are required for this sample also.
Sample 3 illustrates a multiple hosted providers scenario with two Service Providers and two Identity Providers. This sample scenario requires only one server machine and one Identity Server installation. Four hosted providers (two Service Providers and two Identity Providers) are created on the same Identity Server Installation.
Previous Contents Index Next
Copyright 2002 Sun Microsystems, Inc. All rights reserved.
Last Updated December 02, 2002