D3.1: Overview on IMS

 

Cross-Domain Single Sign-On

 

An essential functionality of the Access Manager component provides mechanisms for SSO. With SSO, a user that has been authenticated to the Access Manager may use any application managed by the Access Manager without having to re-authenticate. In the following, we consider web-based SSO only. In this scenario, the user interacts with the Access Manager authentication interface via his browser, which holds a cookie containing authentication credentials, i.e. the user’s session identifier, after a successful authentication. Whenever the user tries to access a resource protected by the Access Manager, the information within the cookie is used by the protected resource to determine whether the user may be granted access to the resource. For security reasons, however, cookies are assigned to specific domains and may subsequently only be accessed by servers in the respective domain. Therefore problems arise when the Access Manager is used to manage applications within different domains, because the information required to grant access to a user is not available to applications within different domains. 

In order to enable Cross-Domain Single Sign-On (CDSSO), the Access Manager provides a CDSSO component issuing cookies for a specific domain. Therefore, all different participating domains require a CDSSO component, which is in each case installed as a servlet into a web server of the respective domain. A complete CDSSO authentication process contains a rather large number of necessary steps, most of which are hidden from the user. Once the authentication is complete, however, subsequent request are processed in a straightforward manner without the necessity of cross-domain redirects. 

The following components participate in a CDSSO authentication process, as shown in .

1. The browser representing the client requesting authentication;

2. The web server representing the protected resource the browser attempts to access, including an SSO agent protecting the resources accessible via the web server;

3. The CDSSO component (located in the same domain as the web server) issuing authentication cookies;

4. The Access Manager (located in a different domain than the web server) including a CDSSO servlet acting as a broker between components.

 

Figure : A Cross-Domain SSO authentication process

 

A Cross-Domain SSO authentication process 

The CDSSO authentication process contains the following five steps, as shown in :

1. The initial request by the browser to access a resource in the domain D1. This request is sent to the web server of the respective domain (step 1). The SSO agent checks the request for an authentication token and redirects the request to the CDSSO component (steps 2, 3), because an authentication token is not present.

2. The redirect to the authentication interface in the domain D2. The CDSSO component redirects the request to the CDSSO servlet of the Access Manager (steps 4, 5). Again, the request is checked for an authentication token and redirected to the Access Manager authentication interface (steps 6, 7), because the token is not present. The user now authenticates successfully.

3. The redirect back to the web server representing the protected resource. After successful authentication, a cookie is stored for the domain D2 and the browser is redirected to the resource that originally had been attempted to access (steps 8, 9). The SSO agent checks the request for an authentication token one more time and redirects the request to the CDSSO component again (steps 10, 11), because there is only a token present for the domain D2, but not for the domain D1 of the protected resource.

4. Another redirect to the authentication interface in the domain D2, similar to the second stage. The CDSSO component redirects the request to the CDSSO servlet of the Access Manager (steps 12, 13). This time, an authentication token for the domain D2 is present. The request is redirected to the CDSSO component in the domain D1 (steps 14, 15). The authentication token is included as a URL parameter in the request and used by the CDSSO component to set a cookie in the domain D1. Then, the request is redirected for the last time to the web server representing the protected resource (step 16).

5. The process completion. The browser finally requests to access the requested resource (step 17). The cookie for domain D1 includes the authentication token, which the SSO agent validates successfully via the Access Manager (not shown in ). Access to the requested resource is granted.

 

Chaining of Authentication Mechanisms

 

Another aspect supported by the Access Manager is the possibility to configure authentication modules in a way that the user must provide authentication credentials to different modules within a chain. The modules within the chain are used, one by one, to process an authentication step that may either succeed or fail. The entire authentication process is terminated successfully when the end of the chain is reached, the last module in the chain succeeds to authenticate and no modules marked as “required” have failed to authenticate. Furthermore, the process is terminated successfully immediately when a module marked as “sufficient” succeeds in authenticating. Additionally, the process is terminated unsuccessfully immediately when a module marked as “requisite” fails to authenticate. Modules marked as “optional” do not have an additional effect on the overall authentication process. Consider the following scenario: three website are available via SSO: an information site, a shop site and a banking site. All websites use the same two authentication modules, M1 (using a username/ password mechanism) and M2 (using a biometric authentication mechanism) within a chain. 

M1 is marked as “required” for all three sites, while M2 is marked as “required” only for the banking site, and as “optional” for the other site. A user may therefore log into the information site via M1. An authentication token is generated when the authentication succeeds, and the user may access the information. When accessing the shop site, the user does not have to re-authenticate because the authentication token is used for SSO. When accessing the banking site, the authentication token indicates that the user has authenticated via M1. However, because the biometric authentication via M2 is required for the banking site, the user has to re-authenticate. 

 

Supported Standards

 

The Sun Java System Access Manager supports the following standards: 

1. JAAS (Java Authentication and Authorisation Service) 

2. Liberty Alliance Phase 2 (Identity-based Web Services Framework) 

3. OCSP (Online Certificate Status Protocol) 

4. SAML 1.1 Specification 

5. SOAP (Simple Object Access Protocol) 1.1 

6. SPML (Service Provisioning Markup Language) 

7. SSL (Secure Sockets Layer) 

8. XML Digital Signature 

9. XML Encryption 

 

Summary

 

After an introduction to the open standardisation group Liberty Alliance, this section has shown components, architecture and functionality of the Sun Java Access Manager as type 1 IMS, comprising authentication, authorisation and accounting. A trial with 80 million users were used to test the presented configuration of the Sun Java Access Manager. 

 

 

13 / 31