(Warning: if you’re not an IT nerd this blog post may make rather dry reading)
Identity Management is a pretty big topic these days – some might say it’s the new IT buzzword. From an organisational perspective it is highly desirable for users to have to remember as few passwords as possible, as this reduces the need to them to write them down. Centralised management and provisioning of user rights also provides more certainty and reduces overheads.
With the use of authentication services such as Facebook Connect, Windows Live ID, and Google accounts becoming more widespread on the web, we’re starting to see the web trending away from the “one identity per service” model towards fewer identity providers proving authentication services for other sites.
Recently I’ve been asked to investigate SAML-base single sign on solutions, so I’ve collected some of my thoughts in this blog post. Please note that this is based on my own research and should not be considered authoritative in any way!
The Web Perspective
One of the problems with the web today is the sheer number of usernames and passwords that people have to remember. You need to create an account for almost every online service you use, as sites need access to certain information about you in order to provide a useful service, and they need a way to ensure that you keep the same identity on the site the next time you visit. E-Commerce is a very significant example of an area where this is needed as you can’t accept payments without a fair bit of information.
Microsoft tried to solve the problem with their passport service back in 1999 (actually it may have been even earlier). The idea was that your “passport” could be used to sign in to other passport-enabled sites, and could contain enough information to allow ecommerce transactions to take place without having to enter your details every time. The problem, in typical Microsoft fashion, was that this service was a centralised Microsoft service – they wanted to hold all the information. It should have come as no surprise then that adoption was rather limited, and fortunately as a result the current Windows Live ID service is a different beast.
What was needed was an open model not tied to a particular service, and that model is OpenID. All the aforementioned services support (or have committed to supporting) OpenID, which is in layman’s terms an open way of logging in to one site using credentials from another. So what this means is that theoretically you could use your Facebook account to login to any site that supports logging in with OpenID.
“Brilliant! Now I can use one identity for everything!”
There’s a small problem though.
The major Identity Providers (holders of your information) all want to be providers, but they don’t want to be consumers (i.e. accept logins from other sites). So while you can log on to Gmail with your Google ID, and digg.com with your Facebook ID, you can’t login to Facebook with your Google ID or Gmail with your Windows Live ID. We’re a long way from the OpenID dream of being able to sign in to any service with any ID, and there’s little stopping it but branding and marketing. But we are at least moving towards needing fewer logins, as smaller sites tend to be happy to accept logins from the major providers, and OpenID adoption is growing so it’s not all bad.
Organisational Needs
Large corporate networks mainly want a single place to manage user access to company resources. They also generally want their users to have as few passwords to remember as possible, and to have to enter their passwords only when really necessary. LDAP solves the first problem by providing that central repository of user information which services can outsource their authentication to, and most applications that would be used on a large network can do this. It doesn’t solve the second problem however, as the user still has to type their password for each service. But at least it’s the same password.
OpenID works well for the web where the services are available to anyone with an email address. Basically they don’t care who the user is as long as they’re the same person. However the Identity Management needs of organisations are somewhat different. You generally don’t want to grant any old OpenID access to a company network, however you may want to grant employees or members of other organisations access to certain resources. What is needed therefore is a framework which refers to a centralised directory service, provides single sign on, and can provide access to users of other trusted organisations.
The solution to this is “Security Assertion Markup Language”, or SAML. SAML introduces the concepts of an Identity Provider (provider of assertions) and Service Provider (consumer of assertions). What happens in a SAML authentication session is that the user’s web browser tries to access the app, gets redirected to the login page of their Identity Provider, which returns a token to the browser upon login. The browser then forwards the token to the service provider which verifies the request and grants access. The best diagram I’ve seen which explains this process is on Google’s SAML reference implementatin page for Google Apps.
The Identity Provider part (IDP) is the easy bit. The software is available (Shibboleth and SimpleSAMLphp are two examples) and once you get your head around the concepts and set it up correctly you can point it at a directory service and go. The problem currently is at the Service Provider (SP) end (the part labelled ACS in Google’s diagram), as few services actually support SAML. Google Apps is one of the first notable examples, and I’m hoping that adoption of Google apps will solve the chicken and egg problem by driving adoption of SAML and providing the install base for other software developers to jump on board and add SAML to their services.
Software such as Novell Access Manager (which supports SAML) attempts to get around the problem by effectively acting as a gateway to the service, and blocking access to unauthenticated users. That way the service doesn’t have to support SAML and you can only get to the service if you have permission, however I don’t know how the target web service is supposed to handle authentication if it needs to know who you are (for example to edit a wiki). I think the logical way would be for it to insert login credentials in the HTTP request, but hopefully this will become apparent when I start playing with it.
Conclusion
OpenID isn’t perfect, and like any username/password scheme it is particularly vulnerable to phishing attacks (only the stakes are higher as a successful attack results in access to multiple sites). The battle between the major providers to be the provider of your identity also threatens to reduce the benefits. But regardless of the risks it seems like a step forward for the web.
For organisations that need single sign on and a federated trust model, SAML seems to be the way to go. But it requires much broader adoption by software developers and service providers before it will truly eliminate multiple logons in organisations. Heck, many don’t even support LDAP yet.
