Identity Matters

The move from JAAS to JASPI subtly changes how we interact with identities. In the world of JAAS we deal with Subjects who are the entities making a request, typically a user, whilst Java EE deals with Principals, the representation of that entity such as a username. The difference may not seem great, but a Subject may have several Principals and this has caused some headaches when using JAAS, leaving determination of the relevant Principal to the implementation.

The days of JAAS have long been numbered however, and JSR-196 (also known as JASPI or JASPIC) is emerging at last; inclusion in JEE6 has definitely helped to push JASPI beyond just Glassfish support.

One of the changes is using the CallerPrincipalCallback to present to the container which Principal is applicable; and which is then available in the ServletRequest using getUserPrincipal(…).

Some background music for mulling over Subjects and Principals: Subject’s theme from Aldo Nova

Like Ozzy Osbourne, we too want to sing about REST but not Ezekiel’s troubled sea. The world of Representational State Transfer (REST) is the rebirth of HTTP as something more meaningful than a prefix in your browser.

So getting back to the origins of GET and POST (familiar friends), delving into PUT and  DELETE (probably strangers), and bringing it full circle to CRUD (relations you have to invite to every party) we are deep within the psyche of OpenAM where all things good are now viewed with RESTful glasses.

Embracing OAuth2 as a powerful emerging standard and revamping the OpenAM Identity Services that provided a REST-like interface to core functionality is only the start. The shift to a resource-oriented architecture (ROA) is underway and hopes to bring lightweight, flexible access to many more features of this great product.

Stay tuned for updates, and enjoy some Ozzy.

OpenAM 10 is out and hits the market with a respectable range of new features. Nudging double digits is no trick and reflects a maturity and age of the product that stretches back towards the last millenium. Living that long in the world of software is not achieved lightly and involves constantly re-visiting the techniques and technologies used to stay on top of the pile.

OpenAM 10.0.0 is the result of several months of intensive research and development work at ForgeRock combined with input and feedback from the flourishing ForgeRock open source community for OpenAM and our customers. This release significantly strengthens the security and integration capabilities of the standards based I³ Open Platform. It includes improvements in the areas of Federation with SAML 2.0 and OAuth 2.0, application integration, Risk Based Authentication, and key enhancements in security, reliability, performance and the underlying replication architecture.

The release features the following industry-leading capabilities:

• Open Identity Gateway (OpenIG): A high performance identity proxy that expedites the integration of web applications into an OpenAM Single Sign-On environment without touching the application. Ideal for legacy applications where changes to the security model are contraindicated. OpenIG also extends the SAML 2.0 Service Provider capabilities of the OpenAM offering.
• Risk Based Authentication: Measure the risk associated with an authentication event and challenge with additional stronger credentials if the need arises. This is now part of the authentication framework and includes capabilities such as geographic location evaluation, time since last login, number of authentication failures check, ip address history check, cookie associated with a device check and attribute profile check, among others.
• OAuth 2.0 authentication: Users can now federate their accounts from Google, Facebook, MSN, and any OAuth 2.0 provider with OpenAM.
• SAML 2.0 Identity Provider enhanced capabilities that ease the interaction with end-users for several tasks such as approval of attribute release to service providers. This is implemented as an additional hook into the SAML 2.0 framework.
• ForgeRock’s OpenDJ is now the embedded configuration store.

OpenAM comprises in one single product the features and capabilities usually found in several products. The latest version can be obtained from the OpenAM community downloads area.

Read more about the new release here

Norway is in a nice place when it comes to national identity federation. Aside from having the will to make it work, there are the very practical advantages of a unique national identifier and a trusting population to match. The child of these factors was a project called “MyID” that provided citizens with an authentication solution based on reusable pin codes and federating according the SAML2 standard.

Since it’s inception the solution has developed; or rather it’s goal has moved and the system has adapted. Back in the day, MyID was created to meet a specific need: authentication for the service aggregation portal “MyPage” that would support magic links (read: single sign on with aggregated services). Today, MyID has been superseded by ID-Porten which wraps the original pin code solution in a solution which also offers other authentication methods from smart-card based identity providers as of version 2.0, and that provides authentication for over 180 public service providers.

My personal satisfaction comes from seeing a national federation solution succeed so grandly; the majority of the Norwegian population over 13 use MyID/ID-Porten when interacting with the government! And did I mention that it is running on some fantastic open source access management software?

PS: I mentioned the Norwegian national identifier as a practical advantage, but didn’t claim that this was the right way to do it. Certainly the direction has to be away from using a single identifier even if it does make life easier, and thankfully this is where I understand ID-Porten to be headed.

A recent request on the mailing list caught my attention as I’ve been working on this just recently. In OpenAM, every log entry has a ContextID but which context is this really? Unfortunately, the answer is not too simple, and tracing activity over the course of a federated authentication, for example, is not trivial.

I’ll take a typical scenario where OpenAM is an IDP in a SAML2 federation, with focus on the following log events:

1. SP sends AuthnRequest to OpenAM IDP
2. Module based authentication using LDAP module
3. Login success log message
4. (Post processing log message)
5. ArtifactResolve and Response
6. Single logout

As stated above, each log entry has a ContextID which is the OpenAM session ID of the user who performs the log operation. Easy, right? Well, no. Taking the first event here, an SP who sends an AuthnRequest to the IDP (OpenAM), then the incoming AuthnRequest is logged to the SAML2 log but since we don’t have a user in the picture (no response has been sent to the user yet) then this is logged by an administrative user. This means that for #1, the ContextID is actually a session ID that may also be shared by other log operations for different users. The AuthnRequest xml contains a MessageID which can be used later for tracing purposes.

The next message in this scenario, where the user authenticates using the LDAP module, could be success or failure – in any case, the user at this point is in dialog with OpenAM and has received an AMAuth cookie which represents their session. So for #2 the ContextID is the session ID of the user whilst they are authenticating. As we will see, the session is replaced with an authenticated session shortly afterwards.

By the time the user has met the authentication requirements in the module or chain/service, then a big change happens: in the LoginState class the temporary session used whilst authenticating is destroyed and a new authenticated session created containing user attributes. the iPlanetDirectoryPro cookie is set with the session ID of this new session and the AMAuth cookie is removed. After this point (#3 and #4) all the user operations are logged with a ContextID that is the session ID of their authenticated session.

One exception to this is in a SAML2 Artifact profile, where the SP has received a token and calls a web service to resolve it, the ArtifactResolve message. This request is direct from SP to IDP and not via the user’s browser, so OpenAM has no immediate access to the user’s session cookie. The receipt of the ArtifactResolve message is therefore logged as an administrative user, similar to #1 but not necessarily the same, and not unique to the user involved. So the ContextID in #5 is fairly meaningless. However, the SAML2 messages are traceable through the MessageID and InResponseTo attributes. Also, in the ArtifactResponse message (the SAML Assertion), there is a session ID which is separate from the OpenAM session ID, and that can be traced to #6 Single logout.

–

The above behaviour is partly due to the information available at each time, but there are definitely ways of improving traceability of log messages. This is on the roadmap here at ForgeRock; watch this space!

(PS: This post is written from memory so there may be some misplaced details. I’ll try to review it with my notes in front of me next week)

The ForgeRock is a rolling stone at the moment and gathering no moss. Here are some of the things we have been up to recently:

• Revamping our website
• Fixing known OpenSSO issues in OpenAM
• Continuing development of OpenIDM
• Expanding our ForgeRock organization in the US and UK
• Unveiling Open Source guru Simon Phipps as Chief Strategy Officer
• Talking to James Gosling
• Supporting customers like BetFair and the Norwegian Railways as they go into production on OpenAM

As it happens, our Rock is at the top of a big hill and we are still picking up speed

Names come in all forms and sizes; official and informal, first middle and last, identifiers and labels. And here is a new type of the name: the ForgeRock name.

As Joe Brockmeier discussed in a blog entry last year, Open Source does not normally say anything about the trademarks that may apply to the software. The current situation in Sun-Oracle may leave a number of Open Source projects out in the cold – and when crunch time comes (is it here already?) then this may be a hot issue.

As Oracle recently removed all open downloads from opensso.org, ForgeRock are the new home of binary downloads for the OpenSSO community, providing essentially the same compiled code as before. Except for the name.

So – OpenAM is the new OpenSSO. Remember the name next time you need a build

One month has passed since Oracle completed their takeover of Sun. That month began with announcements of which products would be “strategic”, and a new company called ForgeRock was born. Relative quiet ensued as Oracle and Sun apparently got down to the internal bit and bolts of merging two organizations. It looks like the time has now come for Oracle to put their Open Source strategy into practice.

On February 24th, the OpenSSO Express builds were removed from opensso.org and the only remaining OpenSSO Enterprise download links to a protected page that requires a support contract with Oracle. At about the same time, the product roadmap on the same site was deleted entirely. Reports about this have started appearing in the media over the last few days, like here and here.

It is too early to draw conclusions, but if this is indicating a future direction then it does not bode well for the community. I don’t believe you can seriously run an Open Source project without providing any binaries. A member of the community who wants to get involved on opensso.org now faces a long series of tasks to check out the source code, set up their build environment and compile the binaries themselves – all this instead of the simple binary download before.

ForgeRock is stepping up to the plate here and providing OpenAM binaries built from the OpenSSO code (the product name is a potential issue so we are using different names), but this still does not change that the steps Oracle have taken over the last few days are in my opinion aimed at stifling the community rather than allowing it to continue to thrive.

Everything starts somewhere, and this blog is starting for a reason. We at ForgeRock have recently launched our business and have a lot to say – this blog is one of those ways

So I can start off by saying that the purchase of Sun by Oracle took a long time but was finally completed on January 27th. As you will see from www.forgerock.com, ForgeRock has it’s roots in the software side of Sun, with almost all our employees having a background from Sun. Naturally we have been interested to see how the takeover would play out, especially with regards to Sun’s open source strategy. Oracle has made several statements about the direction they will be taking including these webcasts.

One of open source products we are particularly involved in is OpenSSO – a fully-featured, enterprise-class product for authentication, authorization, federation and much more. Oracle has said that OpenSSO will continue as an open source project but that Oracle Access Manager will be their strategic product for web single sign-on, and Oracle Federated Identity Manager for federated single sign-on.

What does the “strategic” product choice mean in practice? Nishant Kaushik (architect for Identity Management products at Oracle) in his blog answers like this:

“Strategic” means that this is the product that we will be innovating and developing new features for.

So according to this Oracle will not be innovating and developing new features for OpenSSO, but still hosting the open source project. This can also be seen on the employee side of Oracle where key players from the OpenSSO team are apparently either no longer working there or have been transferred to other teams.

What is the next step for OpenSSO then?

ForgeRock