Sun OpenSSO Enterprise 8.0 Technical Overview

Chapter 10 Federation Management with OpenSSO Enterprise

Sun OpenSSO Enterprise provides a pluggable framework for implementing federated identity infrastructures. The Federation framework places no restrictions on the use of network technologies, computer hardware, operating systems, programming languages or other hardware or software entities. It is based on, and conforms to, open industry standards to achieve interoperability among different vendors on heterogeneous systems, and provides the facility to log identity interactions and erroneous conditions. The following sections contain information about the federation framework.

Key Federation Management Features

OpenSSO Enterprise creates a comprehensive security and identity management framework optimized to work with, and extend, an identity provider's existing security infrastructure. The following list describes some key features:

Exchange of credentials and security tokens across circle of trust partners for purposes of authentication and single sign-on.
Automatic federation of user accounts across multiple security domains.
Session management across authentication domains to determine when user interactions must be terminated (single logout).
Import or export the data required to establish basic federated communication between providers.
Manages and links providers that are available to participate in a circle of trust.
Exchanges SAML security assertions among providers in a circle of trust.
Data management choices include an LDAPv3 directory (OpenDS, Sun Java System Directory Server or Microsoft Active Directory).
Included service provider interfaces (SPIs) to allow customized logic during the federation process.
Support for bulk federation and auto federation.
Support for The Fedlet, a web archive (WAR) of data that can be embedded into a service provider application.
Support for Virtual Federation.
Support for multiple federation protocols in one circle of trust.

The following sections contain additional information on the final three features listed.

The Fedlet

Fedlet is the name given to fedlet.war. The WAR is a very small archive of a few JARs, properties, and metadata (all stored in flat files) that can be embedded into a service provider's Java EE web application to allow for SSO between an identity provider instance of OpenSSO Enterprise and the service provider application - WITHOUT installing OpenSSO Enterprise on the service provider side. The service provider simply downloads the Fedlet, modifies their application to include the Fedlet JARs and, re-archives and redeploys the modified application. The service provider is now able to accept an HTTP POST (that contains a SAML v2 assertion) from the identity provider and retrieve included user attributes to accomplish SSO. (Currently, the Fedlet only supports the HTTP POST Profile.). The Fedlet can communicate with multiple identity providers, using a Discovery Service to find the preferred identity provider. For more information, see the Sun OpenSSO Enterprise 8.0 Administration Guide.

Secure Attribute Exchange/Virtual Federation Proxy

Secure Attribute Exchange (also referred to as Virtual Federation Proxy) provides a mechanism for one application to communicate identity information to a second application in a different domain. In essence, it provides a secure gateway that enables legacy applications to communicate authentication attributes without having to deal specifically with federation protocols and processing. Virtual Federation Proxy allows:

Identity provider applications to push user authentication, profile and transaction information to a local instance of OpenSSO Enterprise which then passes the data to a remote instance of OpenSSO Enterprise at the service provider using federation protocols.
Service provider applications to consume the received information.

Virtual Federation Proxy uses SAML v2 to transfer identity data between the communicating entities. The Client SDK (which contains Java and .NET interfaces) runs independent of OpenSSO Enterprise and enables existing applications to handle the SAML v2 interactions. The following diagram illustrates this scenario.

Figure 10–1 Virtual Federation Architecture

The following use cases are applicable to Virtual Federation:

Authentication at Identity Provider

When a user is already authenticated within an enterprise, the legacy identity provider application sends a secure HTTP GET/POST message to OpenSSO Enterprise asserting the identity of the user. OpenSSO Enterprise verifies the authenticity of the message and establishes a session for the authenticated user. You can use Virtual Federation to transfer the user's authentication information to the local instance of OpenSSO Enterprise in order to create the session.

Virtual Federation at Identity Provider

When a user is already authenticated by, and attempts access to, a legacy identity provider application, the legacy application sends a secure HTTP POST message to the local instance of OpenSSO Enterprise asserting the user's identity, and containing a set of attribute/value pairs related to the user (for example, data from the persistent store representing certain transactional states in the application). OpenSSO Enterprise verifies the authenticity of the message, establishes a session for the authenticated user, and populates the session with the user attributes.

Virtual Federation at Service Provider

When a user is already authenticated by the instance of OpenSSO Enterprise at the identity provider and invokes an identity provider application that calls for redirection to a service provider, the identity provider invokes one of the previous use cases and encodes a SAML v2 SSO URL as a part of the request. The identity provider instance of OpenSSO Enterprise then initiates SAML v2 SSO with the instance of OpenSSO Enterprise at the service provider. The service provider's instance of OpenSSO Enterprise then verifies the SAML v2 assertion and included attributes, and redirects to the service provider application, securely transferring the user attributes via a secure HTTP POST message. The service provider application consumes the attributes, establishes a session, and offers the service to the user.

Global Single Logout

When a user is already authenticated and has established, for example, SSO with the instance of OpenSSO Enterprise at the service provider, the user might click on a Global Logout link. The identity provider will then invalidate its local session (if created) and trigger SAML v2 single log out by invoking a provided OpenSSO Enterprise URL. The OpenSSO Enterprise identity provider executes the SAML v2 single log out, terminating the session on both provider instances of OpenSSO Enterprise.

Note –

An identity provider side application can initiate single logout by sending sun.cmd=logout attributes via a Virtual Federation interaction to a local instance of OpenSSO Enterprise acting as the identity provider. In turn, this instance will execute SAML v2 single logout based on the current session.

For more information, see the Sun OpenSSO Enterprise 8.0 Administration Guide.

Multi-Federation Protocol Hub

OpenSSO Enterprise allows a configured circle of trust to contain entities speaking different federation protocols thus supporting cross protocol single sign-on and logout among hosted identity providers in the same circle of trust. For example, you can create a circle of trust containing one identity provider instance that communicates with multiple federation protocol and three service provider instances that speak, respectively, Liberty ID-FF, SAML v2 and WS-Federation. Figure 10–2 illustrates the process of multi-federation protocol single sign-on and single logout.

Figure 10–2 Multi-Federation Protocol Single Sign-on and Single Logout

Process of multi-federation protocol single sign-on
and single logout

For more information, see the Sun OpenSSO Enterprise 8.0 Administration Guide.

The Federation Framework Architecture

OpenSSO Enterprise consists of web-based services [using SOAP, XML over HTTP(S) or HTML over HTTP(S)], and Java—based application provider interfaces (APIs) and service provider interfaces (SPIs). The figure below illustrates this architecture. Additionally, the figure shows an agent embedded into a web container. This agent enables the service provider applications to participate in the SAML or Liberty-based protocols. The darker boxes are components provided by OpenSSO Enterprise.

Figure 10–3 Federation Framework Architecture

This figure illustrates the federation framework
architecture.

The components include:

SAML Service: Provides SAML related services (versions 1.x and 2.0) including artifact and POST profile support, and assertion query support.
Liberty Identity Federation Framework (Liberty ID-FF): Provides services based on the Liberty ID-FF specifications. Features include federation and single sign-on, single logout, federation termination, name registration, and support for the Common Domain. Implemented web services include a SOAP binding service, a discovery service, a personal profile service, and an authentication service.
WS-Federation: Provides services based on the WS-Federation specifications.
Authentication: OpenSSO Enterprise provides a JAAS-based authentication framework.
Session: OpenSSO Enterprise provides session management for service provider applications.
Logging: OpenSSO Enterprise provides a logging service. It also provides activity logs for auditing. Audit logs can be stored in flat files or JDBC-compliant databases.
APIs: Includes a set of APIs for interaction between the SSO, logging, SAML, federation, and authentication components. Also included are APIs to build web services for clients and providers.
SPIs: Includes a set of Service Provider Interfaces (SPIs) into which applications can insert their custom logic. For instance, there is an SPI to do post federation processing, and an SPI for post processing after a successful single logout.