Understanding the SiteMinder User Cases

This chapter describes three use cases, all built upon legacy SiteMinder deployments. In each use case, SiteMinder continues to provide authentication service for legacy applications even after OpenSSO Enterprise is installed to protect the same enterprise applications. SiteMinder and OpenSSO Enterprise typically co-exist in the following use cases:

• Simple Single Sign-On

• Federated Single Sign-On in a Service Provider Environment

• Federated Single Sign-On in an Identity Provider Environment

Single logout for any these of these use cases can be implemented in many ways. The logout for federation use cases must have a link in the partner portal for the following URL:

http:<sphost>:<spport>/opensso/saml2/jsp/spSingleLogoutInit.jsp?metaAlias=
<metaalias>&idpEntityID=<idp entityid>&RelayState=<integrated product logout url>

Single logout can also be achieved using Identity Provider-initiated single logout.

Simple Single Sign-On Use Case

In this use case, a SiteMinder instance is already deployed and configured to protect some of the enterprise applications in a company intranet. In the architecture figure below, the legacy application is contained in the Protected Resource . The company wants to continue leveraging SiteMinder for authentication purposes, while adding OpenSSO Enterprise to the environment to protect the same application. OpenSSO Enterprise is also used to protect all applications subsequently added to the enterprise.

An OpenSSO Enterprise policy agent protects the Protected Resource, while OpenSSO Enterprise itself is protected by a SiteMinder Web Agent. In this use case, an access request goes to OpenSSO Enterprise for policy evaluation or for single sign-on purposes. But the SiteMinder Web Agent, installed on the same container as OpenSSO Enterprise, redirects the user to the SiteMinder login page for authentication. The OpenSSO Enterprise custom authentication module validates the SiteMinder session depending upon whether or not the user has previously logged in to OpenSSO Enterprise. After successful login, the OpenSSO Enterprise custom authentication module uses the SiteMinder session to generate an OpenSSO Enterprise session. OpenSSO Enterprise then honors the user session obtained by the SiteMinder Policy Server.

Figure 2–1 Single Sign-On Architecture

In this use case, both OpenSSO Enterprise server and SiteMinder policy server share the same user repository for user profile verification. OpenSSO Enterprise could also be configured to ignore the profile option if it relies on SiteMinder session for attributes.

The following figure illustrates the process flow for single sign-on using both SiteMinder and OpenSSO Enterprise.

Figure 2–2 Single Sign-On Process Flow

Federated Single Sign-On Use Cases

The SAML, ID-FF, and WS-Federation protocols provide cross-domain single sign-on among multiple trusted business entities. These protocols are also used in Identity Federation. Identity Federation involves an Identity Provider, also known as an authentication provider, and a Service Provider where the user authentication session at the Identity provider is consumed. The following are common use cases in which SiteMinder is enabled for federation protocols:

• Enabling SiteMinder for federation protocols in a Service Provider environment

• Enabling SiteMinder for federation protocols in an Identity Provider environment

The deployment examples in this chapter are built upon simple single sign-on integration. You must set up single sign-on before enabling federation. For more information about setting up simple single sign-on, see the Sun OpenSSO Enterprise Deployment Example: Single Sign-On. After setting up simple single sign-on, you can enable SiteMinder for Federation in either the Identity Provider environment or in the Service Provider environment.

The federated single sign-on use cases are configured for transient federation. Transient federation assumes that the users exist only in the Identity Provider environment. The Service Provider honors user authentication at Identity Provider. The Service Provider then creates an anonymous session so that Service Provider applications, protected by single sign-on, can be accessed. During SAML interactions, user attribute information can be exchanged back to the Service Provider for authorization and other purposes.

Usually, bulk federation exists between Identity Provider and Service Provider. For more information about transient and bulk federation, see the OpenSSO Enterprise product documentation.

Federated Single Sign-On in an Identity Provider Environment

In this use case, the company uses SiteMinder in the Identity Provider environment to protect applications within the company intranet. As the company partners with external companies, the company deploys OpenSSO Enterprise in the Service Provider environment to leverage the SAMLv2 Federation protocols.

The following figure illustrates how SiteMinder can be enabled in an Identity Provider environment using OpenSSO Enterprise for federation protocols.

Figure 2–3 SiteMinder Federation in an Identity Provider Environment

In this deployment, OpenSSO Enterprise provides federated single sign-on among enterprise applications in partner environments, while SiteMinder continues to provide authentication. The following two figures illustrates a typical transaction flow.

Figure 2–4 Process Flow for SiteMinder Federation in the Identity Provider Environment

Figure 2–5 Process Flow for SiteMinder Federation in the Identity Provider Environment (continued)

Federated Single Sign-On Use Case in the Service Provider Environment

In this use case, the company uses SiteMinder in the Service Provider environment to protect legacy applications. OpenSSO Enterprise is installed to invoke Federation protocols. The OpenSSO Enterprise server includes a customized authentication module for handling SiteMinder sessions. A SiteMinder Web Agent is installed on the same OpenSSO Enterprise instance to protect OpenSSO Enterprise.

Figure 2–6 SiteMinder Federation in a Service Provider Environment

This use case includes two additional, lightweight components:

Custom Authentication Module (spAdapter)

This is an OpenSSO Enterprise SAMLv2 plug-in that processes operations after federated single sign-on login is completed and before the target URL is displayed. After the OpenSSO Enterprise session is established, the spAdapter plug-in uses the OpenSSO Enterprise session to communicate with the SiteMinder Custom Authentication Scheme.

Custom Authentication Scheme

This is a SiteMinder SAMLv2 plug-in. It uses the OpenSSO Enterprise configuration defined in the SAMLv2 metadata and the SAMLv2 session to generate a SiteMinder session.

When an access request comes from a partner application, the SiteMinder login page is displayed. If the user has already been authenticated, the OpenSSO Enterprise custom authentication module creates a session for the user. The custom authentication module consumes the SiteMinder session, and then generates a SAML assertion. The following two figures illustrate the steps in the single sign-on flow:

Figure 2–7 Process Flow for SiteMinder Federation in the Service Provider Environment

Figure 2–8 Process Flow for SiteMinder Federation in the Service Provider Environment (continued)