January 10, 2004

Authentication

A few days ago I pointed to Phil Windley's mention of a new web-based authentication system for the state of Utah. As I mentioned then, I think these identification and authorization systems play a key role in any organization's information management strategy. I'm going to flesh the concepts out a bit more here.

In short, an authentication system provides a single username and password for users that can be used in multiple places. The advantages are many:


  • Improved usability. Users will likely have an easier time using the system as a result of providing a single, consistent interface and a single username and password.

  • Improved security. We all have way to many passwords. To cope, we re-use passwords, make them easy to remember, or write them down (post-it on the monitor). None of these methods makes for high security. By using a single sign-on for multiple applications, we can help improve security across the entire system. (Tog talks more about the passwords, usability, and security.) Security also improves because there are simply fewer systems that can be attacked. Efforts can be put into properly security the central system rather than trying to secure dozens of similar authentication systems.

  • Decreased development time. Developers will no longer have to write and re-write the code for authentication and user management, as these functions can be taken over by the central authentication system.

  • Possibility of user data being interoperable. Uniquely identifying a user can be quite the pain, but with a single system in place, multiple applications can use the same unique identifier. If these systems should need to share data, it becomes much easier.

The key disadvantage to these systems is that they become a single point of failure for the organization's IT systems. If the authentication system goes down, or is compromised, every system that relies on it is now in trouble.

Most of my experience with these systems comes as a user. The University of Washington, where I attended graduate school, has a very nice system. The UW NetID is used for a wide variety of services, from email to employment records (full list here). They even used it to protect resources posted on course websites. The system allowed them to tie together all sorts of disparate systems into a useful portal. In an environment like a university, often each department and group is off doing their own thing. There are probably hundreds of different systems, including commercial, open source, and homegrown systems, running on the campus. By tying everything to a central authentication system, it provides the illusion of a unified system to the users while continuing to allow freedom for the systems.

My other experience, as a developer, is at a much smaller scale. I've built a number of web-based systems for a local school district. Rather than duplicating authentication systems, we decided to tie into the district's Active Directory installation (using LDAP calls). Because the user management parts of the site are already taken care of, we can add new systems in less time and money than it would take to build stand-alone systems. Elsewhere, I've also rigged up a much simpler authentication system that ties into the organization's email system. A POP request verifies if the username and password match on the system, then the user gains access to the protected parts of the intranet. By tying into an existing system, we were able to bring this online very quickly and easily.

Phil Windley has talked about the IT Hierarchy of Needs. The third tier from the bottom (following Base Infrastructure and Storage Management) is Identity Management. Everything I've been talking about so far falls into the this category. I'd imagine that lots of organizations are still struggling to work their way up the hierarchy to this level.