We currently have a requirement to build a multi-tenant application that has cross-tenant users. That is the business data is separated by tenant but users can belong to multiple tenants and should have access to all of the data for each of their tenants. My question is does this even make sense? And if so, how can we handle login for this scenario using OpenID Connect? When I've done multi-tenancy using OpenID Connect in the past, the tenantId has been part of the login. The given requirement complicates things significantly. Should I push back? The reason for the requirement is primarily to prevent users belonging to multiple tenants from having to have multiple logins. Thoughts?
Yes this can make sense, for example in combination with SSO, but it weakens the independence of the tenants.
In principle, in a multi-tenant architecture, you want each tenant to be independent of the others, as-if it would be separate system. This means that each tenant should have its own user management.
However, some users could have to work on several tenants. In my company for example we operate a multi-tenant system in which a couple of system administrators and auditors need access to several tenants. But I can also imagine shared services where the same users manage operations for different legal entities.
The natural multi-tenant scenario for this, would be to keep a strict separation between tenants. The user needs to chose the tenant at login, and you would have to duplicate the relevant accounts. This is cumbersome, but is perfectly in line with the multi-tenant objectives and works very well... until you want to implement some single sign on.
With SSO you could still ask your user to first chose the tenant, and then use the SSO credentials in the right tenant. But for 99% of the user, this would require an extra choice of the sole tenant in which they are registered, whereas SSO is expected to get a smooth seamless access, avoiding any unnecessary steps when connecting to the system. In other words, you could separate user management per tenant, but this would not fit the user experience that you want to give with SSO.
Therefore, it could make sense to have a global management of user accounts. In this way, you could connect to the multi-tenant with your SSO credential, and the system would ask you for the tenant to be used, if and only if you have credential in several tenants.
In this case your data model would separate:
- the management of user accounts, restricted to the bare minimum (e.g. user id + name) that is cross tenant,
- tenant-specific user data (e.g. title, contact detail) and credential (i.e. authorisations)
In this way, you still are in line with multitenancy (except for the unique account identification) and allow to manage at tenant level the elements required to ensure operational control by the entity in charge of the tenant.
I agree with Robert H. that there is an overarching problem here with terminology. Your customer is not using the terminology consistently or correctly, so any requirements discussions using that terminology will be problematic. Steer away from it.
Instead, talk about use cases. The requirement could potentially be restated in plain terms as follows:
As a user, I need to be able to access all of my tenant-specific web sites without entering my password more than once.
If that is the entire breadth of the requirement, it should not be terribly difficult to fulfill, and there are standards that already support it. After all, you can log into multiple web sites using Facebook or Google, without entering your password more than once, and those isolated web sites are at least as separated as your tenants are. If you think of it that way, the problem should be trivial.
- Modify the web site to include a widget that allows the user to switch tenants, e.g. on the top right of the header.
- The widget simply redirects to the default page of the specified tenant
- The tenant-specific web site checks if the user already has a tenant-specific token. If it doesn't, it redirect to the authorization server.
- The authorization server will know if the user is already logged in. If they aren't, it'll render the required page to enter a user name or password. If they are, it may have to render a page asking the user to grant permission to access the tenant (at least on the first visit).
- The authorization server redirects back to the tenant-specific web site, with a token appropriate for accessing it (e.g. with a claim for the tenant).
- The tenant-specific server inspects the token to determine the user's identity and checks for the appropriate claim.
- Users would continue to have separate records, one for each tenant, including distinct profile information. This is not unlike the Stack Exchange sites which maintain separate profiles.
- Optionally, you can give users the ability to synchronize their profiles. Stack Exchange, for example, has a "Save changes for just this community" button and a "Save and copy changes to all public communities." But that is a separate requirement to be determined with your product owner(s).
Don't think of it as "cross tenant users." That is a solution, not a requirement. Focus on the use cases first and determine the solution based on those.