test

Sun OpenSSO Enterprise 8.0 Developer's Guide

Chapter 5 Understanding the Federation Options

Sun OpenSSO Enterprise has a robust framework for implementing a federated identity infrastructure. A federated identity infrastructure allows single sign-on that crosses internet domain boundaries. This chapter contains the following sections.

Understanding Federation

The umbrella term federation encompasses both identity federation and provider federation. The concept of identity federation begins with the notion of a virtual identity. On the internet, one person might have a multitude of accounts set up for access to various business, community and personal service providers. In creating these accounts, the person might have used different names, user identifiers, passwords or preferences to customize, for example, 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 of these service providers. These attributes uniquely identify the individual for that particular provider and can include a name, phone number, passwords, social security number, address, credit records, bank balances or bill payment information. After implementing a federated identity infrastructure, a user can associate, connect or bind the local identities they have configured with multiple service providers into a federated identity. With a federated identity the user can then login at one service provider's site and move to an affiliated (trusted) service provider site without having to reauthenticate or re-establish their identity.

The concept of provider federation as defined in a federation-based environment begins with the notion of a security domain (referred to as a circle of trust in OpenSSO Enterprise). A circle of trust is a group of service providers (with at least one identity provider) that agree to join together to exchange user authentication information using open standards and technologies. Once a group of providers has been federated within a circle of trust, authentication accomplished by the identity provider in that circle is honored by all affiliated service providers. Thus, federated single sign-on can be enabled amongst all membered providers as well as identity federation among users. For more information on the federation process in OpenSSO Enterprise, see the Sun OpenSSO Enterprise 8.0 Technical Overview.

Understanding Federated Single Sign-on

Federated single sign-on allows authentication among multiple internet domains using multiple authentication authorities — with one authority asserting the identity of the user to the other. OpenSSO Enterprise supports the following federation specifications:

Here are some general rules to follow when deciding which federation option will work best in your environment.

For more information, see Chapter 11, Choosing a Federation Option, in Sun OpenSSO Enterprise 8.0 Technical Overview.

Note –

The proprietary OpenSSO Enterprise single sign-on mechanism, due to its dependency on browser cookies, is limited to single sign-on within a single internet domain only. The proprietary OpenSSO Enterprise cross domain single sign-on (CDSSO) mechanism uses a single authentication authority which means only one user identity can exist in the entire system. If the situation fits, CDSSO may be a solution worthy of further evaluation.

  1. Only Sun products (OpenSSO Enterprise and agents) are involved.

  2. All policy agents are configured to use the same OpenSSO Enterprise instance where multiple instances are available.

  3. Multiple instances of OpenSSO Enterprise, configured for high-availability, must all reside in a single DNS domain.

Only policy agents can reside in different DNS domains. For more information on these proprietary features, see Part II, Access Control Using OpenSSO Enterprise, in Sun OpenSSO Enterprise 8.0 Technical Overview.

Federated Single Sign-on Using OpenSSO Enterprise

In order to communicate identity attributes for the purpose of federated single sign-on, you need, at the least, two instances of OpenSSO Enterprise configured in one circle of trust. Circles of trust configured for real time interactions must have, at the least, one instance of OpenSSO Enterprise acting as the circle's identity provider and one instance of OpenSSO Enterprise acting as a service provider. To prepare your instances of OpenSSO Enterprise, you need to exchange and import the metadata for all participating identity and service providers, and assemble the providers into a circle of trust. The following steps are an overview of the process.

  1. Decide whether the instance of OpenSSO Enterprise you are configuring will act as either an identity provider, a service provider, or both.

  2. Create standard and extended metadata configuration files containing the appropriate metadata for your organization. See Chapter 1, ?ssoadm Command Line Interface Reference,? in Sun OpenSSO Enterprise 8.0 Administration Reference.

  3. Create a circle of trust.

  4. Import your organization's provider metadata into the circle of trust.

  5. Determine which organizations will be added to the circle of trust as identity providers and service providers and import a standard and an extended metadata configuration file for each.

    Note –

    The values in these files will come from the providers themselves.

  6. Import the provider metadata into the circle of trust

See Chapter 7, Configuring and Managing Federation, in Sun OpenSSO Enterprise 8.0 Administration Guide for more information.

Executing a Multi-Protocol Hub

Because of the federation options available, OpenSSO Enterprise has implemented a new feature: the multi-protocol hub. The multi-protocol hub is an identity provider that supports all federation protocols implemented in OpenSSO Enterprise. It enables seamless single sign-on and single logout with service providers that communicate using the different federation protocols. OpenSSO Enterprise ships with a multi-protocol hub sample that demonstrates single sign-on and single logout within one hub that includes one Liberty ID-FF service provider, one SAML v2 service provider and one WS-Federation service provider. The sample is located in /path-to-context-root/opensso/samples/multiprotocol. Open index.html for more information.