OAM Session
Session is an object which represent an authenticated user. It contains authenticated user details. No it does not contain user credentials but it keeps track of the important things like when was the last resource accessed, from which IP it was accessed and to which authentication scheme level the user is authenticated etc. Session is stored on server memory. If Database session persistence is enabled then the sessions object is maintained in database.
Why session is so important?
A valid session means a user is authenticated. If the session is not found in memory then user will be challenged by OAM. A session can attain 3 states:
- active
- inactive
- expired
When a session is created it is in active state. If no activity is detected, after idle timeout the session is marked as inactive. The sisson existed in the server memory till session lifetime is reached. After that the session is marked as expired. Once marked as expired the session is removed from server memory.
Many customers complain that the 'Maximum Number of Sessions per User' is not honoured by OAM. The max session limit by default is 8 and sometimes, when you search for user session in Session Management. They will see more than 8 sessions for a user. Why?
The max session limit is applicable only for active user session. So the additional user sessions visible in session management are inactive sessions.
Specifying Maximum Number of Sessions per User as '1' is a special case where only one session per user will be active at any given movement of time. If a user already having an active session and then authenticates again thus creating a new session, then the existing session will be deleted.
Is there a way to control it or know which sessions are inactive?
Let me ask you a question: Do you always logout of your account or directly close the browser or lock your system and leave for the day without logging out?
In my case I am the sole user of the system so I hardly logs out and most of the end users do the same thing. The SSO product should be smart enough to handle this type of situation.
In such scenarios, the end user is away and there is no way for OAM to know if the user is going to return back or not. If the user returns back, the inactive session became active session after re-authentication else OAM waits till Session Lifetime and then clear the in-memory session.
How oam knows which session belong to which user?
When a user is authenticated OAM creates OAM_ID cookie which is a domain level cookie. OAM_ID is httponly cookie so can't be accessed through client side scripts. It contains session ID which maps to the in-memory session. It is only set for Embedded Credential Collector(ECC)
When a user attempts to access a protected application, the OAM checks for the existence of OAM_ID cookie.
OAMAuthnCookie
Host Specific cookie set by each 11g Webgate that is contacted. So you can have multiple OAMAuthnCookie corresponding to each webgate. This cookie is protected by the key known to the respective 11g Webgate and the OAM Server.
ObSSOCookie
It is a domain level cookie specific for 10g webgates. Similar to 11g webgate, it is set only when a 10g Webgate is contacted. It is also protected with keys known to the OAM Server and Only one global shared secret key is used for all 10g Webgates.
OAMRequestContext
OAMRequestContext cookie is a transient cookie set by 11g webgate and stores request context i.e the original request details. during the time of authentication.
OAM_REQ
This cookie is used in high availability setup to store the authentication request context. It stores the original request url to the protected resource.
DCCCtxCookie
DCCCtx Cookie is similar to OAM_REQ cookie but this cookie is only set for Detached Credential Collector(DCC)
Thank you for reading.
No comments:
Post a Comment