Gallery

One sign-on to rule them all

Posted on 18 Jun 2009 at 11:12

What's the problem with implementing single sign-on for websites? Communications professional Simon Brock has the answer.

So if basic authentication is insecure, what about digest authentication? In this, setup username and password are encrypted on the client using information from the server, then sent to the server as a "digest". The server carries out the same digest calculation as the client did, and if it gets the same result then that user is authenticated. This ought to work well but in practice it's almost fatally flawed, because the password digest algorithm isn't the same as used by any other system, so you either have to store the password in plaintext on the server, or else in encrypted form specific to this authentication mechanism. You can do that if you're running your own authentication for the web server, but if you share usernames and passwords with another system it won't work, and that's exactly what we're trying to achieve.

Let's consider the well-known Apache web server, which supports basic and digest authentication. Usernames and passwords are stored on the server in files maintained by the htpasswd program, and if you want to use a centralised LDAP directory server you can do that for basic authentication, but not for the more secure digest authentication - if you don't believe me look at page http://httpd.apache.org/docs/2.2/howto/auth.html in the manual. So, if you use basic authentication on a non-encrypted connection against an LDAP server, anyone who can read packets going between you and your server will find your username and password for all your systems, which is a bad thing.

Towards web single sign-on

So what's the solution? We've seen a hint of one in the web application I mentioned earlier, Request Tracker. That system authenticates against an LDAP server to decide whether someone is allowed access, then employs a cookie to maintain that access right. In principle there's still a problem, because the initial login will be via an unencrypted connection. For a full solution we need some method of logging in securely, in addition to a way of setting a cookie that can be checked.

As we'll see there are a number of systems that implement secure SSO, but I need to explain the scheme in more detail before looking at them. Assume you have two websites you want to protect by username and password, and let's call them www1 and www2, which are normal, non-secure HTTP servers. You also need to set up a secure HTTPS server, call it wwws, which is where your users login to access www1 and www2. Now let's consider what happens when someone accesses www1. They type its URL into their browser and connect to www1, which decides it doesn't know them and so redirects them to wwws. The user enters their username and password into a form on wwws that authenticates them against some username system, which might be LDAP-based. Once they're authenticated, wwws sets a cookie and then redirects the user back to www1 with the addition of an instruction to set a cookie containing an authentication token, and from now on every request to www1 will contain that authentication cookie. The web server on www1 will need to validate that cookie against wwws regularly to check that all is still okay.

Our user is now authenticated against www1 and wwws, and if they go to www2 they'll be redirected to wwws. At that point wwws will probably say this user is already authenticated and redirect them back to www2 with the same authentication token, but there's also the option to revalidate that user before allowing them access to www2 (which isn't mandatory).