OpenID in the world of Federated Identity

In my last post, I promised that I would have a look into OpenID as an alternative means of setting up and Identity Federation. While this is a small adventure away from my usual home among the more established specs, OpenID is not so distant that I haven’t already been sucked in by the hype and made use of it already. So is OpenID a real alternative that can be used in the enterprise as a means of achieving SSO and of provisioning user data across a federation in a secure manner?

The answer to this question is a little convoluted, so I’ll start out by quoting Andy Dale, who says: “In my bitchier moments I have been heard to say… “OpenID; brought to you by people who didn’t want to read the SAML spec””. And in many ways I agree with him. OpenID has burst onto the internet like a wild horse, and is rapidly gaining popularity. Certainly, it has wide adoption as everyone from Google to Facebook attempts to fight out the battle to become worldwide identity silos. But realistically, OpenID is a relatively immature approach to identity management and as such, many of its specifications are under revision. As Andy points out, it is likely that over time the OpenID spec will evolve into something that is fully SAML compliant.

Part of OpenID’s success has been that it is built around an “easy-to-setup, easy-to-use” framework. From an end-user perspective it is ridiculously easy to set up an OpenID URI and get busy logging onto any site that accepts OpenID as a means to authenticate. Administrators and developers find it exceedingly simple to build their own OpenID systems, and certainly there are a number of ready-to-use systems already out there, that can be fired up on any webserver and be home to your OpenID users.

Of course, there are a number of downsides to all of this promiscuity. As Paul Madsen, one of the Liberty Alliance architects, has pointed out on his blog, as Service Providers require more security in their transactions with an IdP, they will become more discerning or selective in their choice of IdP. This means that to login to your favourite blog, it is unlikely that there will be too much selectivity over your choice of IdP. However, your bank is more likely to be deeply concerned about which IdP you make use of, and will limit your selection to those that it has approved.

And this is largely where the split between OpenID and SAML lies. OpenID provides a quick and easy method of achieving SSO. SAML is more complicated, but it is built around a robust security model that can be trusted by large enterprises.

In more simplistic terms, SAML is more applicable for handling identities within organizations that need to maintain control over user data, and which have security concerns. In essence, the organization needs to be able to determine who it trusts within its identity framework. SAML makes more sense in these environments, especially when coupled with other specifications such as those provided by Liberty Alliance, as it facilitates secure data transactions beyond the scope of SSO.

OpenID is more applicable to users outside of an organization who wish to achieve SSO within less security specific environments. These users want to be able to choose their own Identity Providers and have more control over their own data. Essentially, as Stefan Brands writes in his scorching critique of OpenID at The Identity Corner: “OpenID was designed as a lightweight solution for “trivial” use cases in identity management: its primary goal is to enable Internet surfers to replace self-generated usernames and passwords by a single login credential, without needing more than their browser.”

This is not to say that OpenID does not have a space in the world of Federated Identity, only that it caters to a different market. Perhaps it is best to think of OpenID in exactly the terms that the group behind it presents the technology: OpenID is a lightweight method of identifying individuals that uses the same technology framework that is used to identify websites.

More about Federated Identity

In my last post about federated identity, I mentioned that one of the biggest problems facing any implementation of an identity federation is that all of the participants need to be using the same standards and protocols to achieve federation. Unfortunately, as time has progressed a number of different standards have emerged. This is not a big issue if you’re starting out from scratch and all of the applications that are being developed are being built in-house. As long as all of the participants within the federation can agree on a standard, integration issues are unlikely to arise. However, this imposes serious limitations on future scalability. It denies members the opportunity of integrating with applications developed around a separate standard. It also means that all entities, wishing to join the federation in the future, will have to conform to the same standard. With this in mind, you either want to choose a standard that is widely used, or you need a means to integrate across standards. So what are your options?

To start out, it is worth mentioning that as federated identity matures as a concept, many applications are capable of supporting the plethora of standards that have already emerged. Furthermore, there is already a convergence trend that is emerging where standards are slowly being redefined to be more ineroperable with each other. And this is largely down to the work of the OASIS group, with the SAML specifications; and Liberty Alliance, who have developed the ID-FF specifications along with ID-WSF. These separate standards have become increasingly intertwined with each other and the distinctions between them are slowly fading into history.

On the other hand, WS-Federation, a standard originally backed by Microsoft, still stands apart and provides its own specifications on how federation should be achieved. So, in effect, the choices between standards is now really about choosing between the SAML/Liberty specifications or the WS-Federation specification. Either way, more and more applications are trying to overcome these splits by simply offering support for all of the options out there.

Certainly, the Symlabs Federated Identity Suite has catered to support all of the major standards so that integration with new federation members and their associated web applications no longer requires that you come to terms with the differences between the specifications. But Symlabs is not alone in this move, and other vendors such as Ping Identity with their PingFederate product are also focussed on providing these sorts of integration options.

So, when it comes down to developing your federation infrastructure, you have a number of options available to you:

• Develop a proprietary solution from scratch, ignoring all of the standards and specifications that have already been created. This clearly has a load of pitfalls and your integration options are going to be few and far between.
• Use a set of open source libraries built around one of the standards to develop a federation architecture from the ground up. Not only is this likely to be very time consuming, but you are likely to find that many of the open source options are still heavily under development and you’re going to lack much of the functionality that is available in the specifications. Furthermore, you’re going to have to work out which specification you wish to support.
• Use a standards-based Federation suite to implement your core architecture. There are a number of commercially available suites that provide you with everything that you need to build a standards compliant federation that supports all of the major standards. Most of these suites will provide a range of functionality that can be used right out of the box.

Okay. So, it sounds like I’m trying to sell Federation Suites. Yes, and no. In relative terms, Identity Federation is still very young. There are a lot of options out there that make it very difficult to move forward confidently. So, in many ways, making use of a commercially available suite is not a bad option. And from my perspective each of the major players in this market have different things to offer. I know that Symlabs, with its involvement with Liberty Alliance, has a strong focus on implementing a wide range of built-in functionality by taking advantage of the Liberty WSF specifications. Other vendors may cut back on functionality to focus on usability. It is well worth researching any product thoroughly before committing your entire infrastructure to it.

But for the little-guy out there, forking out large amounts of cash to simply achieve SSO might not be a possibility. Is OpenID an option? How does it differ from the other specifications? Can I get the benefits of a true federation using OpenID? These are questions worth exploring. The sudden clamour around OpenID is bound to bring change to the identity management market, and it cannot be ignored. I will try to look at OpenID in more depth in my next post.