Previous Contents Index Next |
Sun ONE Identity Server Administration Guide |
Chapter 5 Federation Management
This chapter describes the Federation Management interface features of the Sun ONE Identity Server. The Federation Management interface provides a way to view, manage and configure the metadata pertaining to the authentication domains and providers. This chapter contains the following sections:
Liberty Alliance and Federated Identity
Federation Management Concepts
Managing Authentication Domains and Providers
Note Example data for the attribute fields described in this chapter can be found in the following default location:
Liberty Alliance and Federated Identity
On the internet, one person might have a multitude of accounts set up to access various business, community and personal service providers. For example, different names, passwords and preferences might be set up for a news portal, a bank account, a retailer, and an email account. A local identity refers to the set of attributes that an individual might set up with one 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 forged to make identity federation a reality.
Federation Management Concepts
To understand the information contained in this chapter, you should familiarize yourself with the following concepts.
Authentication Domain
An authentication domain is a group of affiliated service providers and one or more identity providers. The providers that belong to an authentication domain share a trusted relationship.
Service Provider
Service providers are organizations offering web-based services to users. This includes practically any organization on the Internet (for example, internet portals, retailers, transportation providers, financial institutions, entertainment companies, non-profit organizations, and governmental agencies).
Identity Provider
Identity providers are organizations that specialize in providing authentication services. In the Liberty context, authentication completed by an identity provider will be honored by all its affiliates.
Remote Provider
A remote provider is a service provider or identity provider that is not hosted by the current installation of Identity Server, but is Liberty-enabled, either by another (remote) installation of Identity Server, or by another implementation of the Liberty specification.
Hosted Provider
A hosted provider is either a service provider or an identity provider that is Liberty-enabled by the current, or present, installation of Identity Server.
Metadata
Metadata is the set of required data for configuring the policies that govern the behavior of a service provider or identity provider. Liberty specifications define the metadata attributes for service providers and identity providers.
Account Federation
Account Federation enables service providers and identity providers to unite the otherwise distinct accounts of users.
Federated Identity
Federation allows users to retain their individual accounts with services and identity providers, and establishes an affiliation between the accounts, which facilitates the exchange information about the account on the user's behalf.
Single Sign-on
Single sign-on (SSO) is established when a user authenticates with an identity provider and accesses multiple affiliated service providers, without having to reauthenticate.
Federation Termination
Users will have the ability to terminate federations. Federation termination results in breaking affiliation established between the user's service provider account and the identity provider account at the time of federation.
Single Logout
When a user logs out from an identity provider, the user will effectively be logged out from all affiliated service providers within an authentication domain. Logout information is sent to the identity provider when it is initiated from a service provider. Users can initiate logout from either a service provider or the identity provider.
Common Domain
Due to the constraints in using cookies, a web service can only share cookies with other web services that are in the same DNS domain Therefore, an identity provider in one DNS domain cannot write a cookie that a service provider in another DNS domain can read. To rectify this, the Liberty specification advocates the use of a common domain. This domain is common to all the members of the authentication domain and thus accessible to all parties. All of the cookies in Liberty-based communication will be set by the common domain DNS to make it available to all of the providers within an authentication domain.
Authentication Context
Authentication Context is the information that the service provider may require, in addition to the authentication assertion itself, before it makes an entitlement decision.
If a service provider is to rely on the authentication of a principal by an identity provider, the service provider may require additional information, beyond the authentication assertion itself, before the authentication can be put in a trust context. This information could include:
Initial user identification mechanisms (Examples: face-to-face, online, shared secret)
Mechanisms for storing and protecting credentials (Examples: smartcard, password rules)
Authentication mechanism (Examples: password, certificate-based SSL) Not all authentication assertions are the same; a particular authentication assertion will be characterized by the values for each of these variables, which is captured in an Authentication Context
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.
The Liberty Alliance Project
The vision 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 Liberty 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 an authentication domain based on Liberty-enabled technology and operational agreements. This 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.
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.
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, the user is 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 5-1 illustrates this flow.
Figure 5-1    Liberty-enabled Identity Server Authentication Process Flow
Managing Authentication Domains and Providers
The Federation Management module provides an interface for creating, modifying, and deleting authentication domains, remote providers and hosted providers. To set up a basic Federation Management model, you would do the following:
Create an authentication domain.
Create one or more hosted providers that belong to the created authentication domain.
Create one or more remote providers that belong to the created authentication domain. You must also include the metadata for the remote providers. The metadata could be an XML document that is compliant with the Liberty schema.
Establish a trusted relationship between the providers. A hosted provider can choose to trust a subset of providers, either hosted or remote, that belong to the same authentication domain. The following sections explain how to create and configure authentication domains, remote providers, and hosted providers.
Authentication Domains
This section describes how to create, modify, and delete authentication domains.
Creating An Authentication Domain
Choose Authentication Domain from the View menu in the Federation Management module.
Click New in the navigation frame.
In the Create Authentication Domain window, enter the name of the Authentication Domain.
Enter a value for the description of the Authentication Domain.
Enter a value for the Writer Service URL.
Writer Service URL specifies the location of the Writer service that writes the cookie from the Common Domain. For example, if sun.com is the common domain, the URL could be: Enter a value for the Reader Service URL.
The Reader Service URL specifies the location of the service that reads the cookie from the Common Domain.
Choose a status of active or inactive.
The default is active. This can be changed at any time during the life of the Authentication Domain by selecting the Properties icon. Choosing inactive disables Liberty communication within authentication domain, (including all remote and hosted providers within the authentication domain), with respect to the current installation of Identity Server.
Click Create.
Modifying An Authentication Domain
Click on the properties arrow next to the Authentication Domain you wish to modify.
Modify the properties of the Authentication Domain.
Deleting An Authentication Domain
Deleting an authentication domain does not delete the providers that belong to it. If providers belong to an authentication domain that has been deleted, they remain part of the authentication domain until they are explicitly removed. Additional providers can not be added to an authentication domain that has been deleted.
Choose Authentication Domains from the View menu in the Federation Management module.
Check the box next to the name of the Authentication Domain to be deleted.
Click Delete Selected.
Note There is no warning message when performing a delete.
Providers
This section describes how to create, modify and delete remote and hosted providers.
Creating Remote Providers
A remote provider is an entity that receives metadata from a principal, which is an organization or an individual who interacts with the system. To create a remote provider:
Choose Remote Provider from the View menu in the Federation Management module.
By default, when a Provider is created, it will be a service provider. You can optionally decide to create the remote provider as an identity provider by selecting the option described in Step 14.
Click New. The Create Remote Provider window is displayed.
Enter a value for the Name of the Provider.
Enter a value for the Provider ID.
The Provider ID should specify the URL identifier of the provider. It must be unique across all remote and hosted providers.
Enter the Provider Succinct ID.
The Provider Succinct ID uniquely identifies a service provider to an identity provider. It is also used by the identity provider to determine service provider-specific information such as return URLs, public key/certificates, and so on.
This field accepts a 40-character hexadecimal value. The Succinct ID should be an SHA1 encoded string. It is recommended that the provider ID string should be used as the value to encode, as it will ensure that it is unique. To generate the SHA1 encoding, use the OpenSSL command line tool syntax: Specify Active or Inactive status.
Active status enables this remote provider to participate in federation and SSO. Inactive status makes this remote provider unavailable, and will not respond to any requests.
Enter the Security Key.
The Security Key defines the Security Certificate alias. The certificates are stored in the JKS keystore against an alias. This alias (the Security Key) is used to fetch the required certificate.
Enter the SOAP End Point URL.
This field specifies the location for the receiver of SOAP requests. This is used to communicate on the back-channel (non-browser communication) through SOAP.
Enter the Single Logout Service URL.
The Single Logout Service URL is used by a service provider or identity provider to send and receive logout requests.
Enter the Single Logout Service Return URL.
Enter the Federation Termination Service URL.
Enter a value for the Federation Termination Service Return URL.
This field specifies the URL to which federation termination requests are redirected after processing.
Enter the Assertion Consumer URL.
This field defines the service provider end-point to which an identity provider will send SAML assertions.
Decide if the remote provider is to be defined as an identity provider. By default, all providers are service providers. If selected, the Is Identity Provider option will additionally define the remote provider as an identity provider.
Define the Single Sign-On Service URL.
This field defines the identity provider URL to which the service provider sends requests during federation and SSO. This field only needs to be defined if the Is Identity Provider option is enabled.
Click Create.
Modifying Remote Providers
Once a remote host is created, you can modify it at any time. To do so:
Select Remote Providers from the View menu in the Navigation frame.
Choose the provider profile you wish to modify, and click on the Edit arrow.
By default the General view is displayed in the Navigation pane. All of the fields displayed in the General view contain the data that was entered during the creation of the remote provider. If you modify any of the fields, click Save to save the changes.
To modify the Service Provider fields, choose Service Provider from the View menu.
The Assertion Consumer URL field contains data that was entered during the creation of the remote provider. However, there are three additional fields that you can modify:
Click Save to save the changes.
If the remote provider was defined as an identity provider during creation, you can modify the fields by selecting Identity Provider in the View menu.
The data contained in these fields were entered at creation. If you modify the fields, click Save to save the changes.
Select Authentication Domains in the View menu to edit the authentication domains to which the remote provider will belong.
Use the direction arrows to move a selected authentication domain into the Available list. Click Save. This will assign the provider to the authentication domain. A provider can belong to one or more authentication domains, however a provider without any authentication domains specified can not participate in Liberty communications.
Choose Trusted Providers from the View menu.
Creating Hosted Providers
A hosted provider is an entity that creates, maintains, and manages identity information for principals and provides principal authentication to other service providers within an authentication domain. To create a hosted provider:
Choose Hosted Provider from the View menu in the Federation Management module.
By default, when a Provider is created, it will be a service provider. You can optionally decide to create the remote provider as an identity provider by selecting the option described in Step 9.
Click New. The Create Remote Provider window is displayed.
Enter a value for the Name of the provider.
Enter the Alias for the provider.
For each of the hosted providers, the alias provided in this field is added to a string called meta Alias. This string is then added to the automatically populated URLs for the hosted providers. These URLs are called metadata URLs. In the following examples, sunAlias is the alias for the provider:
Federation Termination Service URL: SOAP Endpoint URL: Enter a value for the Provider ID.
The Provider ID specifies the URL identifier of the provider. It must be unique across all remote and hosted providers.
Enter the Provider Succinct ID.
The Provider Succinct ID uniquely identifies a service provider to an identity provider. It is also used by the identity provider to determine service provider-specific information, such as return URLs, public key/certificates, and so on.
The Succinct ID should be an SHA1 encoded string. It is recommended that the provider ID string should be used as the value to encode, as it will ensure that it is unique. To generate the SHA1 encoding, use the OpenSSL command line tool syntax: Enter the Cookie Domain.
This field specifies the cookie domain if Identity Server is installed on a multi-hosted domain and each of the providers use different domains for their cookie settings.
Specify Active or Inactive status.
Active status enables the remote provider to participate in federation and SSO. Inactive status makes the remote provider unavailable, and will not respond to any requests.
Decide if the remote provider is to be defined as an identity provider. By default, all providers are service providers. If selected, the Is Identity Provider option will additionally define the remote provider as an identity provider.
The Security Key defines the Security Certificate alias. The certificates are stored in the JKS keystore against an alias. This alias (the Security Key) is used to fetch the required certificate.
Enter the Provider URL.
Click Create.
Choose the provider profile you wish to modify, and click on the Edit arrow.
By default the General view is displayed in the Navigation pane. All of the fields displayed in the General view contain the data that was entered during the creation of the hosted provider. If you modify any of the fields, click Save to save the changes.
To modify the Service Provider fields, choose Service Provider from the View menu.
The Assertion Consumer URL field contains data that was entered during the creation of the remote provider. However, there are four additional fields that you can modify:
Click Save to save the changes.
If the remote provider was defined as an identity provider during creation, you can modify the fields by selecting Identity Provider in the View menu. Most of the data contained in these fields were entered at creation.
In this view, you can additionally define the Identity Provider Authentication Context.
The fields are as follows:
Click Save to save the changes.
Select Authentication Domains in the View menu to edit the authentication domains to which the remote provider will belong.
Use the direction arrows to move a selected authentication domain into the Available list. Click Save. This will assign the provider to the authentication domain. A provider can belong to one or more authentication domains, however a provider without any authentication domains specified can not participate in Liberty communications.
Choose Trusted Providers from the View menu.
Choose the trusted providers. The remote provider will only accept request originated from this set of providers. The requests from other providers will be ignored. To create the list of trusted providers, select the providers from the Available field and use the Add button to add them to the Selected field. (You can remove providers by using the Remove button.) Click Save.
Choose Identity Server Configuration Attributes.
The fields are as follows:
Click Save to save the changes.
Previous Contents Index Next
Copyright 2002 Sun Microsystems, Inc. All rights reserved.
Last Updated December 04, 2002