Sessions security
HTTP sessions and security can be integrated in WAS. 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, otherwise you may incur an UnauthorizedSessionRequest exception when the unsecured resource attempts to access an authenticated session (see chart below). Security integration in Session Manager is supported only through the Lightweight Third-Party Authentication (LTPA) authentication mechanism. If you are using Simple WebSphere Authentication Mechanism (SWAM) as your authentication mechanism, you cannot integrate security with the Session Manager.
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
WAS 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. WAS includes the com.ibm.webSphere.servlet.session.UnauthorizedSessionRequestException interface, which is used when a session is requested without the necessary credentials. For more information on these interfaces, see Package com.ibm.websphere.servlet.session. 
The Session Manager uses the WAS security infrastructure to determine the authenticated identity associated with a client HTTP request that either retrieves or creates a session. WAS security determines identity using certificates, LTPA, 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. The security integration outcomes depend on whether the HTTP request was authenticated and whether a valid session ID and user name was passed to the Session Manager.
| Scenario | 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 and the user name is marked as 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. |