Chapter 5 Federation Management, SAML, and Web Services

This chapter explains the concept of identity federation, and describes the role of the Federation Management feature in Access Manager. For detailed information about enabling or managing identity federation, or using the Federation Management APIs and SPIs, see the Sun Java System Access Manager 7 2005Q4 Federation and SAML Administration Guide.

This chapter includes the following topics:

• The Need for Federated Identities

• The Liberty Alliance Project

• Federation Management Implemented in Access Manager

• Federation Management Protocols Flow

The Need for Federated Identities

Consider 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. He may finalize his travel plans via his travel agent’s website, and then 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 particular 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 as an account number to the car rental agency he uses frequently. He is known to his favorite airline 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. Each of these different user names represents a different local identity.

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 travel agency, then book airline tickets online, and make hotel reservations online. It is a convenience for the user to be able to access all of these services without having to provide different user names and passwords at each service site. It is a valuable benefit to the user when he can do so safely, and knowing that his identity information is secure.

The Liberty Alliance Project was implemented to make this possible.

The Liberty Alliance Project

In 2001 Sun Microsystems joined with other major companies to form the Liberty Alliance Project, the premier open standards organization for federated identity and identity-based services. The members of the Liberty Alliance Project represent some of the world's most recognized brand names and service providers. Liberty Alliance Project members drive products, services and partnerships across a spectrum of consumer and industrial products, financial services, travel, retailing, telecommunications and technology.

Access Manager implements two important sets of standards adopted by the Liberty Alliance Project: the Liberty Alliance Project frameworks, and the Security Assertions Markup Language (SAML) specifications. These implementations enable business partners to form a Circle of Trust.

Liberty Alliance Frameworks

The Access Manager Federation Management feature is built upon Liberty Alliance frameworks. The Liberty Alliance Project developed the following specifications and guidelines for implementing complete network identity infrastructures and for deploying identity-based web services:

• Identity Federation Framework (ID-FF)

• Identity Web Services Framework (ID-WSF)

• Data Services Template (ID-WSF DST)

• Identity Services Interface Specifications (ID-SIS)

For more information these specifications, and listings of Liberty web service products, case studies, and white papers, see the Liberty Alliance Project website: http://www.projectliberty.org/

The Circle of Trust

The goal of the Liberty Alliance Project is to enable individuals and organizations to easily conduct network transactions while protecting the individual’s identity. This goal can be achieved only when commercial and non-commercial organizations join together into a circle of trust. In a circle of trust, service providers agree to join together in order to exchange user authentication information using Liberty web service technologies. This circle of trust must contain at least one identity provider, a service that maintains and manages identity information. The circle of trust also includes service providers that offer web-based services to users. Once a Circle Of Trust is established, single sign-on is enabled between all the providers.

In Access Manager, the circle of trust is known as an authentication domain although it is not a DNS domain. In Access Manger, an authentication domain describes entities that are grouped together for the purpose of identity federation.

A travel portal is a good example of an authentication domain. Typically, a travel portal is a website designed to help you find an access various travel service providers from one Internet location. The travel portal service forms a partnership with each hotel, airline, and car rental agency displayed on its website. The user logs into the travel portal and looks for a suitable hotel. When finished making hotel reservations, the user moves to the airline part of the travel portal to look for a suitable airline flight. This time, because of the partner agreement with the travel portal, the airline website shares the authentication information obtained earlier in the user's online session. The user moves from the hotel reservations website to the airline reservations website without having to re-authenticate. All of this is transparent to the user. The following figure illustrates the Circle of Trust formed among the travel portal, which acts as the Identity Provider, and each of the related business partners.

Figure 5–1 The Circle of Trust

Account federation occurs when a user chooses to unite distinct service accounts and identity provider accounts. The user retains individual account information with each provider in the circle. At the same time, the user establishes a link that allows the exchange of authentication information between them. Users can choose to federate any or all identities they might have with the service providers that have joined this circle. When a user successfully authenticates with one service provider, she can access any of the her accounts within the circle of trust in a single session without having to reauthenticate.

SAML Specifications

Access Manager uses the Security Assertion Markup Language (SAML) for exchanging security information. SAML resides within a system's security mechanisms to enable exchange of authentication and authorization information with other services. The SAML 1.0 specification set was submitted to the Organization for the Advancement of Structured Information Standards (OASIS) in March 2002 for standardization by the OASIS Security Services Technical Committee. OASIS is a not-for-profit, global consortium that drives the development, convergence and adoption of e-business standards.

SAML security information is expressed in the form of an assertion about a subject. A subject is an entity in a particular domain, either human or machine, with which the security information concerns itself. (A person identified by an email address is a subject as might be a printer.) An assertion is a package of verified security information that supplies one or more statements concerning a subject’s authentication status, access authorization decisions or attributes. Assertions are issued by a SAML authority. (An authority is a platform or application that has been integrated with the SAML SDK, allowing it to relay security information.) The assertions are received by partner sites defined within the authority as trusted. SAML authorities use different sources to configure the assertion information including external data stores or assertions that have already been received and verified.

Federation Management Implemented in Access Manager

In Access Manager, the Federation Management feature enables applications to participate in three different frameworks:

• Identity Federation Framework

• Identity Web Services Framework

• SAML 1.0 and 1.1 Specifications

These frameworks enable service providers to securely exchange authentication and authorization information. Client APIs are provided for web service consumers to communicate with web service providers. The following figure illustrates the internal architecture of a Liberty Web Services Consumer and a Web Service Provider.

Figure 5–2 Web Services Consumer and Web Service Provider Architecture

The Web Service Consumer components and the Web Service Provider components are newly implemented components in Access Manager. The components in the bottom layer of the Web Service Provider were implemented in Access Manager 6.1. These components include Single-Sign On (SS0), the Access Manager SDK, Service Management Services, SAML, Authentication modules, and a Policy Service. In the Identity Web Service Framework, the Data Service and Identity Service represent custom services that you can add to the Web Services Framework.

Identity Federation Framework

The Identity Federation Framework (ID-FF) specifies core protocols, schema and concrete profiles that allow developers to create a standardized, multiple-vendor, identity federation network. These include the following:

Account linking termination.

Users can choose to stop their account federation.

Authentication context.

Service providers with federated accounts communicate the type and level of authentication that should be used when the user logs in.

Affiliation federation

Federation based on group affiliation can be enabled in an authentication request. If enabled, it would indicate that the requester is acting as a member of the affiliation group identified. Federations are then established and resolved based on the affiliation, and not the requesting provider. The process allows for a unique identifier that represents the affiliation.

Dynamic identity provider proxying

When one identity provider is asked to authenticate a principal that has already been authenticated by a second identity provider. In this case, the first identity provider may request authentication information from the second identity provider on behalf of the service provider. Proxy behavior can be controlled by indicating a list of preferred identity providers, and a value that defines the maximum number of proxy steps that can be taken. Proxy behavior is defined locally by the proxying identity provider, although a service provider controls whether or not to proxy.

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 individual who interacts with the system. This is important when there are multiple identity providers in an identity federation network.

Name Identifier Mapping Protocol

Defines how service providers can obtain name identifiers assigned to a principal that has federated in the name space of a different service provider. When a principal that has an identity federation relationship (and therefore a name identifier) with one service provider requests access to a second service provider site that requires a name identifier, the second service provider can use this protocol to obtain the identifier. It allows the requesting service provider to communicate with the second service provider about the principal even though no identity federation for the principal exists between them.

Name Registration

Enables a service provider or identity provider to register with each other a new name identifier for a principal at any time following federation.

One-time federation

The ability to federate for one session only can be enabled in an authentication request. This is useful for service providers with no user accounts, for principals who wish to act anonymously, or for dynamically-created user accounts. It allows for one-time federation, rather than a one-time name identifier for a session.

Opt-in account linking

Users can choose to federate different service provider accounts.

Single Sign-on and Federation Protocol

The protocol that 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. Two types of Single Sign-On exist which either the identity or service provider can implement:

• SOAP-based Single Sign On and Federation Protocol, which relies on a SOAP call from provider to provider. This is primarily the Browser Artifact SSO profile.

• Form POST-based Single Sign On and Federation Protocol, which rely on an HTTP form POST to communicate between providers.

Single Sign-Out Protocol

The protocol used to synchronize the session log-out functionality across all sessions that were authenticated and created by a particular identity provider. Two types of protocols exist which either the identity or service provider can implement:

• SOAP-based Single Log-Out Protocol relies on asynchronous SOAP messaging calls between providers.

• HTTP Redirect-based Single Log-Out Protocol

Identity Web Services Framework

The Web Services Framework (ID-WSF) consists of a set of schema, protocols and profiles for providing a basic identity services, such as identity service discovery and invocation. Three parties are required for identity federation in a basic Liberty Web Services environment: a user agent, a web service consumer, and a web service provider.

The Web Services Framework consists of a set of schema, protocols and profiles for providing a basic identity services, such as identity service discovery and invocation. This framework includes the following:

Authentication Web Service

An identity service that enables a web service consumer to be authenticated using the Simple Authentication and Security Layer (SASL) mechanism. SASL defines a method for adding authentication support to connection-based protocols.

Discovery Service.

An identity service that allows a requester to discover resource offerings.

SOAP Binding.

A set of Java APIs for sending and receiving ID-* messages using SOAP and XML.

Security Mechanisms.

Defines a set of authentication mechanism and security properties which are factored into authorization decisions enforced by the targeting identity-based web services. Each mechanism contains both peer entity authentication (null/TLS/CClientTLS) and message authentication (null/X509/SAML).

Interaction Service.

A protocol for simple interaction of Web Services Framework participants with a Principal.

Trusted Authority.

APIs for creating security tokens used for authentication and authorization in Liberty II-enabled services.

Metadata Service.

A library of command-line tools for loading metadata into the Access Manager data store.

Reverse HTTP Bindings.

A protocol and set of APIs for retrieving data from Access Manager via clients such as cell phones.

SAML Service

SAML defines an eXtensible Markup Language (XML) framework to achieve interoperability across different vendor platforms that provide SAML assertions. SAML is an XML framework for exchanging security information over the Internet. Access Manager SAML Service consists of a web service interface, a SAML core component, and a SAML framework that web services can connect to.

The Access Manager SAML Service enables the following functionality:

• Users can authenticate against Access Manager and access trusted partner sites without having to reauthenticate. This single sign-on process independent of the process enabled by Access Manager user session management.

• Access Manager acts as a policy decision point (PDP), allowing external applications to access user authorization information for the purpose of granting or denying access to their resources.

• Access Manager acts as both an attribute authority (allowing trusted partner sites to query a subject’s attributes) and an authentication authority (allowing trusted partner sites to query a subject’s authentication information.)

• Two parties in different security domains can validate each other for the purpose of performing business transactions.

• Access Manager SAML APIs can be used to build Authentication, Authorization Decision and Attribute Assertions.

• The Access Manager SAML Service provides pluggable XML-based digital signature signing and verifying.

Federation Management Protocols Flow

The following figure provides a high-level view of the system flow between various parties in a Liberty web services environment. A user agent, Service Provider, Identity Provider, and Personal Profile Service must be present in the environment. The figure and text illustrate the use of both Identity Federation Framework and Identity Federation Web Services Framework.

In this example:

• The web browser represents a user agent or a device used by an enterprise user.

• A Service Provider acts as a web services consumer (WSC) to invoke the web service on behalf of the user. The Service Provider relies on the Identity Provider authentication for single sign-on.

• The Identity Provider acts an authentication provider by authenticating the user and registering the user. The Identity Provider also acts a trusted authority, issuing security tokens through the Discovery Server.

• The Web Services provider serves requests from web services clients such as a Personal Profile Service provider.

Figure 5–3 Identity Federation Protocols Flow

When a user logs into a circle of trust, the following events occur.

1. The Service Provider initiates the AuthnRequest.

   The request uses a browser artifact profile to contact the Single Sign-On service at the Identity Provider.

2. At the Identity Provider, the Single Sign-On service presents a login page to the user.

   The user enters credentials such as username and password.

3. Upon successful authentication, at the Identity Provider the Single Sign-On service sends an artifact to the Assertion Consumer service at the Service Provider.

4. The Identity Provider sends a SAML SOAP response to the Service Provider by keeping an authentication SML assertion in the response.

5. The Service Provider verifies the XML assertion and completes the Single Sign-On process.

   The assertion contains an attribute statement containing the Discover Service resource offering. The resource offering will be used as bootstrap information to invoke the Web Services Framework.

6. The user’s browser, Service Provider and Identity Provider complete the Federation Single-Sign-On process.

   An assertion with an attribute statement containing the Discovery Service resource offering is included in the ID-FF AuthnResponse. This information can be used by any client to contact Discovery Service.

7. The user’s browser requests access to services hosted on the Web Service Consumer.

   This requires contacting user’s Personal Profile service.

8. The Web Service Consumer sends a discovery lookup query to the Discovery Service.

   The Web Service Consumer determines user’s discovery resource offering from the bootstrap Assertion obtained earlier, then sends a discovery lookup query to the Discovery Service to determine where the user’s Personal Profile instance is hosted.

9. The Discovery service returns a discovery lookup response to the Web Service Consumer.

   The lookup response contains the resource offering for the user’s Personal Profile Service instance.

10. The Web Service Consumer sends a web services query that uses the protocol defined by the DataServiceTemplate. The web services query goes to the SOAP end point of the Personal Profile Service instance.

    The query asks for the user’s personal profile attributes, such as home phone number. The required authentication mechanism specified in the Personal Profile Service resource offering must be followed.

11. The Personal Profile Service instance authenticates and validates authorization or policy, or both, for the requested user or Web Service Consumer, or for both.

    If user interaction is required for some attributes, the Interaction Service will be invoked to query the user for consents or for attribute values. The Personal Profile Service instance returns a Data Services Template response to the Web Service Consumer after collecting all required data.

12. The Web Service Consumer processes the Personal Profile Service response, and then renders service pages containing the colleague’s contact information to the user’s browser.

For detailed information about all the components that are involved in Federation Management, see the Sun Java System Access Manager 7 2005Q4 Federation and SAML Administration Guide.