Addendum to ForgeRock Full Stack Configuration – Using ForgeRock OpenIG

This is an extension of an earlier post that demonstrated ForgeRock Full Stack Configuration, comprising OpenDJ, OpenAM and OpenIDM. In here we’ll plug in ForgeRock OpenIG to route traffic to/from OpenAM and OpenIDM. In the video log that follows, you’ll see:

– All urls that hit OpenIG, containing a string ‘openam’ getting redirected to OpenAM URL
– All urls that hit OpenIG, that does not contain the string ‘openam’ getting redirected to:

  1. OpenAM for Authentication if there is no valid User session and then on to OpenIDM UI
    2. OpenIDM UI if there is a valid User sessionOpenIDM UI

So here’s the extended illustration

AddendumToFullStackConfiguration

Now on to the video.Enjoy!

ForgeRock OpenAM – Configuring Different Realms to Use Different BaseDNs of an OpenDJ Instance as Identity Repository

The short video log that follows was prepared to answer a question raised in the Forum on the ForgeRock Community Website. It’s an easy one on how to configure two separate BaseDNs of single ForgeRock OpenDJ instance as Identity Repository for two separate Realms in ForgeRock OpenAM.

Enjoy!

ForgeRock Full Stack Configuration

If you’re in a hurry to know what each of the ForgeRock Identity Platform Components is meant to do, try the Full Stack Configuration. In just over fifteen minutes, you’ll see:

– Installation of ForgeRock OpenDJ
– Deployment of ForgeRock OpenAM
– Configuration of OpenDJ as an Identity Repository in ForgeRock OpenAM
– Installation of ForgeRock OpenIDM
– Configuring OpenDJ as External Resource in OpenIDM
– Running a reconciliation in OpenIDM from OpenDJ
– Provisioning a User from OpenIDM to OpenDJ
– Using OpenAM as the Authentication Module for OpenIDM

With a much awaited weekend around the corner, I couldn’t really get over the laziness to create a better illustration than the one below to help visualize what’s mentioned above.

ForgeRockFullStack

Please watch it, if you have some time. Enjoy!

Thanks: ForgeRock Product Documentation

ForgeRock OpenIG 4 As OpenAM Policy Enforcement Point

We know of it as a job usually done by the OpenAM Web/J2EE Policy Agent to enforce a Policy Decision sent by the Access Management Solution. To help you recollect, this is how it works:

– An End User tries to access a resource (say, a URL)
– The Web/J2EE Policy Agent deployed in the Container, intercepts the requests and redirects the request to Access Management Solution
– The Access Management Solution, first Authenticates the User, does a redirection to the the Resource (URL), where Agent would again receive it
– The Agent would now ask the Access Management Solution whether the Authenticated User has access to the Protected Resource (Authorization)
– Based on the policies defined in the Access Management Solution for the Protected Resource, it constructs a Decision and sends it back to the Agent
– Whatever the decision Agent receives from the Access Management (whether to ALLOW or DENY access to the Protected Resource), the Agent Enforces it!

The story in the video below is a bit different. In fact, the protagonist is different. The honours of Enforcing a Policy Decision sent by OpenAM is on ForgeRock OpenIG 4. As for the flow, it by and large remains what is mentioned above, just that the OpenIG uses its Route Configuration file to decide whether it should redirect the Client requests to OpenAM (should the SSO Cookie is absent in the request), ask OpenAM for Policy Decisions on Protected URLs by Authenticated Users and finally to enforce a Decision that is sent by OpenAM (whether to ALLOW or DENY access to Protected URLs).

Very roughly, here’s an illustration of the flow:
ForgeRock OpenIG 4 As ForgeRock OpenAM 13 Policy Enforcement Point

To see it in action, watch the screen-cast below. Enjoy!


Related Documentation:
ForgeRock OpenIG Documentation

ForgeRock Authenticator (OATH) in ForgeRock OpenAM 13

If you’re in possession of a Smart Phone that runs either the Apple iOS or Android, you may probably be interested to know that the ForgeRock’s newer version of its Access Management solution now has an Authenticator App for you. Once installed and the device registered with ForgeRock OpenAM 13, one could use this Mobile App to generate One Time Password to validate his/her identity and thereby gain access to resources protected by the OpenAM. Needless to add, the ForgeRock Authenticator Mobile App is available on Apple iTunes Store for the iOS users and the Google Playstore for the Android fans.

Once installed, you’ll see on your phone something close to what is in the picture below:


ForgeRockMobileAuthenticator

Here’s what I did with my copy of ForgeRock Authenticator App on my iPhone:

– Configured an Authentication Chain ‘myAuthChain’ in my OpenAM 13 instance
– The said chain consisted of two Authentication Modules namely DataStore & ForgeRock Authenticator (OATH)
– When a subject authenticates against the ‘myAuthChain’ Authentication Chain in OpenAM, he/she is prompted for the DataStore credentials (an embedded OpenDJ instance), which on success is followed by another prompt where the user can register his/her device (using QR Code), generate an OTP that can be used to gain access to the resources protected by OpenAM.

2FAForgeRockAuthenticator

If you are interested to see all of this in action, please spare five minutes to watch the video below.

Enjoy!

Related documents/videos:
ForgeRock Documentation
Smart Security Using Phone App Demo

SAML2 as ForgeRock OpenAM 13 Authentication Module Instance

Well, you’ve possibly heard about the release of newer version of the ForgeRock Identity Platform with several enhanced capabilities. If not, you can read about it all here. One of the new features in the Access Management component of ForgeRock Identity Platform is SAML2 Authentication Module. What that offers is, after configuring Federation, we could supply all the required details like the IDP entity, the binding method etc. in an Authentication Module instance of the ForgeRock Access Management solution and use it just like any other Authentication Module (LDAP, Database, HOTP etc.). Let’s see how that’s done in a video demonstration that follows this write up. And, by the way, if you’d like to get a quick idea what’s new in the newer version of ForgeRock Access Management solution, read the release notes here.

We’ve already discussed OpenAM Federation on this space before. Here’s list of links from the past:

ForgeRock OpenAM Federation Using SAML v2
Using SAML Assertion Attributes in ForgeRock OpenAM

While the following video walks through the OpenAM Federation Configuration from the scratch, if you feel there are details missing in it, please feel free to have a look at the web logs mentioned above. The main focus of the screen-cast below is only to see how SAML2 is used as an Authentication Module instance in the version 13 of ForgeRock OpenAM.

The following illustration might give a quick idea on what’s demonstrated in the video embedded below this post.

OpenAMFederation
Now on to the screen-cast. Enjoy!

ForgeRock OpenAM Federation Using SAML v2

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.

OpenAMFederation

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.

Enjoy!