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