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:

• Facebook
• Google+
• Microsoft account
• Amazon
• LinkedIn

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:

• Email
• 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.