As we’ve been expanding the scope of the services offered through the various Ocean Informatics web sites, the issue of authentication has come up more than once. When a user connects to one of our web applications claiming to be Mason Kortz, how do we know he really is Mason Kortz? Answer: we put the user to the test by requiring a password that only Mason Kortz would know.

The first issue we dealt with was how to securely transmit passwords over the Internet. Sending a password from your computer to a server is like writing it down on a piece of paper and passing it through many hands to another person. If the wrong person grabs it and looks at it along the way, it’s not very secure any more. That’s why last month we enabled SSL on our Ocean Informatics sites. Sending a password over an encrypted connection, like the ones formed with SSL, is like writing it down on a piece of paper and passing it through a cast-iron pipe to another person - significantly more secure.

So, with a safe way for users to submit their credentials, the next issue is to create and maintain a list of names and passwords to check the submitted information against. There are currently two lists of users in the OI environment that could be considered authoritative - the system users for iOcean and the personnel directory. An ideal authentication system would use one of these lists, and avoid the need to maintain a third, independent list.

Our first take on authentication was to use the Apache mod_auth module. Mod_auth allows you to secure your web space on a per-directory basis, using .htaccess files. A simple command line tool, htpasswd, is provided to maintain the text files that form mod_auth’s backend. When a user authenticates through mod_auth, their username is available to PHP through the $_SERVER superglobal array, so web apps can make use of this form of authentication. Mod_auth does have its downsides. It slows down a bit with large numbers of users, and the user/password list it uses stands completely alone, so it would have to be maintained independently of the server users and the personnel directory.

These issues brought us to the next possibility - creating our own authentication app using PHP over MySQL. Specifically, the login app would draw on the personnel database for user/password matching, and then set a cookie that could be accessed by all other web apps, effectively creating a single sign-on service for the OI web space. This solution would have a more robust backend than mod_auth, and would tie the login information to the contact information in the personnel directory. Again, though, there are downsides. Cookies are stored locally on the user’s computer and are easily read, so keeping our sites secure against ’spoof’ cookies would mean devising some security measures of our own. Also, the personnel directory is still divorced from the server users list - so although this solution provides single sign-on for the OI web space, it does not extend to the rest of the OI infrastructure.

This brings us to LDAP/Kerberos, which IOD is moving towards for network authentication. Whenever you sign on to a network resource - which can mean logging in to a computer, connecting to a shared drive, or accessing a secured webpage - your username and password are checked via the Kerberos server against the LDAP database. If they match, you are given a Kerberos ticket, verifying that you are indeed the user you claim to be. This ticket is good for all other (Kerberized) network resources as well, so you have strong single sign-on capabilities. Also, the LDAP database can contain more than just a username and password - it has a customizable schema, and by default supports extensive contact information. This would allow us to maintain one user list that acted as both the authentication database and the personnel directory. Of course, there are drawbacks. Setting up an LDAP server is not a quick task - at the very least it is on par with building our own authentication system. Furthermore, LDAP isn’t a familiar technology, so even once the server is running there will be learning curve as we figure out how to work with the schema files and customize the server to our needs.