test

Sun OpenSSO Enterprise 8.0 Deployment Planning Guide

Examining a SAMLv2 Identity Federation Deployment Example

In a deployment configured for communication using SAMLv2, a Service Provider and an Identity Provider must be created within a circle of trust. The circle of trust enables business providers to easily conduct cross-network transactions for an individual while protecting the individual's identity.

Use the following deployment example to get a sense of how you can map your enterprise requirements to a SAMLv2 Identity Federation deployment architecture.

Identifying the Major Components

Identity Provider Deployment

An identity provider specializes in providing authentication services. As the administrating service for authentication, an identity provider maintains and manages identity information. It establishes trust with a service provider in order to exchange user credentials, enabling single sign-on between the providers. Authentication by an identity provider is honored by all service providers with whom the identity provider is partnered. The following image illustrates the identity provider architecture in this deployment.

Figure 2–2 Identity Provider Deployment Architecture

Illustrates where the identity provider components will be situated

The identity provider domain in this deployment is idp-example.com. The identity provider application represents a legacy system which relies on OpenSSO Enterprise to act as a secure gateway through which identity information can be transferred to another application in a different domain. This functionality is provided by the Secure Attribute Exchange feature of OpenSSO Enterprise which uses SAMLv2 without having to deal with federation protocol and processing.

The following list of components will be installed and configured in the Identity Provider environment.

Sun OpenSSO Enterprise

Two instances of OpenSSO Enterprise provide the core functionality. Each instance is created with a configuration data store. Configuration data includes information about services, administrative users, realms, policies, and more. Two instances of Sun Java System Application Server are installed on the OpenSSO Enterprise host machines into which the OpenSSO Enterprise WAR is then deployed.

User data is accessed through a single load balancer deployed in front of two instances of Sun Java System Directory Server.

Sun Java System Directory Server

Two instances of Directory Server provide storage for user entries that will be created for testing this deployment. Both instances of Directory Server are masters that engage in multi-master replication, providing high availability to the OpenSSO Enterprise layer.

Load Balancers

The load balancer hardware and software used for this deployment is BIG-IP® manufactured by F5 Networks. They are configured for simple persistence and deployed as follows:

  • OpenSSO Enterprise Load Balancer.

    This load balancer exposes the web-based OpenSSO Enterprise console to internal administrators. Alternatively, internal administrators can bypass this load balancer and log in directly.

  • Directory Server Load Balancer.

    The load balancer in front of the Directory Server instances provide round-robin load balancing and a single virtual Directory Server host name. It detects individual Directory Server failures and recoveries, taking failed servers off the load balancer list.

Service Provider Deployment

A service provider offers web-based services to an identity. This broad category can include portals, retailers, transportation providers, financial institutions, entertainment companies, libraries, universities, governmental agencies, and other organizations that consume identity information for purposes of access. The following figure illustrates the Service Provider architecture in this deployment.

Figure 2–3 Service Provider Deployment Architecture

Illustrates where the service provider components will be situated

The service provider domain in this deployment is sp-example.com. The service provider application represents a legacy system which relies on OpenSSO Enterprise to act as a secure gateway through which identity information can be received from the identity provider. This functionality is provided by the Secure Attribute Exchange feature of OpenSSO Enterprise which uses SAMLv2 without having to deal with federation protocol and processing.

The following list of components will be installed and configured using the procedures documented in Deployment Example: SAML v2 Using Sun OpenSSO Enterprise 8.0.

Sun OpenSSO Enterprise

Two instances of OpenSSO Enterprise provide the core functionality. Each instance is created with a configuration data store. Configuration data includes information about services, administrative users, realms, policies, and more.

Sun Java System Directory Server

Two instances of Directory Server provide storage for user entries that will be created for testing this deployment. User data is accessed through a single load balancer deployed in front of two instances of Sun Java System Directory Server. Both instances of Directory Server are masters that engage in multi-master replication, providing high availability to the OpenSSO Enterprise layer.

Sun Java System Application Server

Two instances of Sun Java System Application Server are installed on the OpenSSO Enterprise host machines into which the OpenSSO Enterprise WAR is then deployed.

Load Balancers

The load balancer hardware and software used for this deployment is BIG-IP® manufactured by F5 Networks. They are deployed as follows:

  • OpenSSO Enterprise Load Balancer

    This load balancer exposes the web-based OpenSSO Enterprise console to internal administrators. Alternatively, internal administrators can bypass this load balancer and log in directly.

  • Directory Server Load Balancer

    The load balancer in front of the Directory Server instances provides round-robin load balancing and a single virtual Directory Server host name. It detects individual Directory Server failures and recoveries, taking failed servers off the load balancer list.

Sun OpenSSO Enterprise Policy Agents

Policy agents are used to restrict access to hosted content or applications. The policy agents intercept HTTP requests from external users and redirect the request to OpenSSO Enterprise for authentication. Web policy agents protect any resources under the doc root of the web container. J2EE policy agents protect a variety of hosted J2EE applications; in this deployment, agentsample is used. The agents communicate with the OpenSSO Enterprise instances through the configured load balancer.

Protected Resource Host Machine

The protected resource host machine contains the content for which access is restricted. BEA WebLogic Server and a J2EE policy agent is installed. Sun Java System Web Server a web policy agent is also installed. Additionally, a sample JSP is installed to act as the legacy application for purposes of demonstrating the Secure Attribute Exchange feature.

For step‐by‐step instructions for deploying these components as illustrated in this chapter, see Deployment Example: SAML v2 Using Sun OpenSSO Enterprise 8.0.

Designing the SAMLv2 Identity Federation Architecture

Once you've identified the major components you need in the Service Provider and Identity Provider environments, you can build your deployment architecture to map to your enterprise needs. In this deployment example, the deployment architecture is designed to achieve the most basic OpenSSO Enterprise circle of trust. The architecture is designed to meet the following enterprise requirements: