A late-afternoon session at CommunityOne focused on OpenSSO at opensso.org, Sun's open web access management project. At the podium were Sun identity architect Pat Patterson, senior product line manager Daniel Raskin, and product manager Nick Wooler.
Besides the impressive turnout, the many questions raised and the crowd that surrounded the speakers after the session bespoke the high level of interest in OpenSSO. When Daniel asked how many folks in the audience were using OpenSSO in their applications or projects, many hands went up.
Overview
Nick introduced the session as one that shows how OpenSSO establishes the infrastructure for federation. Engineers from the Sun development team were present to help install OpenSSO. Nice gesture!
Federation In Its Latest Form
Federation implies single sign-on (SSO), in which users log in only once to access all the applications within a domain. According to Pat, currently, many enterprises enable SSO across domains, that is, authenticate at the identity provider (IDP) and then access the service provider (SP) site.
A straightforward way to set up SSO in a single enterprise is through cookies, which don't work, however, across company borders. Before companies establish their IDP-SP relationship, a business agreement is mandatory to form a circle of trust.
Pat described a more and more prevalent outsourcing model, whereby enterprises are outsourcing, for example, employee email to Google, and mentioned that a large European company is putting 30,000 employees on Gmail. Separately, employee calendars are being outsourced, too. Nonetheless, the need for authentication is ever-present.
"One platform now applies for different user types and security is a must," added Daniel. As an illustration, Pat revealed that a recent query on a Google calendar searched for people who had input conference-call data into a public calendar: "It was amazing how anyone could then dial in to private conference calls."
The Runtime Scenario
The process of federation, seamless to the user, proceeds like this:
- The user accesses the SP, typically an outsource company like a health-care provider, which redirects the browser with a Security Assertion Markup Language (SAML) request to the IDP.
- The IDP authenticates the user and then creates a SAML response, an XML document with the user's identity, login time, and mechanism, and then sends the response, usually in the form of an encoded URL, to the SP through the browser. Architecturally, that response can be too large for an URL, in which case the IDP would post to the SP a JavaScript form with ample space for user attributes.
- The SP determines whether to grant the user access.
OpenSSO and Sun Federated Access Manager
OpenSSO, which started in 2005, is the open-source version of Sun Java System Access Manager. All the source code is in a public CVS. The to-be-released Sun Federated Access Manager, which is being merged from Access Manager and Federation Manager, is built from the same code. OpenSSO and Federated Access Manager share the GlassFish Project-Sun Java System Application Server model, with OpenSSO as a distribution.
As of today, OpenSSO boasts 660 project members and 60 committers, of whom 10 are external committers, mostly system integrators. Talk about gratifying progress! For more details, see an interview with Pat, From the Trenches at Sun Identity, Part 2: OpenSSO, a Thriving Community.
To download the binaries and a read-only copy of CVS, click Downloads at opensso.org. You must join OpenSSO to file issues and submit patches. Once you have successfully put through a few patches, you're invited to become a committer.
Demo
Pat walked the audience through the steps of deploying an application and configuring OpenSSO:
- Drop the binary--the web archive (WAR) file-on to GlassFish Application Server.
OpenSSO supports eight containers, including Sun Java System Web Server and Tomcat.
- Configure OpenSSO: Specify the administrator password, data store, agent, and so forth.
- Configure OpenSSO for users: Create SAML 2 IDPs and a circle of trust with attribute mappings, such as cn (common name).
- Create a Fedlet, which is code that makes it a breeze to configure an SP.
A Fedlet is a lightweight (8.5-Mbyte) ZIP file that contains a WAR file and a README file.
Afterwards, you can deploy the SAML WAR file on to the SP's system. Pat demo'd how to log in as a user, browse the XML code, log out, and then log back in as an administrator and test SSO in a controlled environment.
With such a federation setup, user credentials stay with the IDP and are not passed on to the SP. The benefit is all the more obvious in case of employee turnovers, which necessitate no data updates at the SP.
Conclusion and Q&As
"OpenSSO is truly open with no secret sauce," Pat emphasized. The project focuses on standards, with SAML 2 as the preferred mechanism for federation even though OpenSSO also supports WS-Federation. "Our core message to you is to use available, off-the-shelf code. Don't design your own model of authenticating users, which is time-consuming and error-prone," he added.
"Be sure to define the access and federation management architecture for applications early in the development cycle," urged Daniel. ̉Not only will you then be well prepared for growth and transitions, your application will also be flexible for mashup updates." So, plan early and plan it right.
Here are a couple of interesting Q&As toward the end of the session:
Q: Why hasn't OpenSSO publicized all the code for J2EE agents?
A: OpenSSO is an ongoing project and the agents are moving from version 2.3 to 3.0. It's all in the works and will be available down the road. Sign up on the mailing list for the latest updates. Also, join the Internet Relay Chat (IRC).
Q: How do I implement fine-grained authorization so that only preauthorized users can access the applications?
A: Use the SDK API. For details, see the article Developing Secure Applications With Sun Java System Access Manager, Part 2: Advanced Authorization.
|
