Friday, February 22, 2013

Implementing Multiple Accounts With Single Sign On

One of the things that I came across recently was to design and implement a solution that allows users of an application to have multiple accounts such that the accounts are treated as completely independently in some situations, but grouped together in others. Since that probably doesn't illustrate the problem well enough, here are a couple examples that may help clarify the situation.

Example 1: Let's say we are creating a web based email system along the lines of GMail, YMail, or anything of that nature. Furthermore, let's assume that I am an employee of two organizations (say, as a contractor), and each organization is paying for single use license for me to use this email service. Also, as part of this corporate email service, we want users to be able to customize their accounts (job title, contact phone number, etc.). In essence, from the standpoint of the organizations that are paying for the system, they want me, the contractor, to have an account dedicated to their organization.

Example 2: As is the case with many applications, there are normal users and admins. Continuing with the email service example above, let's say that I also work for the company that is making this software (yes, in this example I'm a very busy person) and have administrative privileges on the site. Do I always want those admin privileges? Should I always have them? Obviously, the answer is no. (Yes, there are other ways to handle this sort of varied levels of privileges, but let's ignore that for now.)

Common Solution: The easy solution (and the one commonly implemented) is for users to have completely different usernames for different accounts. This makes it very easy to distinguish between the multiple roles/jobs that I have. For most applications, this is perfectly adequate as most users only ever have one account.

The trouble, however, with this solution is if many of the users of the system will have multiple accounts. For example, let's say we want to deploy this in a hospital setting to be used by all of the doctors. It is not uncommon for doctors have multiple appointments (they are employees of multiple hospitals) and may have different roles, titles, email addresses, etc. Again, we could make them have multiple accounts, but what about if we want to create a unified inbox (e.g. as is done by many desktop email clients) across all of their accounts from the various hospitals?

Improved Solution: In retrospect, this isn't anything clever, and is something that is relatively easy to implement from the beginning that allows to handle this scenario with ease. Of course, this doesn't mean that a single user cannot create two completely different accounts, but it allows for the potential of joined accounts.

The idea is to not just have a user of the system, but also include profiles for each user. In other words, the user identifies the unique individual, while the profile identifies the unique account that individual has. All details that are common to all profiles (name, gender, certain preference settings, etc.) are stored at the user level, while all the particulars of a particular account are stored at the profile level.

Now, instead of storing user IDs for all of the records (e.g. the user ID associated with an email), we store the profile ID. This way we get the benefit of being able to create, for example, that unified inbox by getting all emails for all profiles for the particular user, but still have the ability to have completely separate "accounts" along the lines of the profiles.

(P.S. If you are wondering, those UML diagrams were created with by

No comments:

Post a Comment