First published on MSDN on Apr 11, 2017
Authored by Andreas Helland
Azure Active Directory is a service with a range of different features for different purposes. And with different features comes different acronyms, or TLAs if you will, that need to be sorted out.
Sure, a quick search on the Internet will usually spell out the letters for you, but let's take our own little tour nonetheless. I'm not covering all of the different TLAs here; this is just a starter on some of the high level features it's important to be aware of because they impact your design early on in the process. Each of these comes with its own set of documentation, and should be explored further than what I'm doing here if you see something matching your use cases.
Regular/Plain/Classic Azure AD
This is the "root service" where you create a user directory, and have it stored and accessible through the public cloud. There is an it pro part of it as well as a developer story. We've already covered the basics of this. But looking at the high level aspect - what does this intend to solve?
"Plain" AAD is meant for a single organization, and is referred to as single tenant. Does it cover more complex setups than one domain controller in one office? (I am aware that you should never have less than two DCs in a domain.) Yes, it does. Well, depending on your specific setup at least. It doesn't support every crazy forest configuration you throw at it, but when installing AAD Connect you can tweak the defaults to support multi-domain and multi-site.
What about sites and domains in a cloud only setup? Well, no.. Conceptually "the cloud" is the site, and it doesn't have branch offices. Originally sites were introduced to handle issues like replication over slow links, and the cloud doesn't have these restrictions. Don't get your mind stuck in old constraints :)
Either way, this is the place you start off. Whether you have a setup where you consume Office 365 services, or you intend to develop apps for yourself or a customer, start with the basics of acquiring a tenant. Have a look at the switches and levers in the Azure Portal, and do some of the basic code samples.
More info:
https://docs.microsoft.com/en-us/azure/active-directory/active-directory-whatis
Azure AD B2B
Having your own little tenant with your data and users you have full control over is nice. At some point though you are likely to find yourself having to share some of that data with other users outside the safe confines of your tenant. The scenarios I'm thinking about are things like hiring in external consultants for a project. Or maybe someone in marketing needs to share files with a graphic designer for an upcoming campaign. You'll probably have no problem finding some use cases where the issue at hand is sharing across organizations.
For this we have AAD B2B.
AAD B2B is as the name implies intended for sharing between businesses. If you work in Contoso, and need to work with someone outside Contoso it should be covered by B2B. But what does this require and mean in practice? If the other company also has an AAD tenant there's just some "invisible magic" on the back-end creating a federation between the tenants. If they don't have a tenant a "shadow" tenant will be created before the federation is created. In other words, it should work even if the other company is not a major Microsoft customer.
B2B is not a developer feature. While you can use an API for automating the invitation of external users it is intended for someone with an admin role. You as the developer don't need to approach this in a specific manner.
At the base of it this is just federation solved in an easier manner than working out the kinks of each company setting up something like an ADFS server, and agreeing on manual connections between the entities. Which means that you control the authorization of external users, but the authentication is handled by their tenant.
An architectural consideration that creates some confusion for developers here is single-tenant vs multi-tenant. If I create an app that will be used by Contoso employees, and consultants from Northwind - is that multi-tenant? How do I handle the B2B part of it? This is sort of a question of what the business model for your app is. Is it an internal app, even if there are external users, or is it an app that will be made available for different companies independently of each other (basically a normal software solution)? If it is an internal app you as the developer need not care about B2B; just develop a regular single-tenant app. If you want to sell your app to a number of Azure AD tenants B2B is not the feature you are looking for. In those cases go with the plain AAD model, but make it multi-tenant instead of single-tenant. B2B is for when you need to work on the same resources, not when each company works on their own resources.
More info:
https://docs.microsoft.com/en-us/azure/active-directory/active-directory-b2b-what-is-azure-ad-b2b
Azure AD B2C
Not all end-users are business users though. You usually have a good idea when registering on sites whether you are doing this in the capacity of being an employee, or if it's not work-related at all. And if it isn't related to work you are not likely to want to be using your business id. Azure AD is an engine for handling identities, and isn't tied directly to the identity being managed by a business, so enter B2C.
B2C is intended for consumer identities. Don't have a business identity with someone managing things for you? Do you have a Facebook login, or a Gmail account, or something? This is the way to go. AAD has pre-federated with a couple of social Identity Providers, and you can have them authenticate the user, and then you get to handle the rest.
An important difference between B2B and B2C is that B2C does not use the concept of tenants in the same way. In a regular tenant John Doe will be able to see Jane Doe and vice versa. Since they share the same employer this is desired behavior. In B2C each user is their own entity, and are not able to see everyone else. For instance - if you have a Gmail account and exchange mails with another Gmail user Google will share attributes like the profile image between them, but when composing a new mail you don't get access to the complete directory of email accounts managed by the service.
B2C is a developer feature. It provides value when you are building apps, and want to have a fully featured identity system you don't have to implement and manage while letting the users use an identity they have already established. Which also means there is no easily accessible switch in the management UI to let random consumers access your company SharePoint with their Facebook credentials.
It's also a service where there are a lot of in-progress features, so as a developer I would definitely keep track of this going forward. Expect more scenarios to be solved by B2C in the future.
More info:
https://docs.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-overview
Azure AD Directory Services (AADDS)
While we all know "the cloud" is a good way to solve a lot of problems there are times where our minds go into an on-prem mode of thinking; either because we are not aware of how to solve our issue in an entirely new way, or simply because some things can require a lot more work to modernize than we want to spend time on. For some of these issues we can use the part of Azure AD called AADDS. It should however not be applied to all our "on-prem issues".
So, what is AADDS? It is basically Active Directory in the cloud. Wait a minute - is this not what Azure AD is? One of those classic questions with both a yes and no answer. AAD is AD reimagined for the cloud, and it focuses on protocols like OAuth, SAML, WS-Fed. An on-prem Domain Controller focuses on exposing Kerberos and LDAP(S), and thus matches classic AD better. That's a discrepancy between AAD and AADDS, but this is fully intentional.
AADDS intends to solve use cases where you require support for Kerberos and LDAP, but want it hosted in the cloud. This does not equal a Windows Server 20xx DC in the cloud as you don't really get an identical feature set. It does however solve things like having a virtual machine with SQL Server installed in Azure joined to a domain leveraging service accounts through Kerberos.
Should you be running SQL Server in a VM when you can use the native Azure SQL service? We're focused on lift and shift here. If you have a piece of software requiring a full install of SQL Server you can't necessarily change that easily, but if you could move it piece by piece to the cloud it might still make sense. To make sure the SQL Server behaves the same way you need a domain interface in the cloud matching what you already have, and that is where AADDS comes in.
Great! So, I can manage users/groups/everything I do on a DC in the cloud? No, that is not what you should do. Sure, supporting LDAP you can do user authentication actions, but that does not mean it is recommended to do so. It is for supporting server workloads, not general user management. User management should still be done with the other variants of Azure AD.
And just in case it's not clear. When you as a developer start off building something fresh, (aka not making legacy software work), you should probably not base yourself on AADDS being what drives your authentication components.
More info:
https://docs.microsoft.com/en-us/azure/active-directory-domain-services/
Azure AD B2X
If you're feeling a little bit creative you can probably come up with scenarios of your own where you wonder which bucket these fit into. So, I created my own acronym for this. You can't actually sign up for an Azure AD B2X service :)
Maybe you have both business and consumer customers. You could have a selection when registering allowing the user to choose between a business or a consumer identity. On the back-end you would trigger either a flow based on multi-tenant AAD integration, or a B2C flow based on the choices.
Maybe you have business customers, but you want them to sign in with social identities. This is a bit more tricky, and would possibly require an amount of effort depending on what you want to do once they have logged in. You might need to employ claims, and an additional interface for mapping attributes to a company entity.
You get my point. There are things that do not easily map to these features, but by either building on top of, or combining these you can cover a lot of ground. With a bit of luck it will be less work than implementing everything from scratch yourself.
This really is just skimming the bits swimming on top of the AAD Alphabet Soup, but if you dig deeper it should still keep you occupied for a while.
Have a scenario you don't know how to approach? Shout out below in the comments. (Which also applies if you have a killer approach others should be aware of.)
Have a scenario Microsoft really should address in a future update of Azure AD? Vote or create a new request on UserVoice:
https://feedback.azure.com/forums/169401-azure-active-directory