OpenAM acting as OAuth2 Provider and OAuth2 Client

Recently, we have a customer who wants to extend their OpenAM infrastructure to mobile applications. That should not be a problem at all since OpenAM supports OAuth2 Provider since version 10.1.0-Express.

In addition, customer wants to allow mobile users to authenticate using Facebook and/or on-premise LDAP. Well, OpenAM does support OAuth2 authentication module which acts as an OAuth2 Client to Facebook (which acts as an OAuth2 authorization server). 

So, we spent some time exploring the possibility of having OpenAM acts as an OAuth2 Provider and OAuth2 Client.


1. Basically, all mobile applications are to authenticate via OpenAM OAuth2 Provider, instead of directly with Facebook.

2. OpenAM Login Page allows Facebook OAuth2 authentication or LDAP authentication (as per requirement). Of course, the Login Page might need to customize to render nicely on mobile phones.

3. User clicks Facebook OAuth2 authentication on OpenAM Login Page (notice this trigger a link from OpenAM server to Facebook; not mobile applications with Facebook directly). What actually happens is a redirection from OpenAM Login Page to Facebook application on the same mobile device. 

4. Upon successful authentication (which should be seamless on mobile phones since users seldom log out from Facebook app), Facebook OAuth2 token is returned to OpenAM server. This establish a valid session in OpenAM. 

5. OpenAM now returns its own OAuth2 token back to the mobile application. (instead of a OAuth2 token from Facebook)


One might ask what's the rationale for doing so? Isn't it more straight-forward for the mobile applications to authenticate directly with Facebook? 

Well, the real business case is the customer wants to add more Social Logins in the near future. e.g. Google, Yahoo, etc... With this implementation, there is no need for any modification on the mobile applications as and when a new Social Login is added.

Nice, isn't it?

.

OpenAM Security Advisory #201403

ForgeRock announced another security advisory last night. The detail can be found here.

Again, if you are a paid customer, then it is very hassle free to apply the patch.

Just download the patches in .jar and drop them into your web container. Restart web container. Done!

Nice!


Updated on 23rd Sep 2014

So, I have been informed that the patches should not be as easy as drop and restart. We should be following the README closely and carry out the steps as instructed.

The million-dollar question is: Where is the README file?

I spent some time and finally found it! It is within the patch (jar).

Oh man! This is very confusing. From my past experience, a .jar is simply a file for one to dump into the /WEB-INF/lib directory on the application server.

Instead, the patch (jar) here is nothing but a zip file. The real codes are .class files that are to be deployed in /WEB-INF/classes.

I prefer zip anytime.


.

Integrate OpenAM with Atlassian Jira - java.lang.AbstractMethodError

One of my teammates tried integrating our in-house Atlassian Jira 4.3.2 with OpenAM 11.0.1. The JIRA we have is quite an old version as I have no time to upgrade it. Anyway, it's working fine for us all these years. :) Ok, I'm lazy.

 

It is quite easy to integrate Jira with OpenAM with help from this wiki - Integrate with Atlassian Jira and Confluence.

However, we kept getting the following AbstractMethodError during runtime.

Cause: java.lang.AbstractMethodError: com.sun.identity.provider.seraph.OpenSsoAuthenticator.getUser(Ljava/lang/String;)Ljava/security/Principal;

Upon another round of checking, we realized there is something different between what is stated in the wiki and what we have in our seraph-config.xml. 

The wiki assumes the older versions of Jira is using DefaultAuthenticator. However, in our XML properties file, we are seeing JiraSeraphAuthenticator (which extends from DefaultAuthenticator).

What to do next? Change code!

Replace DefaultAuthenticator with JiraSeraphAuthenticator in OpenSsoAuthenticator did the trick!




.

OpenAM 11.0.1 - HOTP Callback Header Error

I found this error while customizing the HOTP authentication module on our OpenAM 11.0.1 in test labs. No matter which way I tried - HOTP.xml in default folder or HOTP.xml in default_en folder, the wordings "Please enter your One Time Password, or request a new one" will never get replaced with the value I set in HOTP.xml.

I am, however, able to change the value in Confirmation Callback though.

This never happened in version 10.x.x though.

.

OpenAM OAuth2 Provider - Request not valid, perhaps a permission problem

I have a customer that requires OAuth2 Provider to be configured on their existing OpenAM SSO infrastructure.

So, as usual, I do not like to over-promise by just answering customers' questions based on technical write-ups. I went ahead to set up 2 OpenAM servers - 1 acting as OAuth2 Provider; 1 acting as OAuth2 Client.

Of course, any OAuth2 Client will do. It does not have to be OpenAM server acting as a OAuth2 Client. Ok, I'm just lazy. :)

There is a documentation from ForgeRock on Configuring OpenAM as Authorization Server & Client. Be warned: Do read carefully; Do not skip any step.

So, basically, the 1st step is to Set Up the OAuth 2.0 Authorization Service as illustrated in Configuring the OAuth 2.0 Authorization Service.


Simple task. In fact, very simple task!

BUT ... this is where I encountered issue. After I clicked OK and finished the remaining configuration, I hit the error "Request not valid, perhaps a permission problem" when I started testing.

Enabled debug logs but not too many hints.

After many rounds of debugging, I read the documentation again.

In addition to setting up an OAuth 2.0 authorization server for the realm, OpenAM sets up a policy to protect the authorization endpoint. The policy appears in the list of policies for the realm. Its name is OAuth2ProviderPolicy. 

To make the change, browse to Access Control > Realm Name > Services > OAuth2 Provider, add the profile attributes to the list titled User Profile Attribute(s) the Resource Owner is Authenticated On.

I checked with OpenAM Admin console. I did not see a service by the name of "OAuth2 Provider". Neither did I see a policy by the name of "OAuth2ProviderPolicy".

Very strange indeed. No choice, I clicked on "Configure OAuth2" again to make the default realm to act as an authorization server.

This time round, bingo! OpenAM OAuth2 Provider works like a charm.

The OAuth2 Provider service appeared!

The OAuth2ProviderPolicy policy also appeared!

When I tested again, the following authorization page also appeared:

Maybe my VM was slow the first time I tried to configure OAuth2 authorization service. I'm not too sure! But I'll definitely add the above into my verification steps the next time I configure OAuth2 authorization service again!


.

OpenAM Web Policy Agent 3.3.3 released!

August was super busy month as we were closing our financial year. Nevertheless, I still managed to complete Singapore Bay Run (used to be called Army Half-Marathon) yesterday. SGD$12 for a half-marathon race! The special rate is applied to those who have served National Service. 

Anyway, I just received an email from ForgeRock.

Web Policy Agents version 3.3.3 

This email is being sent to you as our records show that you downloaded the latest maintenance release of the ForgeRock OpenAM Policy Agent 3.3.2. 

An issue around policy enforcement was reported to ForgeRock and we took the decision to rescind the 3.3.2 release of the Policy Agents to be replaced with version 3.3.3. 

If you have upgraded to version 3.3.2 we recommend moving to 3.3.3. If you have yet to install 3.3.2 then please use version 3.3.3 instead.

Remember I posted the release of Web Policy Agents version 3.3.2 just slightly more than a week ago? Internally, we tested WPA 3.3.2 on IIS 7 and Apache 2.4. The policies for SharePoint protected by policy agent on IIS 7 needed some tweaking before it worked. We rolled back the policy agent on Apache 2.4 to 3.3.1. So, there is indeed an issue around policy enforcement.

Web Policy Agents version 3.3.3 will definitely come in handy. We're going to give it a try tomorrow morning.

.