Access Integration::Single Sign-On application pattern: Runtime patterns

Single Sign-on can be implemented in several ways. As illustrated previously in the Application pattern figures, the implementation choices can be divided into two classes: those that secure access through the Web tier only and those that extend the security context to include the back-end systems.

Web Single Sign-On runtime patterns
Single Sign-On (SSO) performed in the Web tier is appropriate for environments with no back-end systems or where access to back-end systems does not need to be executed under the Web user’s identity. Examples include e-commerce sites and customer portals.

The key consideration in establishing a Web Single Sign-On solution is the diversity of the e-business environment. There are two key types of environments to consider: a homogeneous application server environment or a heterogeneous environment (multiple vendors/versions of application servers).

Homogeneous application server
Design Last Updated: 3-2002

The homogenous application server design above illustrates how a Web tier environment where all applications are implemented on the same application server can exploit that application server's security server for single sign-on functionality.

The benefits of this design are that it enables a simple, effective security model for applications built within the same application server environment. The disadvantage is that it does not support applications outside the application server domain.

Heterogeneous application servers
Design Last Updated: 3-2002

A Web tier with multiple different vendor application servers can only implement Single Sign-On with the deployment of a separate security server. The external security server provides an authentication proxy that intercepts requests to map or transform user credentials into the appropriate credential format for that application server.

The benefits of this design is that it provides a unified, secure authentication model, and supports multiple vendors/platforms.

Its disadvantages include:

• It requires modification and migration to include existing applications.
• It can be difficult to model the separation or aggregation of authorization data across many applications.
• It requires that applications support an externally-managed security proxy.

Example
WebSphere Commerce Suite is an example of an application that manages its own internal mechanism for authentication (form-based) and authorization (role-based). However, it is possible to establish trust relationships between WebSphere Commerce Suite and the larger enveloping domains of WebSphere Application Server and Secureway Policy Director by sharing a common user registry or by configuring Commerce Suite to accept an LTPA token as proof of authentication. In this configuration, WebSphere Commerce Suite will accept the user as an authenticated user. Its authorization service will remain in effect and determine permissions based on the user identity in the LTPAtoken. For more information on this topic, see the IBM redbook LDAP Implementation Cookbook, SG24-5110.

Extended Single Sign-On runtime patterns
There are two major approaches to implementing the Extended Single Sign-On application pattern: Credential propagation and Central Authorization service.

Credential propagation
Design Last Updated: 3-2002

Extending the security context to back-end systems enables non-repudiation of transactions initiated by the user at the back-end. Credential propagation takes one of two approaches:

• Credential mapping, where the Web user identity is mapped to a user ID used to access the back-end system.
• Credential transformation, where the Web user identity is forwarded to the back-end system but is transformed into the format acceptable to that system.

The main benefit of a credential propagation design is that it allows for maximum flexibility and incorporation of non-compliant applications. Its disadvantages are that it introduces complexities related to credential management, and introduces requirements for additional error handling and transaction support at each application node.

Central Authorization service
Design Last Updated: 3-2002

Another alternative for extending the security context to back-end systems is to allow the same security service that controls the Web tier to control the back-end applications. The security server provides the role-based authorization for controlling back-end resources. No credential mapping or transformation is required. The security context is preserved all the way through to the back-end system.

The benefits of this solution is that it simplifies user management across all applications, and unifies user profile information and reduces redundancy.

Its main disadvantage is that it requires all applications to support the chosen security proxy and may require complex modification and migration.

Design considerations
There are some characteristics of the applications that will affect the solution of choice:

• Does the application let the application server do the authorization? If not, a proxy solution may be required.
• When incorporating an existing application with its own security model into a larger security domain, deactivate the application's security mechanism, if possible, and defer authentication and authorization to the larger secure domain.
• If the application requires a form-based login, there may be no solution short of modifying the application or providing custom code to wrap the application and simulate the posting of the application's login form.

What's Next
Next, review Combined Runtime patterns that merge functionality from the Single Sign-On and Personalized Delivery application patterns.