Gallery

One sign-on to rule them all

Posted on 11 Feb 2012 at 02:17

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

A couple of months back, I wrote about implementing a single sign-on (SSO) system using an LDAP directory service as a central repository for usernames and passwords. Most Unix systems work out of the box with LDAP, and running Samba on a Linux system can include your Windows PCs too. The crucial extra was the Gosa web front-end, which makes it possible for your users to log in to all your Unix, Windows PCs and Macs using the same username and password - for everything except accessing websites. So what's the problem with implementing single sign-on for websites?

Before I can answer that, let's establish what we mean by "signing on to a website", because for most sites you don't need to. If you have a web application that requires a username and password, that might be supported by the LDAP directory. For example, here at Wide Area we use the web-based ticketing system Request Tracker (www.bestpractical.com/rt), but our single sign-on usernames and passwords work because it can talk directly to our LDAP servers. However, some web servers use their own authentication method - HTTP authentication to be precise - which is what's happening whenever you connect to a website and see a login box appear in your browser. The main reason for applying this type of security is that you don't want your site available to everyone on the web: for example, it might be a test site, or it might contain content that's only for internal consumption. We run a lot of sites like this, so we needed to find a way to extend our SSO to work with HTTP authentication. That would then let us manage all our users, both internal and external, through one system.

To understand why that's a problem you need to understand how HTTP authentication works. If you've ever configured a web server - whether Apache or IIS - you've probably come across HTTP authentication, which is quite simple in concept. To protect a site with a username and password under Apache you'd say something like this in your configuration file:

AuthName "My Private Development Site"AuthType BasicAuthUserFile conf/my_password_filerequire valid-user

You'd then use the program htpasswd to create a username and password. Whenever people connect to the site, or maybe to some part of it, they'll have to provide the username and a password. There are two ways in which this authentication scheme can be set up - basic authentication (as in the example) and digest authentication - and both schemes work in a similar way; with each page request the username and password get sent to the server, which decides whether they're okay. If they're not or are missing then when the server sends the page back, it also sends a special header that prompts the web browser to pop up the dialog for the user to enter username and password. Then the browser attempts to reload the page with the provided username and password.

The key point to understand is that username and password are sent with every request, and in the case of basic authentication they're not encrypted. Just to rub it in, every single time you read a page on a website that uses basic authentication, your username and password get sent with the request in unencrypted form. They're not quite in plaintext - they're encoded, but very easy to decode. You can make basic HTTP authentication more secure by using a secure HTTPS server where everything is encrypted, but that requires more setup, and to be implemented properly you might have to buy digital certificates for all your servers, which is expensive.