Saturday, November 30, 2013

OpenAM 11.0.0 Upgrade - Embedded OpenDJ Upgrade Issue

So, OpenAM 11.0 has been released and we being an ForgeRock Open Identity Stack implementor need to eat our own dog food.

We have a pair of OpenAM 10.1-Xpress running in Production, so I went ahead to upgrade the pair one at a time.

No good! As soon as the new WAR file was deployed and the Tomcat started, the following error is encountered  - "OpenDJ upgrade failed with code: 1".

Looking further at OpenDJ upgrade log, it showed "msg=An error occurred when trying to upgrade the config/upgrade folder:null".

Wow! This was tough. The error was too generic. Searched OpenDJ bugster and found this : OPENAM-2783 OpenDJ upgrader fails to upgrade from 10.1.0-Xpress.

The status was FIXED. And I still encountered same error!! How can it be?

Hmmm... looking at the logs again and again... and I noticed OpenDJ upgrader was reading a file "cts-add-schema.ldif.ORIGIN" right before exception occurred.

I went to the directory and found the said file exist! That reminded me that I did something to the schema sometime back. (Read my previous blog here)

So, I went ahead to remove this file and restarted Tomcat again.

Bingo! Nice!

PS: But is that to say there cannot be any "illegal" schema file(s) in the schema directory at all? 


Friday, November 29, 2013

OpenAM 11.0.0 Upgrade

Time to upgrade to OpenAM 11.0.0, isn't it? :)

Well, before doing so, I think it is best one read this document first - OpenAM 11.0.0 Upgrade Guide.

I find this particular section useful.

Best Practices for Upgrades 
1.2.1. Route Around Servers During Downtime  
1.2.2. Back Up the Deployment  
1.2.3. Apply Customization Before Upgrading 
1.2.4. Plan for Rollback

These best practices have been repeated for years, but we do see upgrade failure cases pretty often.

I think most people just read and think they know. However there is no proper thought process going on, which constitutes to failure.

And the worst scenario is there is no Development nor Staging environment to practice prior to Production upgrade! (Yes, this is very true, especially in Asia region. )


Thursday, November 28, 2013

OpenAM RESTful Services

Prior to OpenAM 11.0, there is a set of RESTful APIs for developers to use to perform various operations like Authentication, Logout, Token Validation, Token Attributes Retrieval (See Use OpenAM RESTful Services).

In OpenAM 11.0, there is an enhanced set of RESTful APIs. These are JSON-based APIs. (See Using RESTful Web Services)

The proper use of RESTful Web Services can be briefly illustrated like the following flowchart:

This makes the applications making RESTful calls independent of any domain cookies, which is nice to have. This is really useful in a Cross Domain Single Sign-On (CDSSO) scenario. (Of course, the other alternative is to use Policy Agent which will transparently make the CDSSO work like a charm.)

2 days ago when I visited one of my customers, I came to know that their developers have somehow mis-interpreted the original intention of RESTful Web Services. They have a hybrid way of using RESTful Web Services.

Of course, it works previously as the application resides in the same domain as the OpenAM servers. But it would not work when we start to change the domain name of the application, which the higher management has the intention to do so for branding purpose. 

Please … if one is to use RESTful Web Services, please do not work with cookie. Make it a pure RESTful experience!


Tuesday, November 26, 2013

ForgeRock BackStage

I just came back from a 10-day holiday in New Zealand. Amazing place to be in! The scenery is best to none!

And I did a 32-km trail run on a sunny Saturday morning last weekend - The Great Cranleigh Kauri Run. Awesome view when I ran on the ridge!

By the way, I came back last night and received an email from ForgeRock Support. 

The BackStage has gone LIVE! BackStage is the new Customer Portal from ForgeRock. 

BackStage is the first step in providing a new level of service engagement between ForgeRock and our customers. It brings together our key online customer services into a single convenient location so that you will find your downloads, support tickets and product enhancement requests all in one place. The existing download site will be merged into the customer portal and as a subscription customer you will also be able to gain access to maintenance downloads and any critical or security patches available for your products.
BackStage also introduces a support ticket wizard to help you create tickets that more accurately reflect the nature of your problem, leading to a more efficient support process and hopefully a speedier conclusion. BackStage will also allow you to view your open support tickets; selecting a ticket will take you directly into the support system allowing you to view and update the ticket as usual.

To my customers, what is most important is Patches! :)

This is what matters to them most and this is exactly what they are paying for - timely patches for their mission-critical 24/7 Identity and Access Management System.


Friday, November 15, 2013

Internet of Things

Everyone is talking about "Internet of Things" these days … Today, I came across an article from CA which talks about the same topic. The same article makes reference to ISACA - 2013 IT Risk/Reward Barometer.

The following chart is interesting as it also highlights the consumers' concern ("Not knowing who has access to information collected by connected devices"), which is quite alarming high to me - 44%.

The survey also captures the type of Governance Issues that comes with Internet of Things.

The top 3 are:
1. Increased security threats
2. Data privacy
3. Identity / access management

Yes, IAMS has a room to play in the Internet of Things ….  As I always say,  Cloud, Mobile, Social is not going to go away anytime soon. They will just get bigger, and we should better prepared ourselves for them.


Wednesday, November 13, 2013

OpenDJ Entry Cache

I was setting up LDAP Monitoring cn=monitor for OpenDJ for a customer. There is a section on "Cache" and I was curious to try it out.

However, the Entries in Cache, Cache Hits and Hit Ratio are always 0.

Then I remembered there is a chapter in OpenDJ document - Entry Cache Settings.

OpenDJ implements an entry cache. The entry cache is not designed to cache every entry in your database, but is instead useful in cases where you have a few, typically large entries that are regularly used. For example, if you have a few large static groups and applications that regularly check group membership, you could cache your group entries.

Unlike Sun DSEE, OpenDJ is designed differently. It is not useful to enable the entry cache for user entries in OpenDJ in general. However, it is much more efficient to have a larger JVM and tune the database cache to make sure the whole database files are cached.

Read this chapter - Database Cache Settings.
Database cache size is, by default, set as a percentage of the JVM heap, using the backend property db-cache-percent. Alternatively, you use the backend property db-cache-size to set the size. If you set up multiple database backends, the total percent of JVM heap used must remain less than 100, and must leave space for other uses. Default settings work for servers with one user data backend JVM heaps up to 2 GB. For heaps larger than 2 GB, you can allocate a larger percentage of heap space to DB cache.
Depending on the size of your database, you have a choice to make about database cache settings. By caching the entire database in the JVM heap, you can get more deterministic response times and limit disk I/O. Yet, caching the whole DB can require a very large JVM, which you must pre-load on startup, and which can result in long garbage collections and a difficult-to-manage JVM. Test database pre-load on startup by setting the preload-time-limit for the backend. 


Tuesday, November 12, 2013

Native Mobile Application SSO

This article (Native apps and the NAPPing giant for mobile SSO) from Ping Identity is good read. It talks about the limitation of OpenID Connect for mobile native applications.

... native application model should be with us for a while...

Federation protocols such as SAML, WS-Federation, and OpenID - designed to enable SSO for browser applications, don't work so well for native mobile applications. Consequently, OAuth, and more recently OpenID Connect, have emerged. 
While optimized for the authorization and authentication of native applications, OAuth 2.0 and OpenID Connect do not themselves enable SSO across native applications, i.e. the authentication performed for one application is not generally shared for a different native application.

In OpenID Foundation, a new group - Native Applications (NAPPS) Working Group will define a profile of OpenID Connect (OIDC) that will enable a standardised cross-app SSO experience - for both consumer-centric and enterprise applications.

Pretty cool!


Monday, November 11, 2013

OpenAM 11.0 released!

The much anticipated OpenAM 11.0 has been officially released.

This is quite a major release with a long list of new features and enhancement.

My favorites are always those from my own customers:

  1. New OpenAM Core Token Service (CTS)
  2. Adaptive authentication capabilities now include the Device Print authentication module
  3. OpenAM now fully supports Internet Protocol version 6 (IPv6) in addition to IPv4.
  4. OpenAM now fully supports Java 7 environments.
  5. OpenAM Session failover has been modified to be simpler to deploy
  6. The Persistent Cookie module has been added to support configuration of cookie lifetimes, based on requests and a maximum time.
  7. The AMLoginModule now lets authentication modules retrieve the list of current session tokens for a user
  8. The REST authenticate command now has a parameter to specify the client IP address
  9. You can now prevent OpenAM from caching subject evaluations for policy decisions


Saturday, November 9, 2013

OpenDJ Rest API - Part III

In case you encounter the same error as what I encountered, this is what I did to resolve the issue.

The entry ou=people,dc=example,dc=com specified as the search base does not exist in the Directory Server.

Kind of strange to me initially. When I installed OpenDJ, I have explicitly configured my root suffix to be dc=azlabs, dc=sg. How come the Rest2Ldap interface is responding with a "dc=example,dc=com" error message?

Then I remember there is a configuration file http-config.json - which I said is the "soul" of Rest2Ldap. 

There you are... by default, the http-config.json consists of mapping to "dc=example,dc=com".

All I needed to do is to change all references of "dc=example,dc=com" to "dc=azlabs,dc=sg".

After that, stop-ds followed by start-ds. Fire a curl again.


Ops! Mine was a hacker's act. For a production system, please do the following to reload the http-config.json.

Force the HTTP Connection Handler to reread its configuration.
$ dsconfig
 --port 4444
 --bindDN "cn=Directory Manager"
 --bindPassword password
 --handler-name "HTTP Connection Handler"
 --set enabled:false
$ dsconfig
 --port 4444
 --bindDN "cn=Directory Manager"
 --bindPassword password
 --handler-name "HTTP Connection Handler"
 --set enabled:true


Friday, November 8, 2013

OpenDJ Rest API - Part II

I continued to have fun with OpenDJ Rest2Ldap Interface. 

So how does one determine whether the Rest2Ldap interface is enabled? By default, it is disabled. 

To enable, follow the below example:

$ ./dsconfig set-connection-handler-prop --hostname --port 15444 --bindDN "cn=Directory Manager" --bindPassword password --handler-name "HTTP Connection Handler" --set listen-port:18080 --set enabled:true --no-prompt --trustAll

$ netstat -an | grep 18080
tcp        0      0 :::18080                    :::*                        LISTEN

We can use the status command to check the HTTP Connection Handler status (aka Rest2Ldap interface).

Or, like myself, we can take a look at config.ldif.

ds-cfg-config-file is the "soul" of Rest2Ldap.

This is where the mapping occurs to expose directory data over HTTP as JSON resources. The artifact for serving JSON resources is a REST to LDAP Gateway, which is technically a Servlet. The Servlet will be followed by a REST to LDAP Connection Handler within OpenDJ.

The benefit is of course to allow applications that do not support LDAP protocol to retrieve directory data via HTTP transport.