I’ve been working on a problem with identity for a multi-tennant application offered by a provider. There are a few specific requirements:
- The Provider has multiple multi-tennant SaaS offerings
- The provider needs to invite a primortial user into an offering
- The primortial user can invite other users
- The primortial user can setup federation with an external identity provider
- Users should be able to log into this application and any other SaaS application offered by the provider.
I struggle with all things Identity so I need a working example to ground myself as I try to solve the problem. So here is the Example:
Use Case for Company Contoso
- The primordial user
create a new accountprocess for one of the multi-tenant SaaS offerings offerd by the provider
- If the user doesn’t have a way to log into the provider’s setup process they can create a new account.
- This new account will be stored in
live.comas a Microsoft Account with a a record like
- The user then creates a New Tenant called
constosoand this will map to the multi-tenant naming of the provider to
- The user creates a new local user. There are now two users that have access in the
- The user Configure the Domain
contoso.comto point to
- The user creates new user in tenant for the domain
- There are now three users in the
One of the key things to understand is that the user
email@example.com potentially has two differenty ways to log into the tenant:
- One through the
- One through the
firstname.lastname@example.org were deleted from the
contoso.onlitware.com tenant then the user would still be able to log in through the
live.com account. This is because the
live.com account is a Microsoft Account and not a local account in the
Configure auditing of what accounts have access to the tenant.
I have a project where I created a POC for a similar problem here https://github.com/briglx/python-b2c-app.
This application is hosted in the provider’s tenant, but the identities are stored in an Azure AD B2C directory. This directory is then setup to federate with the customer’s Azure AD tenant. This allows the customer to manage the identities in their own tenant.
A provider could use this model to allow customers to onboard easily, setup federation, and manage their own identities.
A second Multi-tenant SaaS application could use the same Azure AD B2C directory. This would allow the customer to use the same identities in both applications.