JavaOne 2008: OpenSSO – creating federated relationships for secure SaaS, Social Networking and Web 2.0

Near the end of CommunityOne, I am currently attending a session on OpenSSO by a lively team of presenterts from Sun. The objective of OpenSSO is to provide a way to establish the identity once for a user and share that identity across a range of applications. Or in the mission statement: “The goal of OpenSSO is to provide an extensible
implementation of an identity services infrastructure that will
facilitate single sign-on for web applications hosted on web servers
and application servers.”

Business Case: enterprises are outsourcing important business functionality to external parties. For example: Mail and Calendar functionality to Google, SalesForce.com and many other SaaS providers. Establishing identity in such scenarios is very important: the identity is established within the enterprise and that authenticated identity is to be used for those external (SaaS based) applications.

Users get authenticated and subsequently get access to resources
when we know who they are. However, when the application and the
resource access crosses boundaries between enterprises or even
departments within enterprises, the identity that is commonly kept
using Cookies does not travel across those boundaries.

SAML: Identity Providers can return a SAML response with the
identity as it has been established for the SAML Authentication
Request.

OpenSSO is open sourcing of Sun’s Federated Access Manager, developed in a community with 650+ project members, 60 committers of which 10 are core committers. See https://opensso.dev.java.net/ for details on OpenSSO.

Installation of OpenSSO: copy the opensso.war to the auto deployment directory of Glassfish – or one of many other containers. The application is exposed as Sun Federated Access Manager.

It turns out OpenSSO comes with embedded OpenDS for its own configuration purposes. For actual users in the production environment, we can use any LDAP directory implementation.

Installation is followed by configuration. After the configuration information is entered, the authentication services are registered and the OpenSSO Management Console is available. A new user is created – Dilbert Adams as suggested by the audience – and his profile set up. On the Common Tasks pane, we now create a SAML identity provider. The Identity Provider can be published as Service Provider or Fedlet. Note that identity does not necessarily mean username; it could be something like ‘a known student enrolled at University X’.

Briefly, the ‘Fedlet’ is a package that a SAML 2.0 identity provider
can create to quickly federation-enable a small service provider. If
you’re trying to federation-enable a single web application, you need
the Fedlet. See http://blogs.sun.com/raskin/entry/identity_buzz_podcast_the_fedlet for more on the FedLet. As I understand it, the Fedlet can be the login dialog for any application that need authentication against the OpenSSO server.

The article http://blogs.sun.com/steffo/entry/single_sign_on_to_google describes how OpenSSO is used to set up authentication for Google Mail. When this is set up, a user accessing an authentication-requiring-Google service, Google will leverage the configured OpenSSO Identity Provider and either use the identity it already has for the current user or has it bring up a login dialog (for example the fedlet). Well, something like that at least.

Demo shows how to turn the Windows authentication into the login to Google Mail. Well, the demo shows that it works, as well as for SalesForce. The Intranet Portal engages in some serious negotiations with the OpenSSO Server to get hold of the proper authentication token for the eternal SaaS application that is invoked.

Summarizing, OpenSSO sounds interesting. It seems that OpenSSO is an easy way of setting up a SAML based Identity Provider that can easily be leveraged from various application to benefit from a centrally managed identity. I hope to give it some more time this week.