Open Identity Stack - Common Audit Framework

I'm looking forward to the Common Audit Framework in the next release of Open Identity Stack (OpenAM, OpenIDM, OpenDJ and OpenIG). 

At present, each component is logging in its own format and to different targets (e.g. file-system, database, syslog). Thus making debugging across components tedious.

This is definitely a good move!

.

ForgeRock OpenIG - API Gateway

API Gateway is getting hot these days. In fact, within a span of 2 months, I have 3 potential customers asking for API Gateway solutions.

There are already a few API Gateway solutions out there in the market - namely CA API Management (aka Layer 7), Oracle API Gateway and Mulesoft API Manager.


Well, ForgeRock is now enhancing OpenIG to be a API Gateway!

* Slide extracted from the recent 2015 Identity Summit in US.

You can view the slides from The Platform Big Picture.


.

Shared Consent Atrribute Name

This blog was meant to be published last month but I was held up with moving to new office. (Yes, we are now in Fusionopolis Place, situated right next to INSEAD and the MRT/Metro is right below our building.)

Of course, in between, I had a short family vacation in Phuket, Thailand where I ran the 10th Laguna Phuket International Marathon.

 

Back to today's topic ...  Lets's assume a scenario as follows:

1. OpenAM acts as a OAuth 2.0 Provider
2. An application is protected with OAuth 2.0 (aka it is OAuth 2.0 Client enabled)

When an user access the application for the 1st time, the OAuth 2.0 client will redirect to the OAuth 2.0 provider. In this example, the OAuth 2.0 provider is OpenAM. Thus the OpenAM Login Page will be displayed.

After successful authentication, OpenAM will present the user with an authorization decision page.

When the checkbox is ticked and Allow button is clicked, the user entry in LDAP will be updated, specifically an attribute that was defined during configuration in OpenAM console "Shared Consent Attribute Name". In this example, the attribute name is defined as oauth2consent.

When the user entry is updated, the aooauth2consent attribute will be populated with the following data format:

 [oauth 2.0 client name] [attribute1] [attribute2] [attribute3] ...

Now, in some scenarios, for example Intranet applications, customers would not like the authorization decision page to be shown. How can we workaround this since OpenAM does not have the capability to hide this page at the moment?

The simple solution is to provision directly to the LDAP, specially the oauth2consent attribute with the data format shown above. 

PS: Do remember to add oauth2consent into LDAP User Attributes in Data Store. Otherwise, OpenAM is not able to update the user attribute in the LDAP.