This chapter from Modern Authentication with Azure Active Directory for Web Applications, by Vittorio Bertocci, takes a closer look at how Azure AD represents applications and their relationships to other apps, users, and organizations.
It’s time to take a closer look at how Azure AD represents applications and their relationships to other apps, users, and organizations.
You got a brief taste of the Azure AD application model in Chapter 3, “Introducing Azure Active Directory and Active Directory Federation Services.” Later on you experienced firsthand a couple of ways to provision apps and use their protocol coordinates in authentication flows. Here I will go much deeper into the constructs used by Azure AD to represent apps, the mechanisms used to provision apps beyond one’s own organization, and the consent framework, which is the backbone of pretty much all of this. I’ll also touch on roles, groups, and other features that Azure AD offers to grant fine-grained access control to your application.
The application model in Azure AD is designed to sustain many different functions:
- It holds all the data required to support authentication at run time.
- It holds all the data for deciding what other resources an application might need to access and whether a given request should be fulfilled and under what circumstances.
- It provides the infrastructure for implementing application provisioning, both within the app developer’s tenant and to any other Azure AD tenant.
- It enables end users and administrators to dynamically grant or deny consent for the app to access resources on their behalf.
- It enables administrators to be the ultimate arbiters of what apps are allowed to do and which users can use specific apps, and in general to be stewards of how the directory resources are accessed.
That is A LOT more than setting up a trust relationship, the basic provisioning step you perform with traditional on-premises authorities like ADFS. Remember how I often bragged about how much easier it is to provision apps in Azure AD? What makes that feat possible is the highly sophisticated application model in Azure AD, which goes to great lengths to make life easy for administrators and end users. Unfortunately, the total complexity of the system remains roughly constant, so somebody must work harder to compensate for that simplification, and this time that somebody is the developer. I could work around that complexity and simply give you a list of recipes to follow to the letter for the most common tasks, but by now you know that this book doesn’t work that way. Instead, we’ll dig deep to understand the building blocks and true motivation of each moving part—and once we emerge, everything will make sense. Don’t worry, the model is very manageable and, once you get the hang of it, even easy, but some investment is required to understand it. This chapter is here to help you do just that.