InfoCenter Home >
4: Developing applications >
4.4: Personalizing applications >
4.4.1: Tracking sessions >
4.4.1.1: Session programming model and environment >
4.4.1.1.3: Securing sessions

4.4.1.1.3: Securing sessions

HTTP sessions and security can be integrated in IBM WebSphere Application Server. When security integration is enabled in Session Manager and a session is accessed in a protected resource, every resource from then on must be secured. You cannot mix secured and unsecured resources. Security integration in Session Manager is not supported in form-based log-in unless LPTA is used.

Security integration rules for HTTP sessions

  • Sessions in unsecured pages are treated as accesses by "anonymous" users.
  • Sessions created in unsecured pages are created under the identity of that "anonymous" user.
  • Sessions in secured pages are treated as accesses by the authenticated user.
  • Sessions created in secured pages are created under the identity of the authenticated user. They can only be accessed in other secured pages by the same user. To protect these sessions from use by unauthorized users, they cannot be accessed from an insecure page.

Programmatic details and scenarios

IBM WebSphere Application Server maintains the security of individual sessions.

An identity or user name, readable by the com.ibm.websphere.servlet.session.IBMSession interface, is associated with a session. An unauthenticated identity is denoted by the user name "anonymous." IBM WebSphere Application Server includes the com.ibm.websphere.servlet.session.UnauthorizedSessionRequestException interface, which is used when a session is requested without the necessary credentials.

The Session Manager uses the WebSphere security infrastructure to determine the authenticated identity associated with a client HTTP request that either retrieves or creates a session. WebSphere security determines identity using certificates, LPTA, and other methods.

After obtaining the identity of the current request, the Session Manager determines whether the session requested using a getSession() call should be returned.

The table lists possible scenarios in which security integration is enabled whose outcomes depend on whether the HTTP request was authenticated and whether a valid session ID and user name was passed to the Session Manager.

  Unauthenticated HTTP request is used to retrieve a session HTTP request is authenticated, with an identity of "FRED" used to retrieve a session
No session ID was passed in for this request, or the ID is for a session that is no longer valid A new session is created. The user name is "anonymous" A new session is created. The user name is "FRED"
A session ID for a valid session is passed in. The current session user name is "anonymous" The session is returned. The session is returned. The Session Manager changes the user name to "FRED"
A session ID for a valid session is passed in. The current session user name is "FRED" The session is not returned. UnauthorizedSessionRequest Exception is thrown* The session is returned.
A session ID for a valid session is passed in. The current session user name is "BOB" The session is not returned. UnauthorizedSessionRequestException is thrown* The session is not returned. UnauthorizedSessionRequestException is thrown*

* com.ibm.websphere.servlet.session.UnauthorizedSessionRequestException is thrown to the servlet.

Go to previous article: Controlling write operations to persistent store Go to next article: Deciding between single-row and multirow schema for sessions

 

 
Go to previous article: Controlling write operations to persistent store Go to next article: Deciding between single-row and multirow schema for sessions