Multi-tenant User Model

Question

In a multitenant system that hosts multiple organizations and applications, where an organization may use several applications hosted on the system, should my user and role model be such that a single user or role can exist across multiple applications and organizations? Or should I limit a user entity to a single organization/application pair and then define some overarching model to tie those user entities together?

That is:

• John Doe is a person

• He wants to use ApplicationA and ApplicationB

• He works for two different companies (just bear with me), OrganizationA and OrganizationB

Should the user model be:

1. johndoe@someuniquesuffix is his unique user name. This gives him access to both applications for both organizations.

2. johndoe@applicationa@organizationa is his username for ApplicationA at OrganizationA. johndoe@applicationb@organizationa is his username for ApplicationB at OrganizationA...and the same for OrganizationB. Then have some "master" list that says that all 4 user accounts for the apps/orgs correspond to the same actual "person", John Doe?

The same scenario(s) described above applies to how I will design my Role schema.

Thanks for any asistance!

Answer 1

IMO, you should limit each set of credentials to an organization. Further, you should enable the ability for each application to restrict what users within that organization can do with each application. I.e., each application should manage its own authorization roles. You need some means to handle the scenario where Joe leaves Organization A but continues to work for Organization B.

Answer 2

Personally I think that keeping track that John Doe is one person that works both at Organization A and at Organization B complicates things significantly, without adding much value to the most cases. Unless you have a clear business reason to understand in your model that A's John Doe is the same as B's John Doe, I'd steer away from it. Maintaining your user database across all orgs, having to deal with unique names across orgs ('What do you mean there is already a John Doe? that's not me!') and having the UI model this (eg. asking the user at login 'do you want to work on A's data today or on B's data?) just adds significant complications.

The one drawback of my recommendation is that if you use a 3rd party authenticator like OpenID or OAuth then a person that has multiple tenants has to log in with different IDs. Eg. I log in with my google openId I end up on A's data, but to work on B's I need to use my Twitter account, because my Google id is already tied to A and only A.