Infrastructure Anti-pattern: Death by a Thousand Passwords


December 20, 2010 By Tim O'Brien

I’ve had the opportunity to see many development environments: from the mature organization with tens of thousands of developers that can afford to spend millions on dedicated infrastructure teams, to the three person start-up lacking something as simple as source control.  This series of posts discusses some of the common anti-patterns in development infrastructure that are relevant regardless of team size or approach.   It also provides some hints for how to avoid these problems.

Problem/Anti-pattern: Too Many Logins

No matter how mature your process is, I’ve always found credentials to be especially difficult for a new hire.   It takes days, and then, even when you think you’ve created all of the necessary passwords, there are those other systems that jump up from out of nowhere.

“Do you have a login for Subversion?  No.  Talk to Tom about that?   How about JIRA?  I’m not sure who setup JIRA, let me check on that.   Ok, we have this VPN, and you are going to need to get those credentials in order to check your email which, unfortunately, is a whole different set of passwords.”

The first few days of employment are meeting people, downloading Gigabytes of software, and remembering an encyclopedia of passwords. Some of these password might be managed by HR, others are managed by your Technology department, but this post focuses on those credentials that affect development infrastructure.  If your development infrastructure is mature, your organization might solve this by consolidating authorization and access control information on an LDAP server or Atlassian’s Crowd.  If you don’t use one of these products, then you are dealing with an expanding constellation of moving parts: JIRA, Subversion, GitHub, Basecamp, Bugzilla, Confluence, Twiki, Matrix, CruiseControl, etc.

Complicating matters further is the fact that some enterprises are branching out into the world of hosted or distribute development infrastructure.   If you are working at a business that is experimenting with services like GitHub, Basecamp, or a hosted Atlassian stack, you’ll understand that this complicates things.   If you’ve already standardized on LDAP or Crowd, many of these hosted services do not have any provision for tunneling back into your VPN and authenticating against an internally managed authorization and access control server.

First Step: Use LDAP or Crowd

The first step is easy, use LDAP or Crowd.   Consolidate all of your credentials and select development infrastructure (like Sonatype Matrix and Sonatype Nexus) that can be easily integrated with these services.  Sonatype used to use OpenLDAP to manage this issue, but we switched to Atlassian’s Crowd server as it offered a cleaner interface.   If it takes more than one hand to count the number of developers in your group, it is probably time to invest in a similar solution.

Second Step: Use a Password Wallet

How do you deal with hosted, distributed infrastructure?   What if you are working on an open core product when portions of the system are stored on external source control systems?   What if you are using GitHub for some components?     The answer here is that there really is no way to get to a single password for everything.   The reality of today’s development infrastructure is that not everything can talk to your LDAP or Crowd server, it just isn’t realistic.  In these cases you will want your developers to use a password wallet.

Sonatype Professional’s Developer Onboarding tool provides just this structure to consolidate all of these credentials in a Security Realm.    When a Developer materializes an Eclipse workspace using Developer Onboarding, Sonatype’s Installer asks for all of the credentials and passwords up-front and stores these credentials in secured storage.   This serves a few purposes.

First, we ask for the credentials up front.  You can’t complete a materialization unless you can connect to the necessary resources.  This prevents a developer from starting a process and realizing half way through that they don’t have the appropriate access.

Second, we store this information in Eclipse in secured storage and we protect it with a password.   Sonatype Developer Onboarding product knows how to access this information and every time it needs to access secured storage to retrieve a password it will prompt you for your storage password.

This is the same sort of functionality that you can get through a product like PasswordWallet or 1Password.    Sonatype has taken the idea of a password wallet and integrated it into the development environment.