Agentless Cross Domain Single Sign-on with Session Upgrade

The following wiki link details a ForgeRock configuration that demonstrates how to achieve cross-domain single sign-on with session upgrade, using OpenID Connect.

Business Case: One of the primary tenants of achieving customer facing omni-channel business presence, is to balance security with reduction of friction. As part of that overall goal, this paper describes a particular set of configuration options that enable the tracking of a user’s actions throughout session in order to enforce security and provide context aware services. This is achieved in an adaptive fashion that reduces friction by not forcing a user to authenticate until absolutely needed. This model does however enable capabilities that provide incentive for suggestive authentication, in order to have richer experience.

Technical Constraint: This particular solution is rather trivial when leveraging the included OpenAM abstraction components either (OpenIG or Policy agents). However due to a recent customer request, this paper describes a deployment approach in a fashion that maximized the developer involvement rather than abstract away from developers the complexity. From a business perspective, this may be the less attractive of a deployment approach, however after describing the more complex case, makes the ideal option easier to understand. So, this solution architecture will have a technical constraint that it must not rely upon proxy or agent-based components; rather, the clients directly engage over modern open standards such as OpenID Connect.
Use-Case: Cross-Cookie-Domain Single Sign-on with support of notion of some resources may require authenticated user, while other resources may consider anonymous as an acceptable status from the centralized access management system. Once authenticated however, other resources should be notified that user has upgraded from anonymous to authenticated user.



For more info see:

ForgeRock OpenAM Federation Using SAMLv2

This blog post was first published @, included here with permission.

If you experience Deja Vu by looking at the illustration just below, chances are that you’ve hit my blogs before, in particular on this entry, where we looked at ForgeRock OpenAM as an Identity Provider and ForgeRock OpenIG as a Service Provider.

A friend asked me if I could demonstrate a very simple configuration of Federation using two ForgeRock OpenAM instances, one acting as an Identity Provider (a.k.a IDP) and another one taking up the role of a Service Provider (a.k.a SP). It wasn’t difficult to do one, so here we have it embedded towards the end of this post.


So what do we have here:

– A Circle of Trust which has two OpenAM instances, one of which acting as an Identity Provider and another one as Service Provider
– User always authenticates against the Identity Provider
– The authentication process is intiated either by the IDP (known as IDP initiated SSO) or by the SP (SP initiated SSO)
– Once the user is authenticated successfully, IDP sends across a piece of security information to the SP (known as assertion) that could contain user attributes
– SP then gives the user access to protected resources

In the demonstration that follows, because ‘Auto Federation’ is not enabled, during the first login the user will be prompted for credentials both by the IDP and the SP. Once the account linking is done, it’s only the IDP who would challenge the user.

If the illustration and the briefing above hasn’t given you the complete picture, the video below might give a better one.