Show TOC Start of Content Area

Background documentation Security Sessions  Locate the document in its SAP Library structure

The authentication information of a Web application user is stored in a session object on the J2EE Engine’s Web Container. This session is referred to as a security session and differs from the HTTP sessions. In fact, there is a complementary association between a security session and an HTTP session – that is, the security session provides the security-related information of the user that is identified by the HTTP session. A security session can have associations with more than one HTTP sessions (in case of single sign-on for Web applications), whereas the HTTP-session-to-security-session associations are always of type one-to-one.

Life cycle of Security Sessions

The security session’s life cycle is related to the life cycle of the HTTP sessions associated with it. That is, a security session lasts until all HTTP sessions associated with it expire, or are invalidated. On the other hand, if a security session expires or is invalidated upon user logout, then all associated HTTP sessions are invalidated too.

It is possible that several security sessions are created for the same user as he or she traverses the boundaries of a particular security policy domain. This is explained with the fact that J2EE Engines uses hierarchical security policy domains and requesting an application that resides within a sub-domain or a different domain requires re-authentication (hence the creation of a new security session).

Global Logout

If a user logs out of an application, this logout has a global effect. That is, all security sessions currently associated with the JSESSIONID of the user that logs out are destroyed. If operating in a cluster environment, the security sessions associated with the user’s JSESSIONID are destroyed on all cluster elements.

You can disable the global logout behavior using the <global-logout-disabled/> tag in the web-j2ee-engine.xml descriptor on the J2EE Engine. If an application has this property set in the deployment descriptor and the user performs a logout in this application, only the security session of the current application is destroyed; all other security sessions (in different security policy domains) associated with the corresponding HTTP session remain active.

Example

The global logout is disabled only for an application that has the <global-logout-disabled/> tag set in the deployment descriptor. Assume application A has disabled the global logout behavior, and application B has not. If a user who is logged on to both applications logs out from application A, then only the security session for the application A is destroyed, while the one for application B (if exists) remains. The opposite way – if the user calls logout from application B, then the global logout behavior takes place and all security sessions for this user (identified by the corresponding JSESSIONID) are destroyed on all server processes in the cluster.

Caution

Disabling the use of the global logout behavior is deprecated. It is considered not secure behavior.

Security Sessions and Failover

Security sessions on the J2EE Engine are not serialized. This implies that in case of server process crash, the failover function will not be able to migrate the security session to another cluster element together with the HTTP session and the user will be forced to authenticate himself or herself again.

 

End of Content Area