Show TOC

HTTP Sessions and Security Sessions on the AS JavaLocate this document in the navigation structure


Sessions are used to track information exchanged between the client and the server, and also preserve that information for as long as necessary. A session is established at a certain point of time, and it is destroyed at a later time. The exact moments of session creation and session deletion depend on the settings for a given session type.

Stateful Web Applications

Stateful web applications can store information between multiple requests. This allows the application logic on the server side to distinguish between interacting clients while preserving information tokens for each client. To achieve this, stateful applications require the creation of HTTP sessions.

HTTP Sessions

By design the HTTP protocol is stateless, meaning that it does not retain information about the communicating parties and it cannot create its own sessions.

However, when there is a need to store information between multiple requests, a session mechanism can be utilized.

Creation of HTTP sessions: HTTP sessions are created by the stateful applications with which the user works. A user can have more than one HTTP session to the AS Java for using different applications at the same time. One way of creating HTTP sessions is by using the APIs, defined in the Java Servlet Specification. For more information about creating and tracking HTTP sessions, see: HTTP Sessions and AS Java Cookies .

Termination of HTTP sessions: The termination of an HTTP session could be determined explicitly by the application logic or by an automatic expiration mechanism.

Security Sessions

The authentication information of a Web application user is stored in a session object on the AS Java's Web Container. This session is referred to as a security session.

Creation of security sessions: A security session is created after the user logs in successfully to the AS Java.

Termination of security sessions: 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.

Relations Between the Different Types of Sessions

After the user logs in, the AS Java creates a security session for this user. The AS Java also creates HTTP sessions, depending on the requirements of the applications that the user accesses. These HTTP sessions are mapped to the security session that already exists for the user. One security session can have many HTTP sessions mapped to it. An HTTP session can only be mapped to one security session.


  1. The user enters the URL of an application in the address bar of the browser.

  2. The AS Java requests the user to authenticate.

  3. The user authenticates successfully and the AS Java creates a security session for him or her.

  4. The AS Java creates an HTTP session that will be used to track the interaction between the user and the application.

  5. The AS Java maps the HTTP session to the security session.

    Subsequently created HTTP sessions are also mapped to the security session that already exists for this user.

  6. Session termination

    • The user logs out.

      When the user logs out, the AS Java destroys the user's security session and that also invalidates the HTTP sessions.


      For applications protected by SAML 2.0, an explicit logout by the user or administrator can trigger a logout on all systems, which participate in the SAML 2.0 Single Log-Out.

    • Sessions expire.

    • The AS Java or an administrator terminates one or more sessions because of a problem.