OpenAM with IBM Tivoli Directory Server

We know that from OpenAM version 10.1.0 onwards, the LDAP Authentication module is able to support LDAP Behera Password Policy.

So, I was configuring the LDAP Authentication module for a customer to authentication against IBM Tivoli Directory Server. I did verified that IBM Tivoli Directory Server supports IETF-approved Password Policy (also known as Draft Behera LDAP Password Policy).

To be fair, I have no visibility to what the Customer has configured on the IBM Tivoli Directory Server. And I am not sure whether or not it has been configured properly as per documented by IBM. It's a black box to me.

But no luck! As soon as the LDAP Behera Password Policy Support is enabled, OpenAM will throw the following exceptions:

amAuthLDAP:04/14/2014 02:18:54:972 PM ICT: Thread[ajp-172.19.194.75-8009-3,5,jboss]
WARNING: unable to decode PasswordPolicyResponseControl
org.forgerock.opendj.ldap.DecodeException: Cannot decode the provided password policy response control because it does not have a value
        at org.forgerock.opendj.ldap.DecodeException.error(DecodeException.java:57)
        at org.forgerock.opendj.ldap.controls.PasswordPolicyResponseControl$1.decodeControl(PasswordPolicyResponseControl.java:114)
        at org.forgerock.opendj.ldap.controls.PasswordPolicyResponseControl$1.decodeControl(PasswordPolicyResponseControl.java:90)
        at org.forgerock.opendj.ldap.responses.AbstractResponseImpl.getControl(AbstractResponseImpl.java:119)
        at com.sun.identity.authentication.modules.ldap.LDAPAuthUtils.processControls(LDAPAuthUtils.java:1204)
     
:
:
amAuthLDAP:04/14/2014 02:18:54:972 PM ICT: Thread[ajp-172.19.194.75-8009-3,5,jboss]
No controls returned

So what this means is that use case like Password Expired cannot be automatically detected by OpenAM during authentication.

If IETF approved password policy is supported, then OpenAM should be able to detect Password Expired use case. See Password Must be Changed Now Check.

Currently, based on my testing, OpenAM is treating IBM Tivoli Directory Server as not having the Password Policy Response Control. As such, it is not able to detect Password Expired use case.

In such scenario, OpenAM will treat Password Expired use case as Invalid Credential. The output is the same as what is documented from IBM LDAP documentation.

.

OpenAM 11.0.1 and Policy Agent 3.3.1 released!

Last night, ForgeRock released OpenAM 11.0.1 and Policy Agent 3.3.1 at the same time!

Earlier today we released an important maintenance and security release available for OpenAM 11.0 as well as earlier versions of OpenAM 10.0.x and 9.5.x. These include fixes that address critical security issues such as Denial of Service attacks and SQL Injection attacks.  

.... 

ForgeRock strongly recommends that all customers update their OpenAM deployments with the updated security patches at the earliest opportunity. We appreciate the contribution from our customers and community members that help us to build the best, most secure product. 

If you are a paid customer and on the latest release of OpenAM, the patch is fairly simple.

1. Download the appropriate jar for your OpenAM version
2. Restart your application server

Done. As simple as that. (Well, this is where I feel paid customers should enjoy this convenient service from ForgeRock. Honestly.)


For Policy Agent 3.3.1, the following is the key fixes made:

You can read the Policy Agent 3.3.1 Release Note here.

Mobile . Social Login . Single Sign-On

I was attending a webinar by CA - Enabling and Securing Multi-Channel Customer Interactions. 

Some points caught my attention:

• replace traditional channels with mobile apps if the same customer service features were available
• consumers prefer to use a company's mobile app for routine inquiries rather than calling the company on the phone
• consumers have a more positive view of a company if they have a customer service app

 Social Login benefits:

• access to large volume of social media users
• higher level of conversion to internal prospect list
• more targeted marketing opportunities

Now, based on the facts above, more and more decision makers will move businesses towards the Mobile and will offer Social Login.

Single Sign-On solutions in the market has to get:

• easier to deploy (Cloud ?)
• easier to integrate with Social Login providers
• more secured
• to scale even better and quicker

It's an exciting time to be in now!

.

Version file not updated after OpenAM is patched - Part II

So, according to Peter, there is a bug (See Bugster OPENAM-3280) which will impact the command line ssoadm.

I was trying out ssoadm tool yesterday and observed that the bug does not impact the setup program.

Before I patch OpenAM (which is version 10.0.0), the setup tool is able to detect the version of OpenAM correctly.

After OpenAM is patched (which is version 10.0.2), the setup tool is also able to detect the version of OpenAM correctly.

Now, once the setup is done and you start using the ssoadm command line utility, the bug will come. The command is retrieving value directly from the .version on the file-system, instead of querying directly from OpenAM Configuration Store.

By retrieving value directly from OpenAM Configuration Store, it should behave like what the OpenAM Admin Console will display.

Now, there are really some hardcode people around who insisted to use ssoadm command line utility.
(Ok, I'm just lazy. If given a choice, I'll go for UI. Using command lines doesn't make me any smarter. Ha!) Joke aside, on a more serious note, I think we are making a living trying to provide business solutions to our customers. We do not really need to insist on a certain way of doing things. If there are workarounds, go for it. Case closed, go home early and be with the family.

Back to ssoadm command line utility, before OPENAM-3280 is resolved, there is in fact a more tedious way of getting the correct version of OpenAM.

Use the export-svc-cfg sub-command. (See export-svc-cfg)

This will generate a XML file contains OpenAM Service Configuration.

Within the XML, it'll contain the current version of the OpenAM Server.

By the way, there's another bug with ssoadm. This time, it's not the command line utility issue. It's an issue with the Web UI utility (ssoadm.jsp). See Bugster OPENAM-2979 - ssoadm.jsp does not offer export-svc-cfg subcommand.



.

Version file not updated after OpenAM is patched

I am preparing myself for an engagement in a customer's site tomorrow to patch their OpenAM deployment from 10.0.0 to 10.0.2.

I blogged about OpenAM version 10.0.2 before. You can read it here - OpenAM 10.0.2 released!

The upgrade process is fairly easy. But of course, remember to backup, backup, and backup! You never know what will happen.

Clicking on "Save Report" will download a OpenAM Upgrade Report on the activities that the upgrade is going to take.

OpenAM Upgrade Report
=====================
Created: 20140415144314
Existing Version: OpenAM 10.0.0 (2012-April-13 10:24)
New Version: OpenAM 10.0.2 (2013-December-12 18:38)

Services Upgrade Report
-----------------------
New Services
* None
Modified Services
* sunAMAuthADService
openam-auth-ldap-heartbeat-interval
openam-auth-ldap-heartbeat-timeunit
openam-auth-ldap-operation-timeout
Added attribute openam-auth-ldap-operation-timeout
Added attribute openam-auth-ldap-heartbeat-interval
Added attribute openam-auth-ldap-heartbeat-timeunit
iplanet-am-auth-ldap-server-check
Removed attribute iplanet-am-auth-ldap-server-check
: 

: 

New Sub Schemas
* None
Deleted Services
* None

Server Default Upgrade Report
-----------------------------
New Attributes
* attr name: com.sun.identity.authentication.multiple.tabs.used : value: false

Modified Properties
* attr name: com.iplanet.am.version
old value: OpenAM 10.0.0 (2012-April-13 10:24)
new value: OpenAM 10.0.2 (2013-December-12 18:38)

Deleted Properties
* attr name: com.sun.identity.authentication.mutiple.tabs.used

Based on the Upgrade Report above, the embedded OpenDJ which is used as the default configuration store will update a value in the LDAP attribute called "com.iplanet.am.version".

I found there is a .version text file in the file system.

Before the upgrade, the content within the .version was: OpenAM 10.0.0 (2012-April-13 10:24)

After the upgrade, nothing was changed. But everything runs fine.


Strange indeed.


.

Solaris 10 OS and Oracle Directory Server Enterprise Edition not affected by Heartbleed

We support Solaris 10 OS and Oracle Directory Server Enterprise Edition for a big customer here in Singapore. 

Both are not affected by Heartbleed security flaw.

Oracle Solaris 10 Sparc is not vulnerable to the SSL Heartbleed vulnerability.The latest patched default OpenSSL library in Solaris 10 is version 0.9.7d, which is not affected by the vulnerability. The Heartbleed vulnerability only affects OpenSSL version 1.0.1 to 1.0.1f.

Official response from Oracle Support with regard to Oracle Directory Server Enterprise Edition below:

ODSEE do not use OpenSSL. ODSEE uses NSS for the SSL libraries. You may want to refer to this link for more understanding on the topic: ODSEE 11.1.1.7.0 Administration Guide: http://docs.oracle.com/cd/E29127_01/doc.111170/e28972/ds-security.htm#bcaul

.

ForgeRock Software Not Affected by ‘Heartbleed’

Last week went kind of crazy after the Heartbleed security flaw was uncovered with customers calling to verify if their deployments are affected by the bug.

ForgeRock released a press statement on 11th April 2014.

• ForgeRock’s products (OpenAM, OpenIDM, OpenDJ, OpenIG) do not incorporate openssl. OpenSSL is a commonly used component of open source software and Linux distributions, whereas the vast majority of ForgeRock software runs on the Java platform which uses its own TLS implementation. 

• Some ForgeRock components use the Mozilla Foundation NSS libraries, which are also not vulnerable to Heartbleed. 

In short, ForgeRock software are not affected by Heartbleed.

.

ForgeRock OpenAM: Delivering Trust and Reliability

I didn't say it. A paying customer in Holland said it.

The team considered many access management solutions and eventually decided to implement ForgeRock OpenAM, all-in-one access management platform. A main selling feature for OpenAM was the fact that the solution was open source. 

“Out of all of the access management solutions that we researched, ForgeRock was the best company to offer a fully open source access management platform,” said Paul Saraber, Enterprise Architect, Portbase. “We have found, open source access management solutions to be much more secure than closed source because they allow developers to identify and fix security- related bugs faster than legacy, closed-source platforms.”
.... 

Further, the transparent software subscription model based on a pay-per-use license instead of CPU or VM model that is common among other vendors, offered more value and was easier to manage and budget.

 .

OpenAM Session Failover in OpenAM 11 - Core Token Service (CTS)

So I was with a customer in Thailand last week and I talked about upgrade roadmap for OpenAM. They have OpenAM 10.0.0 currently in their production environment.

We know the OpenAM Session Failover (SFO) prior to OpenAM 10.1.0 was using the Sun Java Message Queue. Pretty complex product which makes debugging a little challenging at times (well, depending on how well trained you are). I have numerous posts in my blog talking about Sun Java Message Queue and how SFO works.

The new OpenAM roadmap since version 10.1.0 is to completely remove this cumbersome layer on the bottom and replaced it with OpenDJ. The Core Token Service (CTS) has been rewritten to use OpenDJ to store users' sessions/tokens.

Session failover also relies on a shared Core Token Service (CTS) to store user session data. The service is shared with other OpenAM servers in the same OpenAM site. When an OpenAM server goes down, other servers in the site can read user session information from the CTS, so the user with a valid session does not have to log in again. When the original OpenAM server becomes available again, it can also read session information from the CTS, and can carry on serving users with active sessions.

From operational perspective, this new feature is very much welcomed. Customers do not have to learn additional technology like Sun Java Message Queue. Instead, what they have to focus on are OpenAM and OpenDJ. And I must say both are relatively easier to pick up. Forget about Sun Java Message Queue!

Now, there is 1 thing to take note of for multi-instances deployment. One has to read carefully the documentation - CTS Deployment Scenario.

I quoted from the documentation below:

To reduce the impact of any given failure, consider the following options:

• Start your implementation, if possible, with the CTS options available with the OpenDJ instance embedded in OpenAM. You can still set up a different backend on the embedded OpenDJ server. If the embedded OpenDJ server can handle your requirements, it will simplify implementation of CTS.
• Isolate the user, configuration, and session stores from OpenAM in separate external OpenDJ servers.
• Configure multiple directory stores for CTS, set up with load balancer(s).
• Add separate servers for data store replication. For more information on how this is done with OpenDJ, see the OpenDJ documentation on Stand-alone Replication Servers.
• Set up redundancy in the load balancer connections between OpenAM and the external data store.

A load-balancer is required in-front of the multiple external OpenDJ servers for multi-instance deployment. Why? The diagram below says it all.

There is only a single field to key in the Directory Name. The code cannot handle multiple OpenDJ in the backend. This is weird because the existing Authentication module and Data Store module are able to load-balance and failover multiple OpenDJ backends.

Unless there is a technical reason for intentionally not to support multiple OpenDJ from CTS layer. Well, I do not have the answer. I just find it a step backward with this new feature.

.

Custom OpenAM Login Page for new realm

March was full of activities for me. It was quarter-end for some customers and we were pushing hard to close as many deals as possible… right to the very last day of the quarter! Well, customers have money to spend, it's my job to help them spend wisely. :)

Of course, how can life be exciting without some running? Mid-March, I took a few days off to Hong Kong for TransLantau50 - a super challenging 50km trail race.

Once the quarter was closed, I flown off to Thailand to visit another customer. They already have OpenAM deployed a year ago and are looking to extend their SSO infrastructure to external users. With this new requirement, a new realm is recommended. They also want a totally different look-and-feel for the external users.

Can it be done easily in OpenAM? Why not?

The latest OpenAM Documentation explains it all. See To Copy the Pages to Customize For Another Realm.

In OpenAM mailing list, there are questions on why customization does not work every now and then. I think the trick is now following the instructions carefully. The technical writer said it all. I help to summarize below:

Modify appearance if you must by editing the .jsp, image, and CSS files without changing any of the JSP tags that govern how the pages work. 

Modify the localized text, using UTF-8 without escaped characters, by changing only the original text strings in the .xml files. 

If necessary, restart OpenAM or the web container to test the changes you have made.

I also like the section on How OpenAM Looks Up UI Files. It explains very clearly how the codes go about finding customized UI files.

OpenAM tries first to find the most specific file for the realm and local requested, gradually falling back on less specific alternatives, then on other locales. 

The first and most specific location as follows.
suffix_client-locale-language_client-locale-territory/services/realm/client-name/file-name

Great stuff!

.