The single sign-on across applications on the Sun Java System Web Server is supported by the Sun Java System 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 one time, and 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 6.1 SP8 Administrator’s Guide or the Sun Java System Web Server 6.1 SP8 Administrator’s Configuration File Reference.
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 as user accesses a protected resource in any web application associated with a virtual server, the user is 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 user to authenticate him or herself again.
The single sign-on feature utilizes 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 VS element of the server.xml file:
sso-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 value is set to false.
sso-max-inactive-seconds: Specifies the time after which a user's single sign-on record becomes eligible for purging if no client activity is received. Since 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.
sso-reap-interval-seconds: Specifies the interval between purges of expired single sign-on records. The default value is 60.
Here is an example configuration with all default values:
<VS id="server1" ... > ... <property name="sso-enabled" value="true"> <property name="sso-max-inactive-seconds" value="300"> <property name="sso-reap-interval-seconds" value="60"> </VS> |