Wellfire Interactive // Expertise for established Django SaaS applications

Table for two: designing multiple user accounts

Users and accounts needn't be confused. Let your customers work together by supporting multiple users per account.

When you use your Facebook account you expect to log in as you and only you. The account is itself an identifier, of course, as it represents just one person. But when you create an account for a service provider, all too often what you want to do is create an account which other people can have access to. A Facebook page is one example, a hosting account another. Sure the former requires that individual account first, but the result is something different.

Sites where accounts and subscriptions are separated from identities are just not the norm.

Account management best practices

It boils down to this:

Users and accounts should not be coupled together.

That is, management of an account and the resources for that account should not be coupled to one username and one password only. When this happens, what you’re asking is for people to share passwords. This is double plus bad.

Unless an account truly represents an individual human, like a social network profile, accounts should decoupled from people’s access to the site. It’s the natural thing to think of individuals as the core component of a site, but while people are using the site, they aren’t the resource. For a car, you shouldn’t need the driver, just access to the car. You can share keys, but a family will probably just provide each driver with their own key. Swapping that one would be annoying as all get up. So don’t make everyone use that one login.

The rest should be old hat, like not sending passwords, even temporary passwords, over email (Mailman and WordPress, I’m looking at you).

API key management best practices

Similarly, if your product exposes an API, limiting users to one key foists on them an opinion about how and where they should access your API. It now means each environment needs access to the same key, and now this one key needs to be shared.

Rackspace API keys

If you already have an API Access Key and generate a new one, your current key will become obsolete and will be replaced by the new one.

Does the key used for uploading files really need to also provide rights to create and destroy server instances?

Okay, rather than look at how not to do this, let’s look at a good example of how to do this.

HipChat does a really good job of this. Apparently aside from being a kick ass company, Atlassian also understands that their users might have diverse uses for their API keys.

HipChat API keys

In this shot from the HipChat account management panel we’ve got multiple keys and some configuration for each.

There are four good practices for API keys and account access that we can pull from this:

  1. An accessible account should be able to have 1 + n keys
  2. API keys should be disposable. It should be possible not just to reset a master authentication key, but to dispose of one key without disrupting any others.
  3. API keys should be nameable. At the very least at the level of an admin control panel, the account manager should be able to label the various keys. It’s good to know what environment each is used in.
  4. API keys should be able to provide different levels of access. Whether it’s account administration, notifications, or read vs. write, allow users to dictate what keys can do.

Increase the bus factor

Another good rule of thumb might be this: if your account management policies enforce an arbitrarily low bus factor on your users, it’s not flexible enough. Let users decided whether they want to share passwords and give them the ability to manage their accounts comfortably and securely.