There has been lots of speculation regrading whether OpenID is actually useful and I’ve often asked myself what can OpenID actually do for a company. If you’re interested in what OpenID can do for SSO/trust/webapps, then have a read. If you have no idea what OpenID is and want a quick overview, head over to the Crowd 1.1 Release Notes.
The standard SSO techniques in Crowd are based on cookies. If you’re authenticated, then a cookie token is set on your browser. The browser then sends this cookie for each subsequent request made to the site. SSO is achieved by having a centralized authentication mechanism between all web applications on a host to examine the cookie establish that the user is authenticated.
Enter Crowd: a middle-ware application that provides connectors to applications so that they use the same mechanism for establishing authentication and also provides connectors to different user repositories. As long as all the applications are on the same domain, “seamless” SSO is achieved.
Limitations of the current approach
- “seamless”ness: The current approach isn’t exactly seamless because applications need to be written so that Crowd is used for all user related operations such as logins, authentication checks, groups/roles information. Even though Crowd uses a SOAP API, applications need to use this API and refactor any existing internal implementation of user management to use it. This API isn’t a “standard”.
- cookies: cookie-based SSO schemes are limited to only achieving SSO for applications in the same domain. This rules out the possibility of cross-domain SSO. So say if you’re logged in to company-a.com/jira, you can’t SSO through to company-b.com/confluence.
OpenID provides a mechanism which allows cross-domain authentication. A user enters their OpenID, which provides the endpoint of the authentication server to the web-application requesting authentication. So it doesn’t matter if the web-application and authentication server are different hosts. The neat thing about OpenID is that it is an attempt at a standard – which is having an increasing level of adoption.
What this means for the End-User
- One username: your OpenID is all you need to authenticate with OpenID enabled applications.
- Web-level SSO: once signed in to your OpenID authentication server, you don’t need to individually sign in to each of your OpenID enabled applications.
- Profile Management: simple attributes such as your name, email address, DOB, can be stored on your OpenID authentication server. This allows quick registration to OpenID enabled websites that you have never been to. Users can have the ability to manage multiple profiles. Although many people won’t have the need to be Clark Kent by day and Superman by night, it allows for things like having a full-profile (exposing your email address) and a minimalist profile (may be just a nickname). So as an Atlassian employee you could post a comment on a blog and people will know your OpenID verifies you’re from Atlassian, but spam-bots won’t hunt you down. That same OpenID could be used with a more open profile to login to our extranet for example.
- Decentralised Identity Management: you can choose who hosts your identity. You can even choose to host your own. Or you can take the middle-ground approach and purchase a domain (to use as your OpenID) and delegate OpenID interactions with an existing OpenID authentication server. Basically, this means you as a user can control your identity (not Microsoft, AOL, Verisign, etc).
What this means for Applications
- Single Authentication Mechanism: it’s very easy to use libraries (such as openid4java) to build OpenID clients. The seamlessness of integration is an issue, but no harder than integrating with any other authentication framework. Once OpenID settles to a decent level of standardization, application developers (for thick and thin client based-apps) will be able to rely on OpenID for authentication needs.
- Attribute Exchange: the attributes sent back to the application from the authentication server are not just limited to your name and email address. They could include group and role permissions – so that the applications have a level of user access control. The not-yet-finalized Attribute Exchange allows for custom XML-schema based attributes to be exchanged between the authentication server and applications.
- Trust relationships: it is possible for clients to only trust certain authentication servers and likewise for authentication servers to only service authentication requests to trusted clients. This could be organized in such a way that business partners could allow users from a trusted domain to access another application on a different domain, eg. Atlassian could allows authentications from trusted datacenter authentication server to access our extranet.
- Security: it’s as tight as you want it to be. Enabling SSL over the wire will ensure no one else can eavesdrop on the authentication. Using client-side certs will also allow the server to be sure the remote host is who they claim to be. The main concern with OpenID is phishing attacks and also the fact that breaking into your OpenID account will give people access to your identity (which is nothing new).
- Adoption: the danger of any new up and coming way of doing things is that it’ll turn out to be just a Web x.0 fad. Lots of people have blogged about the increasing number of OpenID enabled sites. Admittedly, a lot of these sites are just a waste of space. However, what’s cool is there are a lot of big players like Microsoft, AOL, Verisign, Sun and Firefox. This may reassure some people that OpenID probably won’t go away anytime soon.
- isAuthenticated() isn’t cheap: checking if a user is authenticated isn’t as cheap. Every authentication request could be a complicated sequence of HTTP POSTs and redirects. In fact all operations which require the authentication server now become costly. The simple way to revive some speed is to cache operations. But should you cache the fact that you are authenticated? And for how long?
- single-sign out: if you do cache the fact that a user is authenticated, you lose single-sign out. Say I’m signed in to my authentication server, and via OpenID I authenticate to a few web applications. If I sign out of any particular web application, then I don’t automatically sign out of any of the other apps (or the authentication server). Also if I sign out of the authentication server, I could still be signed in to the web apps. This is because there’s no way of pushing the fact that a user has signed out via OpenID.
- synchronization of user data: similarly, there is no way for the authentication server to notify applications that a user has just updated their email address on their profile, for example. The web applications must pull data from the OpenID authentication server by specifically requesting it. This could be achieved by polling the authentication server maybe once every few hours.
OpenID is currently a maturing technology with decent potential to become the standard mechanism for web authentication. The adoption for OpenID is really amazing considering current OpenID 2.0 specifications are still in “draft”. Once specs are finalized and libraries become solid, I think we can expect a lot of creative things to be built on top of the lightweight, flexible protocol.