Scenario: I’m creating a Software as a Service (SaaS). I’m having multiple customers & I want to manage their identity. For some of my customers the users won’t have corporate identity ; I would like to offer them to login using their social identity (e.g. Facebook) if they want to or create an account on my site otherwise. For other customers, they’ll come in with a corporate AAD (likely synchronized with on premise AD) and I would like to integrate with that. How do I do that in Azure?
Azure Active Directory (AAD) is an Identity & Access Management (IAM) service in Azure.
AAD can be used in multiple numbers of ways. You can use it as a simple identity store where you store user accounts with a given password. You can then use it to authenticate those users against a web site or a web API. You can have it synchronize with an on premise Active Directory, using Azure Active Directory Connect. You can enable multi-factor authentication with it. You can use it as an identity provider for third party SaaS applications (e.g. SalesForce.com), enabling SSO. You can also use it for on premise web applications, projecting them in the cloud, with Application Proxy. You can enable conditional access on those application proxies.
Lots of ways to use it.
Two new ways to use it, still in preview, are AAD B2C & AAD B2B. Both services are in preview at this time (mid-March 2016).
Business 2 Consumer
AAD B2C allows AAD to integrate with social networks:
This means your AAD won’t be authenticating the users, those social networks will. But, AAD will still be logging in the users. This means your application integrates with only one identity provider, which in turns integrates with many. It therefore federates identities from different sources.
You stay in control of the entire onboarding, login & other User Experience (UX) integration with social network by customizing those UX.
AAD B2C still allows you to create “local users”, i.e. users existing solely in your AAD tenant. This supports the scenario of “falling back” to creating accounts for your site only. Those users can have access to a self-service password reset.
On top of that AAD B2C allows you to customize the user schema, i.e. adding custom attributes on top of the standard ones (e.g. Given Name, Surname, City, etc.).
Since user accounts are imported in your tenant, you can put different users coming from different social networks within AAD groups, to manage application roles for instance.
You can see an introduction video here, see the pricing here (based on number of users & number of authentications). You should also consult the up-to-date list of known limitations here.
AAD B2C is actually a special type of AAD. You have to decide at creation if you want an AAD B2C or not.
Business 2 Business
AAD B2B allows you to bring identities from other AADs into your tenant and give them access to your applications.
This feature is free.
Currently (mid March 2016), the only to import user accounts is by using CSV files. This is done via the “Add User” window: simply select Users in partner companies in the as the type of user.
You need to supply a CSV file with a given format, i.e. with the following column names:
- DisplayName
- InviteAppID
- InviteReplyUrl
- InviteAppResources
- InviteGroupResources
- InviteContactUsUrl
The way it works is that the email you give is basically the key to find the user in the right tenant. For instance, vince@contoso.com will use contoso.com as identity provider. The user is then imported in your directory and its attributes are copied into it. The only thing that remains in the foreign AAD is the authentication.
Only non-Microsoft accounts are accepted in those.
Optionally you can specify the “InviteAppID” column. This will add the user in the given App within your tenant.
One of the advantage of importing the user account within your tenant is that you can assign it to groups within your tenant.
There is excellent documentation on this feature. You can find a detailed walkthrough and learn about the up-to-date current limitations.
Multi tenant SaaS strategy
The strategy I’m giving here leverages Azure Active Directory and isolates each of the SaaS tenant in a different tenant.
You could use one AAD tenant and throw the user accounts of all your tenants in it ; you would then solely use applications within your AAD to segregate between your SaaS tenants. Although this would work, it would be much harder to manage users this way.
Having separate AAD segregates your SaaS tenants more strongly. For instance, you could wipeout an entire SaaS tenant by deleting the corresponding AAD.
Here is how it could look like.
Cust-X & Cust-Y are the same scenario: the customers do not have a corporate AAD, hence you rely on AAD B2C to store and federate identities. You can then use AAD groups within the AAD B2C to control user membership and implement some application roles.
Cust-Z is a scenario where the customer do have a corporate AAD and you leverage AAD B2B to import the users that will use your application. The Cust-Z AAD tenant becomes a proxy for the corporate AAD.
A variant on this scenario is with Cust-W, where there is no proxy AAD and the AAD application used to authenticate your application’s users is within the corporate AAD of your customer.
So when would you choose Cust-Z over Cust-W scenario?
Cust-Z allows the owner of the application (you) to create groups within the AAD proxy and include different users into it. With Cust-W you can’t do that since you do not control the AAD. The advantage of Cust-W scenario is that your customer can more easily control which users should access your application since that one lives within his / her AAD.
Conclusion
So there you have it, a strategy to manage identities within a multi tenant SaaS solution.
As usual with architecture, there are more than one possible ways to solve the problem, so your mileage will vary as you’ll perform different compromises.
Nevertheless, the combination of AAD B2C & AAD B2B adds a lot of flexibility on how AAD can manage external identities.
Personally I’m a bit skeptical about this approach since it entail creating a multitude of Azure ADs. This might be doable if there was some way of automating the creation of new Azure ADs, but as long as you have to do it manually, my feeling is that it doesn’t scale for a solution with many customers.
Hi Pål,
That is a good point!
The scenario I had in mind was “a few customers”. The basis of that article was a customer need and they run a SaaS and target less than 20 customers over time (in the next few years).
For somebody running a SaaS with customers onboarding weekly or daily, that approach would quickly become unmanageable and then I would recommend one of the other approaches touched on the article.
I was also re-thinking our strategy for a multi-tenant SaaS solution with this multi-ADs approach. I wasn’t thinking about the issue of provisioning ADs automatically, but I was starting to wonder how to know what AD to use at the time of user-login. The user would have to choose the tenant pre-login (or otherwise navigate to different pages, etc).
Yes, the user sort of specify it when they login since they need to provide the domain name, e.g. john@mytenant.com. The domain is what AAD uses to map the tenant and route the authentication there.
Hi Vincent, You have some demo of the same MVC application using B2B and B2C
Hi Vincent, You have some demo of the same MVC application using B2B and B2C. Thanks very much.
Hi Jeisson,
I don’t have any specific demos I kept, but you should easily be able to build ones from https://docs.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-setup-msa-app & https://docs.microsoft.com/en-us/azure/active-directory/active-directory-b2b-how-it-works
Beautiful explanation, I understood better the difference between B2c and B2B and how AD acts as proxy
Tx!