HOWTO: Increase Your Drupal Security with OpenID

As a matter of best practices with privileged user account passwords, it is important to avoid using the same password for multiple sites. The reasons for this should be pretty clear, but when you are working in a collaborative environment with multiple different sites this is easier said than done. It is really hard to remember many different complex passwords and to share them (for User 1) across your development team. An encrypted "password safe" file can be one solution, but the problems to this kind of approach should be obvious.

A better solution, that we use at Chapter Three, is to setup our own Open ID server to create our own OpenID accounts and then use Drupal's OpenID support to credential ourselves into Drupal. This allows us to easily grant each of our developers access to the User 1 account (or their own admin account) without requiring that they share (or even know) the standard Drupal User 1 password. The use of OpenID has other benefits including being able to easily use SSL authentication, globally change a compromised password, and being able to quickly remove access from developers at the end of the project without having to update everyone with new User 1 credentials.

To get this working you first need to locate and install an OpenID server package to your development server. We use Community ID, but any mature package should do just fine. There is a development version of a Drupal package as well (http://drupal.org/project/openid_provider). Be aware there is a current bug with the Drupal's OpenID module that makes it sensitive to the HTML source positioning of the "rel" attribute on the OpenID provider definition. For some OpenID implementations (including Community ID) Drupal requires a patch to Drupal or a modification to the output of the OpenID server to change the ordering to be Drupal approved (we opted for the later). For extra points, you can configure a wildcard ServerAlias rule with Apache (ex: ServerAlias *.id.chapterthree.com) to allow certain OpenID servers to create cool subdomain IDs (ex: matt.id.chapterthree.com instead of id.chapterthree.com/identity/matt).

Afterwards, on each Drupal site you want to use your new credential with you need to enable the OpenID module (its in contrib in 5.x and core in 6.x) and then enable your OpenID for each account (with the OpenID Identities Tab on the user edit page, see blow) you want to use your new OpenID account with. The User Login block will now have a neat link to login with OpenID (instead of the standard Drupal login) and you can throw away your password file.