OpenIDM 3.1 released

OpenIDM 3.1 was released on 3rd December 2014. The announcement can be found here.

This is an exciting release as the UI for managing connectors and objects has finally arrived! It doesn't matter a lot to hard-core engineers. But believe me, one of the customers' evaluation criteria is a easy-to-use Admin UI. In fact, it is an item that is high up in the evaluation list.

So, I just finished attending ForgeRock Partner Focus Session. Following is a quick highlight of OpenIDM 3.1.

Some marketing stuff below :)

Roadmap for OpenIDM 4.0 below:

Great stuff! Latest version of OpenIDM can be downloaded from here. 

Google reCaptcha revamped!

We integrated SimpleCaptcha with OpenAM for one of our customers before. And the #1 complaint was always "How to make the distorted words or numbers more human-readable?"

Google's reCaptcha technology was also based on  distorted words or numbers. But they are now changing ... reCaptcha will be reduced to nothing more than a single checkbox next to the statement “I’m not a robot.” (Source here)

Instead of depending upon the traditional distorted word test, Google’s “reCaptcha” examines cues every user unwittingly provides: IP addresses and cookies provide evidence that the user is the same friendly human Google remembers from elsewhere on the Web. And Shet says even the tiny movements a user’s mouse makes as it hovers and approaches a checkbox can help reveal an automated bot.

This is a good move!

OpenAM . OpenUMA

In the recent IRM Summit held in Ireland, ForgeRock announced OpenUMA, an open source community initiative focused on addressing public concerns around privacy and consent in the digital age.

The initiative marries the increasingly popular technical standard, User-Managed Access (UMA), which provides a blueprint for addressing digital consent and privacy, with ForgeRock’s open source access management project, OpenAM. 

Believe it or not, weeks before the announcement of OpenUMA, I was in a customer's site based in Singapore and the IT Director was discussing with me the roadmap for OpenAM and the features he was looking for.  FYI, we have deployed OpenAM 10.0.1 for his company and are in the midst of upgrading to 10.0.2.

Most of his applications are .Net and his authentication source is Microsoft Active Directory. He is thinking of migrating to Office 365 in the near future. That makes OpenAM 12 a good candidate.

We were wondering what does "Cloud Connector Wizards - Office 365" mean? I presumed it meant OpenAM 12 can better integrate with Office 365. And that's why we were not hurry to upgrade to OpenAM 11.x. Instead, we chose to upgrade to the latest stable release of OpenAM 10.

We moved on and he told me his biggest nightmare now is every application is implementing their own authorization rules. He wanted to isolate authorization from every application and implement at a higher-level in OpenAM. OpenAM is where he saw will be the centralized Authentication & Authorization engine.

The authorization in discussion here is not coarse-grained authorization currently implemented in OpenAM policies & OpenAM Policy Agents. He is looking for an enterprise-wide access management for applications. I searched around and found Access Management 2.0 for the Enterprise to be the correct term.

There is a case study written by Eve Maler - Case Study: Access Management 2.0 for the Enterprise. By the way, I told him Eve Maler has already joined ForgeRock as vice president of innovation and emerging technology. And I even told him there should be something exciting brewing. :)

Coincidentally, weeks later, OpenUMA is announced.

The million dollar question is when will OpenUMA be fully integrated with OpenAM?


.

OpenAM Security Advisory #201404

3 days ago, ForgeRock announced yet another security advisory #201404 - the 4th this year.

Good trend? Bad trend? To me, I read it as OpenAM deployment base has become larger and more people are using it for real deployments. With more eyes, more bugs will be found. That's a good thing for the community!

#201404 - Denial of Service vulnerability – CVE-2014-7246
In environments where more than one OpenAM server has been configured, it is possible that an authenticated attacker can construct and send a single request that triggers an infinite loop, occupying one or more instances in the deployment until the affected instances are restarted.

Another thing to note:

See that? The patch bundles are now distributed in .zip, instead of .jar. This better reflects what the patch bundles should be used for. To unzip, read the instruction(s) and to deploy the patches, which are usually in .classes. 

My positive feedback comes true! (See my previous blog) :) Well done! 

.

Insufficient Access Rights: You do not have sufficient privileges to perform an unindexed search

In my previous post, I mentioned that we are currently migrating OpenAM 9.5.3 to OpenAM 11.0.2 for a customer based in Singapore. At the same time, we are migrating a very old OpenDJ 2.4.3 to OpenDJ 2.6.1.

And of course, we do have customized schema in OpenDJ and customized codes in OpenAM. Which customer will not have customized requirement?

Anyway, when we run an unit test against the new setup, we encountered the error below:

11:24:50.514 [http-apr-7070-exec-1] DEBUG DEBUG - [LdapConnection - getAttributes] Getting attributes for filter (sgloginid=USERA)

11:24:50.532 [http-apr-7070-exec-1] ERROR DEBUG - Check devices command exception: Proxy User ID: USERA  User ID: USERA, Facebook ID: null, M2GW IP: x.x.x.x

org.forgerock.opendj.ldap.ErrorResultIOException: org.forgerock.opendj.ldap.AuthorizationException: Insufficient Access Rights: You do not have sufficient privileges to perform an unindexed search

        at org.forgerock.opendj.ldif.ConnectionEntryReader.hasNext(ConnectionEntryReader.java:235) ~[opendj-ldap-sdk-3.0.0-SNAPSHOT.jar:na]

One of my colleagues googled and directed us to OpenDJ Administration Guide Indexing Attribute Values - Determining What Needs Indexing.

A quick fix is to grant unindexed-search privilege to the account that binds to OpenDJ. But should we?

No, I do not think so.

The article says it all, in order of preference to resolve unindexed search issue:

1. If directory users tell you their client applications are getting this error, then you can work with them either to help them make their search filter specific enough to use existing indexes, or to index attributes they need indexed in order to perform their searches.

2. If you do need to allow some applications to perform unindexed searches, because they need to retrieve very large numbers of entries for example, then you can assign them the unindexed-search privilege.


In our case, we should index the attributes as sgloginid is used very frequently in OpenAM for authentication and in another customized application.

.

Unbreakable (backward-compatible) OpenAM Login Page

I am currently migrating OpenAM 9.5.3 to OpenAM 11.0.2 for a customer based in Singapore. In fact, I migrated Sun Access Manager 7.0 to OpenAM 9.5.3 few years back for the same customer. How time flies? Getting older. :)

The migration is pretty smooth so far … with a little surprise and confused me for a while.

We know the UI for OpenAM 11 looks like the one below:

But after I ported customized codes and JSP pages over, I was constantly redirected to the old OpenAM server! How can it be?!! The below was what I saw...

It took me (and my colleague too) quite a while to realize that we are in fact landing at OpenAM 11 Login Page.


See the differences below? ForgeRock logo and footer are different in OpenAM 11.

Ok lah, from backward-compatible point of view, well done man! Good job!


By the way, I ended last month with a 50-km trail race - The North Face Singapore.

Awesome run!

.

Oracle Directory Server Enterprise Edition 11g supports Windows Server 2012

A customer called to ask if their existing Oracle Directory Server Enterprise Edition 11g can run on Windows Server 2012 R2.

A check with Oracle Directory Server Enterprise Edition 11g Certification Matrix System Certification confirms it is a 'YES'.

But do note: All components (except Directory Proxy Server) would run in 32 bits only.

.

Message:Service does not exist : sunAMAuthApplicationService

This is a super misleading error message in OpenAM Authentication debug log. If you turn on debug level to Message and restart OpenAM, it will appear almost 100% of the time.

And last Saturday, I was at a customer's site which had a farm of OpenSSO 8U1R2 running. I was trying to debug on a node and switch to Message level, and I was seeing the same misleading error!

Wow! This has been there for years! This post is to remind myself to ignore it the next time I see it again.

amAuthConfig:10/18/2014 03:48:25:480 PM SGT: Thread[pool-1-thread-11,5,main]
Error retrieving service schema
Message:Service does not exist : sunAMAuthApplicationService
        at com.sun.identity.sm.ServiceSchemaManagerImpl.isValid(ServiceSchemaManagerImpl.java:135)
        at com.sun.identity.sm.ServiceSchemaManagerImpl.(ServiceSchemaManagerImpl.java:115)
        at com.sun.identity.sm.ServiceSchemaManagerImpl.getInstance(ServiceSchemaManagerImpl.java:589)
        at com.sun.identity.sm.ServiceSchemaManager.(ServiceSchemaManager.java:112)
        at com.sun.identity.sm.ServiceSchemaManager.(ServiceSchemaManager.java:77)
        at com.sun.identity.authentication.config.AMAuthLevelManager.updateGlobalAuthLevelMap(AMAuthLevelManager.java:697)
        at com.sun.identity.authentication.config.AMAuthLevelManager.initialize(AMAuthLevelManager.java:199)
        at com.sun.identity.authentication.config.AMAuthLevelManager.(AMAuthLevelManager.java:97)
        at com.sun.identity.authentication.config.AMAuthLevelManager.getInstance(AMAuthLevelManager.java:109)
        at com.sun.identity.authentication.config.AMConfiguration.addServiceListener(AMConfiguration.java:770)
        at com.sun.identity.authentication.config.AMConfiguration.getModuleBasedConfig(AMConfiguration.java:624)
        at com.sun.identity.authentication.config.AMConfiguration.newConfiguration(AMConfiguration.java:213)
        at com.sun.identity.authentication.config.AMConfiguration.getAppConfigurationEntry(AMConfiguration.java:691)
        at com.sun.identity.authentication.service.AuthUtils.isPureJAASModulePresent(AuthUtils.java:1528)
        at com.sun.identity.authentication.service.AMLoginContext.executeLogin(AMLoginContext.java:315)
        at com.sun.identity.authentication.server.AuthContextLocal.login(AuthContextLocal.java:435)
        at com.sun.identity.authentication.server.AuthContextLocal.login(AuthContextLocal.java:371)
        at com.sun.identity.authentication.AuthContext.runLogin(AuthContext.java:675)
        at com.sun.identity.authentication.AuthContext.login(AuthContext.java:572)
        at com.sun.identity.authentication.AuthContext.login(AuthContext.java:524)
        at com.sun.identity.authentication.AuthContext.login(AuthContext.java:383)
        at com.sun.identity.security.SystemAppTokenProvider.getAppSSOToken(SystemAppTokenProvider.java:78)
        at com.sun.identity.security.AdminTokenAction.getSSOToken(AdminTokenAction.java:295)
        at com.sun.identity.security.AdminTokenAction.authenticationInitialized(AdminTokenAction.java:143)
        at com.sun.identity.authentication.UI.LoginLogoutMapping.initializeAuth(LoginLogoutMapping.java:103)
        at com.sun.identity.authentication.UI.LoginLogoutMapping.init(LoginLogoutMapping.java:65)
        at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1100)
        at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1023)
        at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4969)
        at org.apache.catalina.core.StandardContext.start(StandardContext.java:5376)
        at com.sun.enterprise.web.WebModule.start(WebModule.java:345)
        at com.sun.enterprise.web.LifecycleStarter.doRun(LifecycleStarter.java:58)
        at com.sun.appserv.management.util.misc.RunnableBase.runSync(RunnableBase.java:304)
        at com.sun.appserv.management.util.misc.RunnableBase.run(RunnableBase.java:341)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)

.

POODLE SSL Bug and the impact on OpenDJ

Ludo has posted a blog on POODLE SSL Bug and OpenDJ.

Good read!

OpenAM acting as OAuth2 Provider and OAuth2 Client - Part II

So I finished September with my 1st ever 101km run - Craze Ultra 101.

Just to put a closure to my previous blog on OpenAM acting as OAuth2 Provider and OAuth2 Client, I have the following slide which was presented to a client a week ago.

The real beauty of having OpenAM acts as an OAuth2 Provider and OAuth2 Client is the flexibility and ease in rolling out new Social Logins.

With this implementation, there is no need for any modification on the mobile and web applications as and when a new Social Login is added.

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.

.