Single sign-on across applications on the Web Server is supported by the Web Server servlets and JSPs. This feature allows multiple applications that require the same user sign-on information to share this information between them, rather than having the user sign on separately for each application. These applications are created to authenticate the user once. When needed, this authentication information is propagated to all other involved applications.
An example application using the single sign-on scenario could be a consolidated airline booking service that searches all airlines and provides links to different airline web sites. Once the user signs on to the consolidated booking service, the user information can be used by each individual airline site without requiring another sign-on.
Single sign-on operates according to the following rules:
Single sign-on applies to web applications configured for the same realm and virtual server. The realm is defined by the realm-name element in the web.xml file. For information about virtual servers, see the Sun Java System Web Server 7.0 Update 5 Administrator’s Guide.
As long as users access only unprotected resources in any of the web applications on a virtual server, they are not challenged to authenticate themselves.
As soon users access a protected resource in any web application associated with a virtual server, they are challenged to authenticate using the login method defined for the web application currently being accessed.
Once authenticated, the roles associated with this user are used for access control decisions across all associated web applications, without challenging the user to authenticate to each application individually.
When the user logs out of one web application, for example, by invalidating or timing out the corresponding session if form-based login is used, the user's sessions in all web applications are invalidated. Any subsequent attempt to access a protected resource in any application requires the users authorization.
The single sign-on feature uses HTTP cookies to transmit a token that associates each request with the saved user identity, so it can only be used in client environments that support cookies.
To configure single sign-on, set the following properties in the single-sign-on element of the server.xml file:
enabled: If false, single sign-on is disabled for this virtual server, and users must authenticate separately to every application on the virtual server. The default is false.
idle-timeout: Specifies the time after which a users single sign-on record becomes eligible for purging if no client activity is received. Because single sign-on applies across several applications on the same virtual server, access to any of the applications keeps the single sign-on record active. The default value is 5 minutes (300 seconds). Higher values provide longer single sign-on persistence for the users at the expense of more memory use on the server.
To configure single sign-on through CLI, see the enable-single-signon(1) and disable-single-signon(1) man pages.
The following example shows a configuration with all default values:
<single-sign-on> <enabled>1</enabled> <idle-timeout>300</idle-timeout> </single-sign-on> |