Single Sign-on for J2EE Web Applications 

The J2EE Engine’s Web Container provides options for cross application login to Web application users. That is, if a user has successfully authenticated to a Web application, he or she can access other Web applications without re-authentication.

The Web Container’s single sign-on implementation leverages the strengths of the JAAS authentication model and the JSESSIONID mechanism. Namely, the Web application deployer defines a security policy domain and deploys the application within its boundaries. It is possible that several applications share such a domain. This means that single sign-on can be used across those applications. If the user crosses the security policy domain boundary (for example, by requesting a Web application that is deployed in a different domain), he or she is forced to re-authenticate.

In the context of Web applications and single sign-on on the J2EE Engine, a security policy domain must be considered different from a security technology domain and a realm name domain. This enables applications that use different security technologies to share a single security policy domain, and therefore to enable single sign-on for their users.

Hierarchical Security Policy Domains

An important feature of the security policy domains is that they can be hierarchical. That is, a larger domain can contain one or more sub-domains. The purpose of the hierarchical security policy domains is to enable unidirectional login between two Web applications. For example, if an application is deployed within the larger domain named A, and another that is deployed in domain B that is a sub-domain of A, then users that have logged in to the application in domain B can access the first application without re-authentication; however, the reverse situation would require the user to re-authenticate to the application within domain B.

Using this feature of the security policy domains on the J2EE Engine, you can easily configure your welcome Web application to accept users from all other Web applications deployed on the Web Container on the same server process. You do this by deploying it in a “root” security policy domain, and then deploying each other Web application in a sub-domain of the root one.

By default, each Web application is deployed within different security policy domain. That is, by default no single sign-on is available on the J2EE Engine.

Single sign-on using the JSESSIONID mechanism is possible only between applications that are running on the same server process in the cluster. The reason for this is that the security sessions created to identify the user’s security identity are not persistent, and therefore cannot be migrated to another server process.

Mechanisms Supporting the Single Sign-on

By default, the standard JSESSIONID mechanism is used to exchange the information about the user’s identity between the Web applications when performing single sign-on. It is based on the associations between the HTTP sessions of the user established for the different applications, and the security session that is established after the user logs in to an application. This information is sent with the HTTP request using a session cookie (or URL rewriting, if cookies are disabled).

When accessing the J2EE Engine and having more than one browser window open, users will not be able to change the logged on user id. To change the logged on user id, users have to log out and close all open browser windows before logging on again.

In addition, to securely log out of a browser session, we recommend to ensure that browser processes that run in the Operating System (OS) background are terminated upon closing all browser windows. For more information, see the documentation for your OS and Web browser.

The other mechanism that can support the single sign-on functions is based on the SAP Logon Tickets. Upon successful login to a Web application, the J2EE Engine issues the user with such a ticket. Consequently, the logon ticket is sent with the request coming from the user and can be used to log him or her on to other applications. For more information about SAP logon tickets, see Using Logon Tickets for Single Sign-On in the Administration Manual.

The advantage of the logon tickets is that you can use them to provide cluster-wide single sign-on (which includes single sign-on between the Java and the ABAP stack within the Web AS cluster).

Configuring Your Web Application for Single Sign-on

You configure your Web application for single sign-on using its web-j2ee-engine.xml deployment descriptor. All you have to do is to specify the security policy domain, within which you want to deploy the application. For a detailed description of the procedure of setting the security policy domain, see Configuring Authentication.

The string that you specify in the security policy domain field in the application’s web-j2ee-engine.xml in the SAP NetWeaver Developer Studio can be perceived as definition of a security policy domain (that is, you do not need to configure anything in advance in the Security Provider Service on the J2EE Engine). By defining appropriate domains for all your Web applications, you actually build a hierarchy of such domains that determines when single sign-on is possible and when re-authentication is necessary.