Authentication, Single Sign ON, Session & Cookies

What is Authentication
What is SSO
Different types of Authentication
User/Password
Certificate
FIDO (Fast Identity Online)
Biometrics
AuthN / SSO flow
SSOTokenID
HTTP Cookie
Session Cookies
Cross Domain Single Sign On (CDSSO)
Grouping / Realm
Session Termination
CTS Session termination
Session Upgrade:
Session Quotas /Constraints ]
Java Agents/ WebAgents/ WebGates (OAM)

What is Authentication

Authentication is the process of validating the credentials of a user to allow access to a service/resource. The authentication process varies based on the pre-configured setups. The common authentication is the user/pass. Other forms of authNs are the CERT based authN, PKI, FIDO and biometrics.

The different authN methods provide increased levels of protection to the resources. The basic username/pass is for low level assurance. The medium level assurance is provided by the CERT based authN or even biometrics.

The response to authentication is a success or a failure. For a failure response the user is denied access. Whereas, a successful response, the user is allowed access to the resource. The complete access is determined not just by the authN success, but also by the access privilege like a coarse or fine grained roles the user has to the resource.

[ This article is focused on OpenAM authentication, cookies, session management concepts. However, the concepts can be applied to other access manager products like Oracle Access Manager.]

What is SSO

Authentication is the process of validating the credentials of a user to allow access to a service. Single sign on (SSO) is when a user is prompted to authenticate once and allowed access to the resource without re-authenticating. SSO happens until the session is active and not expired.

Different types of Authentication

The following are different types of authentication method used by different access manager products.

User/Password

The user is challenged by the access manager to enter his username and password, he knows, to get access to the resource.

Certificate

The other method of authN is Cert based.A certificate is generated as a proof of identity and given to the user or device. When the user accesses the resource, he is prompted for the proof of the certificate as the credentials.

PKI certificate & X509 certs are examples of certificate based authN.

FIDO (Fast Identity Online)

The user registers a device with the resource owner services and is prompted to provide a proof of holding that device before access is allowed to the resources. This could be a combination of user/pass + keys (Yubikey etc) or just provide the proof of key. When prompted, the user has to touch the key to provide the user’s identity.

Biometrics

The user is prompted to scan his face or eye/retina or use his fingerprint to get access to the system. The scan is compared against the scan prints stored in the system.

Authentication can also take place in a programmatic way using the REST apis. As well available are the SDKs which have the classes and methods that can be used to authenticate and manage user sessions.

AuthN / SSO flow

Let’s look at a common Authentication (AuthN) flow :

• The user tries to access a resource protected by an access manager (AM) and is intercepted by the agent.
• AM looks for a valid user session.
• If there is no valid session, the user is redirected to an authentication page.
• The user enters his/her credentials or presents his certificate as the proof of identity.
• If the authN is successful, a cookie with a session value is set in the browser.
• After successful authN, a session value is generated and set with a sessionIdentifier.
• Until the expiry of a session, the user can access different resources / services protected by the access manager within the scope of the user organization and the user is not prompted to re authenticate.
• The user can end the session either through logout or upon session expiry (idle time).

• The user doesn’t enter the right credentials, the authN is a failure. Access to resources is denied.

There are a few parameters set when a user is successfully authenticated. Lets understand how an HTTP cookie is set when authentication is successful and what role does the cookie play. The cookie stores the session value of the user in the browser. As long as the cookie holds a valid session, the user is allowed access to the protected service.

SSOTokenID

Sessions are identified by a Session Token ID — SSOTokenId. The policy agents get access to the session token using the SSOTokenID sent through a cookie.

The SSOTokenID has two pieces of information. The first secure random number identifies the authoritative server that generated the token. The second part of the session key identifies the correct site used to reach the server which generated it. The session key has the Site identifier and the server ID for the authoritative server.

HTTP Cookie:

The different custom values that can be set in a cookie are :

1. One of the elements of the Cookie is the custom name=values pair which stores the sessionidentitifer=<session value>.
2. HTTPOnly — This feature protects against CROS — cross site scripting vulnerabilities that can be exploited through Javascript or other scripting languages. When the HTTPonly flag is enabled, the header will be set to HTTPOnly flag in the token. If an invalid token is detected, then the token is ignored and auhtN continues.
3. On Logout the set-cookie clears the session cookie in the browser.
4. Secure — Secure keyword allows cookie access only over SSL, Non SSL access is denied.
5. Domain — This value indicates how the cookies impact the domain, usually it affects the complete domain abc.xyz.com. If you want to configure multiple subdomains, those subdomains have to be configured individually.
6. Path — The path indicates the directory to which the cookie has an impact. The /sso folder or its sub folders.
7. Expires — This holds the UTC formatted lifetime of a cookie.
8. Set the httpOnly cookie in AM by logging into the console and Set the value of the com.sun.identity.cookie.httponly property to true.

Session Cookies

Cookie issued either for client or CTS (Core Token Services) sessions.

Cookie default name IPlanetDirectoryPro for access manager or ObSSOcookie for OAM (10g webgates)/OAMAuthnCookie (11g) . This cookie name can be changed from the AM console to suit your deployment.

The CTS store session has a reference to the browser cookie, whereas the browsers/client cookie/session has all the information in the IPlanetDirectorypro cookie.

Client based cookies have two parts — the first part is similar to the value of the CTS store cookie, whereas the second part stores session information in JWT (Json Web Token) tokens.

The users/admins are responsible to configure the size of the cookie that is stored in the browser.

Cross Domain Single Sign On (CDSSO)

Open AM is capable of providing authN and authZ to services residing in different domains like the .example.com and .xyzexample.ca. This is a features supported by the policy enforcement Web agents & Java agents.

For cross domain SSO , the preferred method is to use federation capabilities like SAMLv.20 or OAuth 2.0. Both client and CTS store support CDSSO as well.

Grouping / Realm

Realm is a way to group the business specific authN modules, authorization policies and identities. Users logged into a realm will not be required to re-authenticate until they access resources within that realm. If the users leave the realm, he is logged out of the realm. Based on the authN scheme of the new realm, he has to re authenticate and get a new session.

Session Termination

CTS Session termination

The session termination takes place in the below scenarios.

1. User logs out.
2. Session idle time-out
3. Admin terminates session
4. Session exceeds the time-to live.

On any of the above scenarios, the session is removed from the CTS store and all contents of the cache cleared. Once the cache is cleared, the user has to re authenticate to access a resource.

When a user logs out, AM sets the cookie with an invalid session ID and expiration date to the past, whereas an admin invalidating the cookie from the access manager console, the invalid state of the cookie is reflected the next time the user logs in.

Client based cookies cannot be terminated by the admin, because after authentication ,AM doesn’t modify cookie idle timeout of the cookie or doesn’t have control over the client cookie.

In the CTS mgmt, the invalidation of cookie clears the session from the store, the user on next login is forced to re-authenticate.

Using the Session blacklisting feature the AM maintains client based session values, and checks to see if the session is valid or invalid for any further session generation.

Session Upgrade:

There are scenarios where user identity doesn’t need to be validated before accessing certain features in a portal such as browsing a course or searching a catalog for access. However, to access specific resources , the user is prompted to authenticate before access is granted.

For example, If a user needs privileged access to pay a bill or access important financial data, the session needs to be upgraded. This upgrade is possible through a ForceAuth feature, the user is forced to authenticate with a multi-factor or second factor authN — in this a code to the user’s phone or email for the user to enter during authentication. This is called step up authentication.

Configuring ForceAuth parameter =true will force the user to -. ForceAuth Session upgrade is supported only in CTS sessions.

Session Quotas /Constraints -

Session Quotas limit the number of active sessions an user can have in the system at one point in time. This limits the number of open browsers or devices a user can simultaneously work with. If the max configured session is reached, then an appropriate message can be displayed to warn the user.

When the session quota is reached, the following actions could be taken to clear the session

• Deny user login
• Delete Oldest session
• Destroy an expired session or all previous sessions.

Java Agents/ WebAgents/ WebGates (OAM)

Java Agents and Web Agent are plugins deployed with the resources integrated with OpenAM. Those agents integrated with AM provide AuthN, SSO and AuthZ services. A simple flow is shown.

Oracle Access Manager uses different types of Webgates based on the OS to provide AuthN, AuthZ and SSO. These agents communicate through specific pre configured ports with the access server to verify the authentication and authorization policies.

This article discussed a few core access manager concepts on the high level: Single Sign on (SSO), Cross domain SSO (CDSSO). What is a Session, Session upgrade, and Session Quotas. The session store, the Core token services CTS store. What happens when user authentication is successful with HTTP cookies and security around it.

The SSO flow diagram captured how to achieve basic SSO. Also covered are Client based cookies and the CTS store role in managing the session lifecycle.