OAM Sessions and Cookies
OAM Sessions and Cookies
(Taken from oam-idm blog)
OAM Session
Session is an object which represent an authenticated user. It contains authenticated user details. 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 sesison 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.
What is OAM
Everyone knows that OAM is an access management tool which provides centralised control over Authentication and Authorization. Yes, that is the main purpose of OAM but its stability and flexibility to incorporate most of the security standards with easy debugging and auditing makes it stand out of the rest of available products in the market. I do agree Oracle documentation is not that great and if you don't know what you are looking for then it will give you a hard time.
Everything that I am going to discuss in this blog series is documented in oracle documentation and I have learned it through hit and try method. I would suggest you to go through the oracle documentation first as it is the official reference. The technology will change and my blog will be outdated (I will try my best to keep it updated but it's a side project). For new folks I would suggest you to start with the OAM student guide and then Admin Guide and once you are comfortable with oam take a deep dive with Dev guide. Most of the difficulty configuring OAM happens when you are following wrong documentations. So make sure you use the correct documentation for the particular version of OAM because minor steps and configuration change will make or break things.
How it works
In layman OAM works similar to a receptionist in an Office. When a new user arrives OAM asks Who are you and whom you want to meet. Based on the predefined rules and logic it decides if the user is allowed to access the resource or not.
In our digital world there are lot of notorious guys who want to sneak in silently for that reason OAM has an army of webgates (which are similar to a security guard in office). So, it doesn't matter which resource you want to access a webgate will intercept you make a call to OAM to check if the resource is public or protected and based on the OAM response it takes further actions.
P.S. I explained the same thing to my brother and he started comparing it to Matrix. No, we are still not that technologically advance and no webgate is not like agent smith.
How does OAM setup looks like?
Let's say Agent Smith tries to access App1, his requested is routed through a webserver(OHS) proxying the resource. The webgate1 which is deployed in OHS1 will intercept the request and check with OAM if Agent smith is allowed to access the request. As this is the first time for Agent smith oam will ask for credentials and once authenticated, it verifies the authorization policies. If all the checks are success then OAM will redirect the request to webgate with the permission to access the resource.
Now, Agent smith tries to access App2. Wegate2 will make a call to OAM and OAM will check if Agent smith is already authenticated or not. As the Agent smith is already authenticated The OAM will evaluate authorization policies and then only the access will be allowed.
Communication between webgate and OAM happens over Oracle Access Protocol (OAP) and the redirection of happens over http/s
OAM Session and OAM Cookies
OAM Session
Session is an object which represent an authenticated user. It contains authenticated user details. 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 sesison 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.
OAM: Basics
What is OAM
Everyone knows that OAM is an access management tool which provides centralised control over Authentication and Authorization. Yes, that is the main purpose of OAM but its stability and flexibility to incorporate most of the security standards with easy debugging and auditing makes it stand out of the rest of available products in the market. I do agree Oracle documentation is not that great and if you don't know what you are looking for then it will give you a hard time.
Everything that I am going to discuss in this blog series is documented in oracle documentation and I have learned it through hit and try method. I would suggest you to go through the oracle documentation first as it is the official reference. The technology will change and my blog will be outdated (I will try my best to keep it updated but it's a side project). For new folks I would suggest you to start with the OAM student guide and then Admin Guide and once you are comfortable with oam take a deep dive with Dev guide. Most of the difficulty configuring OAM happens when you are following wrong documentations. So make sure you use the correct documentation for the particular version of OAM because minor steps and configuration change will make or break things.
How it works
In layman OAM works similar to a receptionist in an Office. When a new user arrives OAM asks Who are you and whom you want to meet. Based on the predefined rules and logic it decides if the user is allowed to access the resource or not.
In our digital world there are lot of notorious guys who want to sneak in silently for that reason OAM has an army of webgates (which are similar to a security guard in office). So, it doesn't matter which resource you want to access a webgate will intercept you make a call to OAM to check if the resource is public or protected and based on the OAM response it takes further actions.
P.S. I explained the same thing to my brother and he started comparing it to Matrix. No, we are still not that technologically advance and no webgate is not like agent smith.
How does OAM setup looks like?
Let's say Agent Smith tries to access App1, his requested is routed through a webserver(OHS) proxying the resource. The webgate1 which is deployed in OHS1 will intercept the request and check with OAM if Agent smith is allowed to access the request. As this is the first time for Agent smith oam will ask for credentials and once authenticated, it verifies the authorization policies. If all the checks are success then OAM will redirect the request to webgate with the permission to access the resource.
Now, Agent smith tries to access App2. Wegate2 will make a call to OAM and OAM will check if Agent smith is already authenticated or not. As the Agent smith is already authenticated The OAM will evaluate authorization policies and then only the access will be allowed.
Communication between webgate and OAM happens over Oracle Access Protocol (OAP) and the redirection of happens over http/s
Comments
Post a Comment