OpenAM Session Upgrade: Overview

Posted 12 years ago by Gabor Puhalla

SSO authentication introduces some technical challenges besides providing obvious benefits. Imagine for example that you need to assign different types or levels of authentication to different resources or different actions within a domain. E.g. you allow users to view information, if they successfully authenticate using user name and password, while you may require them to insert a special security code besides user name and password, if they want to start editing. Or you allow users to access general content using user name and password, while accessing specific content (e.g. admin content) needs a security certificate.

Now, what if the user is logged-in  with one level or type of authentication, while she attempts to access a resource that requires a different level or type of authentication? Will she be asked to log-in again? What happens to the SSO session technically in such cases?

The technical solution

This is what OpenAM calls session upgrade. When the user is authenticated for the second time, the SSO session is upgraded on the server side (it’s properties are updated) and a new iPlanetDirectoryPro cookie is created on the client side that’s associated with the new session. The available documentation doesn’t describe the process in detail; this is what I’m getting reading technical docs, blogs and what I was able to confirm, while exploring the product. I hope, readers will find the collection of these pieces in one article helpful and comment if anything needs correction.

When is Session Upgrade triggered

So, when is a second authentication actually triggered? Does accessing a resource with a different type of authentication always result to re-authentication? Not necessarily. This is driven by the concept of policy conditions. Assume, for example, that we have 2 different resources that require 2 different levels of security and that the user already authenticated to access the first resource. Policy conditions can be configured in a way that re-authentication is triggered, when the user accesses the second resource with a higher authentication level assigned. The user would not be asked to re-authenticate, if the authentication level associated with the second resource is equal or lower.

BTW, be careful about the way you set your policies. You should configure your policies, so they get evaluated. Should you for example set your first Policy 1 to /res/* and the Policy 2 to /res/sessionupgrade/*, then Policy 1 would match the resource for Policy 2 and hence, Policy 2 would not get evaluated.

Available docs

Further technical and process details are available in OpenAM 10.x and OpenSSO 8.x documentation (most of it should hopefully be still valid for OpenAM 10.x). We plan publishing another article as a follow-up to this overview. It should describe the configuration, the step by step process and implications of session uprades. Stay tuned:)

Gabor Puhalla