Authentication: the first victim of the dev-ops divide

Combination Lock

Combination Lock

In almost every IT project I’ve worked on, we wrote an authentication system for the application we were building. User passwords were stored in the application database (encrypted or not). I don’t think that’s good for the users. We should be asking people to remember fewer passwords, not more.

(the exception to to this is .NET, where you get Active Directory almost everywhere)

I can see why:

  • A lot of IT professionals couldn’t tell you the difference between authorization and authentication.
  • Integrating your shiny new project with an existing authentication system makes it harder to test.
  • Usability can unfortunately take a back seat to delivery

There upsides to using a directory service instead of writing your own: You don’t get to make elementary security mistakes in storing user passwords, and you end up writing less dull code.

Directory systems can be seen as squarely on an admin’s patch. That’s the main reason why. I truly believe that we deliver better systems when admins and developers collaborate.

Update: hopefully the rise of OpenID, Google Friend Connect and Facebook connect will make us think differently. As Bryan points out below, we should be able to plug and play many authentication systems into our apps. Thanks to Dan for the editing.

image courtesy of ladydragonflycc

Tagged

3 thoughts on “Authentication: the first victim of the dev-ops divide

  1. John Arundel says:

    When I worked for ACME Enterprise Hosting Co, they had Kerberos everywhere which worked quite well, combined with RSA two-factor authentication.

    However, when you’re writing systems integration glue code and Puppet manifests and so on, it seems inevitable that you’re going to have to store passwords somewhere, because lots of applications and bespoke scripts don’t support directory services. I wonder what the best practice for dealing with such things is.

  2. bryanl says:

    It shouldn’t matter what the backend for for AAA system is. You *should* have a good enough API in your app where you can switch systems if need be. Every system wil be different, and even the same systems in different environments will be different, so lets not just proclaim one as the *best*.

  3. Banos says:

    Makes me feel advanced. A couple of years ago I helped implement a Chordiant/J2EE/WebSphere6.1/AIX solution using Kerberos to Authenticate/Authorise against a Windows 2003 AD domain using SSO in a retail bank. If it’s achievable there, believe me, it’s achieveable anywhere šŸ™‚ Windows has been doing Kerberos since 2000, whats your excuse?

Comments are closed.

%d bloggers like this: