Professional Documents
Culture Documents
Azure Active Directory
Azure Active Directory
By
Mohamed Waly
Table of Contents
About the Author......................................................................................................... 4
Chapter 1: Introduction ............................................................................................ 5
1.1
1.2
1.3
1.4
1.5
1.6
Custom Domains......................................................................................... 10
1.7
1.8
1.9
1.10
Summary.................................................................................................... 15
Introduction ................................................................................................... 16
2.2
2.3
2.4
2.5
Summary ....................................................................................................... 34
Introduction ................................................................................................... 36
3.2
3.3
3.4
3.5
3.6
3.6.1
APPLICATION ................................................................................................ 46
3.6.2
3.6.3
3.6.4
3.7
3.8
Summary ....................................................................................................... 54
Introduction ................................................................................................... 56
4.2
4.2.1
ENABLE
GROUP
CLAIMS
FOR
THE
LOCATE
THE
OBJECT
ID
FOR
THE
DEV/TEST
4.3
4.4
Summary ....................................................................................................... 65
Mohamed Waly: I'm a former Hyper-V MVP, Microsoft Student Partner, I use to
deliver sessions about Virtualization Technology and Cloud Computing.
Chapter 1:
Introduction
Figure 1.1
Throughout this book, the focus will be on the developer, with careful
attention given to the tools, libraries and features of Azure AD that can
be used to build cloud applications that are protected by Azure AD. This
chapter lays the groundwork for some key concepts in Azure AD. Future
chapters in this book will go deep into the developer experience for
different types of cloud applications.
Figure 1.2
domain name you want to use with your directory. Next, you need to go
through a domain verification step in Azure AD, which basically involves
updating the DNS records with your domain registrar to include a TXT
record and value (provided by Azure AD) to prove you own the domain.
The details for configuring a custom domain are covered in full detail in
this Verify a domain article on TechNet.
OAuth 2.0 This is an authorization protocol that has been quickly and
widely adopted in the industry as a way to sign-in users using their
credentials at popular web applications such as Facebook, Twitter, and
other social applications. Some of the benefits of this protocol is its
smaller token format, JSON Web Token (JWT), and application scenarios
11
The OAuth 2.0 and OpenID Connect just recently became Generally
Available (GA, or fully supported and out of preview in September of
2014) on Azure AD and there is a great amount of work going into
libraries like Active Directory Authentication Library (ADAL) and OWIN
middleware components to light up scenarios these protocols enable for
developers. This book will cover these libraries in great detail in later
chapters. The type of application you build and the requirements for your
application will largely determine which of these protocols is used to
protect the application when registering it with Azure AD. For now, it is
enough to know they are supported by Azure AD.
Notice
that
every
12
endpoint
starts
URL
Endpoint
Federation
https://login.windows.net/<tenant>/federationmetadata/2007-
Metadata Document
06/federationmetadata.xml
WS-Federation
https://login.windows.net/<tenant>/wsfed
SAML-P
https://login.windows.net/<tenant>/saml2
https://login.windows.net/<tenant>/oauth2/token
OAuth
2.0
https://login.windows.net/<tenant>/oauth2/authorize
Authorization
https://login.windows.net/cloudalloc.onmicrosoft.com/wsfed
https://login.windows.net/530c3a3b-e508-4826-997a38fb543bc87f/wsfed
If a custom domain was configured for the directory, then the domain
name could also be substituted for <tenant>.
As this book progresses we will see how these endpoints are leveraged
for various types of applications.
13
Figure 1.3
When you choose the option to add an application my organization
is developing, you must next indicate the type of application you are
going to add. The reason the type is important is because it is here
where necessary protocol artifacts will be collected leading you
eventually to the use of either WS-Federation or OAuth / OpenID
Connect. The two choices are:
14
1.10 Summary
In this chapter I introduced Azure AD and some important concepts
regarding users. I talked briefly about custom domains and then wrapped
up by covering the protocols supported by Azure AD and how they are
surfaced through application endpoints unique to the directory. In the
next chapter, Ill dive into the developer experience and talk about
building on the first of the two choices mentioned in the last section
which is Web Applications and/or Web APIs.
15
Chapter 2:
2.1 Introduction
In the last chapter I introduced some basic concepts about Azure Active
Directory and ended with a review of the protocols and application
endpoints that are used to build applications protected by Azure AD. In
this chapter I will continue by talking about developing Web
Applications and Web APIs protected by Azure AD using Visual Studio
2013.
Before I get into the developer experience of building a Web
Application or Web API protected by Azure AD using Visual Studio, I
want to quickly pick up where I left off on the previous chapter and talk
about the portal experience of adding an application to your directory.
The experience is extremely simple and prompts you to make only four
choices as shown below, two of which require very little thought.
Figure 2.1
Here is a quick description of the four prompts.
16
1. The name of your application. This can be any name you want and is
simply how you will identify the application in your Azure Active
Directory.
2. The type of application. Notice that Web Applications and Web APIs
are considered the same type of application as far as Azure AD is
concerned. Since this article is about both, that makes this an easy
decision.
3. A Sign-On URL. This is the URL where users will access your application.
There is no verification of this URL so even if the application hasnt been
developed yet the portal will still let you add it.
4. An App Id URI. Notice this is a URI and not a URL. This is what Azure AD
will use to identify your application when authentication users
requesting access to it. It can be practically anything you want as long
as it is unique in your directory and a valid URI.
Now, click the checkmark and you have registered an application in
Azure AD. Is it really that simple? Well, not really. What you have is just
enough information at your fingertips to go build the application you
just added to your directory. And if you continue down this path I
promise you will learn to appreciate the degree of automation that
Visual Studio and the Azure SDK provides for you when building Web
Applications and/or Web APIs that are protected by Azure AD.
So, lets develop that appreciation now.
2.2
17
Assuming that you are starting from the ASP.NET Project template for
an MVC application and will be hosting it in an Azure Website, the first
thing you must do is change the authentication type to use
Organizational Accounts (the same as Student or Work accounts
mentioned in the last article) and enter the domain (Azure AD tenant)
you are externalizing authentication to. In my sample shown here, the
Azure AD Tenant is configured with a custom domain otherwise it would
be <tenant-name>.onmicrosoft.com.
Figure 2.2
The next change you must do is specify an existing Azure SQL Database
Server to use with your application or create a new one. The reason why
this is required is because the code that is added to your project by the
ASP.NET project template when using Organizational Accounts requires
it.
18
Figure 2.3
These are the only two changes you would have to make to successfully
create a web application and add it to your Azure Active Directory using
Visual Studio. If you prefer a step-by-step experience that walks you
through every dialog and more, then please see Authenticating with
Organizational Accounts and Azure Active Directory. And if you are
interested in further understanding the SQL Database dependency I
mentioned above, then see Deep Dive: Azure Websites and
Organizational Authentication using Azure AD.
The application produced by the ASP.NET template uses Windows
Identity Foundation (WIF) in the .NET Framework to take care of
authenticating users accessing the application. WIF provides the
implementation of protocols such as WS-Federation that an application
like this uses to authenticate users. It handles redirecting
19
unauthenticated users to the correct sign-in (and sign-out) URL for their
realm, verifying the signature of the SAML token issued to the client
after successfully authenticating, managing session tokens and cookies
for the client, extracting claims about the user from the token, and
putting these claims in the principal object of the current thread. Most
of this functionality is implemented in two HTTP modules that WIF
provides, which are
the WSFederationAuthenticationModule and SessionAuthentication
Module. Visual Studio takes care of adding these in the web.config as
shown here.
<system.webServer>
<modules>
<add
name="WSFederationAuthenticationModule"
type="System.IdentityModel.Services.WSFederationAuthenticationModule,
System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089"
preCondition="managedHandler" />
<add
name="SessionAuthenticationModule"
type="System.IdentityModel.Services.SessionAuthenticationModule,
System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089"
preCondition="managedHandler" />
</modules>
</system.webServer>
20
<system.identityModel>
<identityConfiguration>
<issuerNameRegistry type="CloudAlloc.Website.Utils.DatabaseIssuerNameRegistry,
CloudAlloc.Website" />
<audienceUris>
<add value="https://cloudalloc.com/CloudAlloc.Website" />
</audienceUris>
<securityTokenHandlers>
<add
type="System.IdentityModel.Services.Tokens.MachineKeySessionSecurityTokenHandler,
System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089" />
21
<remove type="System.IdentityModel.Tokens.SessionSecurityTokenHandler,
System.IdentityModel, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089" />
</securityTokenHandlers>
<certificateValidation certificateValidationMode="None" />
</identityConfiguration>
</system.identityModel>
<appSettings>
<add key="webpages:Version" value="3.0.0.0" />
<add key="webpages:Enabled" value="false" />
<add key="ClientValidationEnabled" value="true" />
<add key="UnobtrusiveJavaScriptEnabled" value="true" />
<add key="ida:FederationMetadataLocation"
value="https://login.windows.net/cloudalloc.com/FederationMetadata/200706/FederationMetadata.xml" />
<add key="ida:Realm" value="https://cloudalloc.com/CloudAlloc.Website" />
<add key="ida:AudienceUri" value="https://cloudalloc.com/CloudAlloc.Website" />
22
</appSettings>
23
</federationConfiguration>
</system.identityModel.services>
This
configuration
applies
specifically
to
the
2.3
24
Figure 2.4
The rest of the experience is the same as for web applications with one
very important difference the Web API project has no requirement
for a SQL Database. Now, you may want to have a SQL Database linked
to your Web API, but just understand that the project template in this
case does not emit any code in your project that absolutely requires it.
So, youre free to choose the No database option if you like as shown
here.
25
Figure 2.5
26
format that is much lighter than the SAML token format we saw
previously.
Unlike WIF, OWIN is not a core component of the .NET Framework 4.5
stack. Instead, it is delivered to your project through a set of Nuget
packages as shown below, consisting of the community owned and run
Owin package (Owin.dll) and several Microsoft Owin Components that
provide the implementation of the OWIN specification.
<package id="Microsoft.Owin" version="2.1.0" targetFramework="net45" />
<package id="Microsoft.Owin.Host.SystemWeb" version="2.1.0"
targetFramework="net45" />
<package id="Microsoft.Owin.Security" version="2.1.0" targetFramework="net45" />
<package id="Microsoft.Owin.Security.ActiveDirectory" version="2.1.0"
targetFramework="net45" />
<package id="Microsoft.Owin.Security.Jwt" version="2.1.0" targetFramework="net45"
/>
<package id="Microsoft.Owin.Security.OAuth" version="2.1.0"
targetFramework="net45" />
<package id="Owin" version="1.0" targetFramework="net45" />
27
28
Figure 2.6
Startup.cs provides the class name and method signature that Katana
applications look for to configure the Microsoft OWIN components. The
Configuration method takes an IAppBuilderinterface which if you recall,
is the interface defined in the Owin.dll.
using Owin;
namespace CloudAlloc.WebAPI
{
29
30
namespace CloudAlloc.WebAPI
{
public partial class Startup
{
public void ConfigureAuth(IAppBuilder app)
{
app.UseWindowsAzureActiveDirectoryBearerAuthentication(
new WindowsAzureActiveDirectoryBearerAuthenticationOptions
{
Audience = ConfigurationManager.AppSettings["ida:Audience"],
Tenant = ConfigurationManager.AppSettings["ida:Tenant"]
});
}
}
}
The bearer token middleware simply means that any party in possession
of a token (a bearer) can use it get access to the resource (the Web
API endpoints in this case) as defined in the OAuth 2.0 Authorization
Framework specification.
Just like in the Web Application scenario, this Web API project has all of
these details implemented for you and the application is automatically
registered in Azure Active Directory. Unlike the Web Application
scenario, you cannot just press F5 to run it in your browser. This is a
Web API project that expects you to be the bearer of a JWT token to
31
access the endpoints of the application. Ill show you how to get that
token and use it to access the Web API endpoints in the next chapter.
32
Figure 2.7
These classes are core components of the .NET Framework starting with
version 4.5. You dont need to download a Nuget package or install an
SDK. These classes are as common as System.String and are defined in
the mscorlib assembly. So, if youre targeting .NET Framework 4.5 or
newer, then your application is a claims-aware application.
The ClaimsPrincipal class has a static property called Current that will
return the ClaimsPrinicipal object for the thread. It is also equipped with
some handy methods you can used to find and retrieve the values of
claims for a client
The Claim class is used to describe statements about the Subject (or
client) that the Issuer can prove. Each claim as a Type that describes the
33
Or, if you prefer to use LINQ you could do something like this.
var principal = ClaimsPrincipal.Current;
var surnameClaim = principal.Claims.Where(c => c.Type ==
ClaimTypes.Surname).FirstOrDefault();
var surname = (surnameClaim != null) ? surnameClaim.Value : "";
2.5 Summary
In this chapter talked about the developer experience of building Web
Applications and Web API applications that are protected by Azure AD.
To recap each of these, a Web Application generated using Visual
Studio 2013 is protected by WIFs implementation of the WS-Federation
protocol which is configured via settings in web.config, code that is
added to your project, and a SQL Database that stores cryptographic
keys. The web application receives a SAML token from authenticated
34
users and WIF validates the token and extracts the claims about the
client from the token.
Web API applications generated using Visual Studio 2013 are protected
by Microsofts OWIN middleware components using OAuth 2.0 and JWT
token format. The OWIN components perform similar token validation
and also extract the claims from the token.
Finally, I wrapped up with a brief overview of the ClaimsPrincipal and
Claim classes and demonstrated how you can retrieve the claims to
drive behaviors in your application code.
In the next chapter, I will cover the Active Directory Authentication
Library (ADAL) and show you how you can use it to call Web APIs
protected by Azure AD and build native client (non-browser based)
applications for Azure AD.
35
Chapter 3:
3.1 Introduction
In the last chapter I discussed developing two types of applications
protected by Azure Active Directory: web applications and web APIs. In
that chapter I approached these applications from the perspective of a
developer using Visual Studio 2013 and the project templates provided
for creating these types of applications. The automation delivered by
Visual Studio and the Azure SDK when creating these applications
resulted in the two applications being registered in my Azure Active
Directory as shown in the following Figure:
Figure 3.1
application and discuss how you can develop a native client to acquire
an access token that can be used to access the Web API.
A native client application is one that is installed on a users computer or
device. Examples of such an application include, but is not limited to,
WinForms, WPF, Windows Store, Windows Phone, and iOS applications.
And while these applications may not necessarily run in Azure as
compared to the web application and web API applications discussed in
the previous chapter, native client applications can be protected by
Azure Active Directory and access other applications registered with
Azure Active Directory.
3.2
37
{
// Look for the scope claim containing the
// value 'Read_CloudAlloc_WebAPI' or 'Read_Write_CloudAlloc_WebAPI'
var principal = ClaimsPrincipal.Current;
Claim readValuesClaim = principal.Claims.FirstOrDefault(
c => c.Type == "http://schemas.microsoft.com/identity/claims/scope" &&
(c.Value.Contains("Read_CloudAlloc_WebAPI") ||
(c.Value.Contains("Read_Write_CloudAlloc_WebAPI"))));
if (null != readValuesClaim)
{
//
// Code to retrieve values to include in the response goes here.
//
return Request.CreateResponse(HttpStatusCode.OK);
else
{
return Request.CreateErrorResponse(
HttpStatusCode.Unauthorized, "You don't have permissions to read values.");
}
}
2. For the chapter method, I made similar changes but instead look
for
the
scope
claim
containing
the
// POST api/values
38
if (null != writeValuesClaim)
{
//
// Code to add the resource goes here.
//
return Request.CreateResponse(HttpStatusCode.Created);
}
else
{
return Request.CreateErrorResponse(
HttpStatusCode.Unauthorized, "You don't have permissions to write values.");
}
}
39
of
claims
with
this
level
of
granularity
into
3.3
Figure 3.2
40
The manifest is a JSON formatted file that contains the Azure Active
Directory configuration for an application registered in Azure Active
Directory. If you scroll through the file you will see the settings you see
on the CONFIGURE page for an application and much more. The
configuration setting were interested in for this chapter is the
oauth2Permissions setting. By default, this is an empty array, as shown in
the following Figure.
Figure 3.3
41
"origin": "Application",
"type": "User",
"userConsentDescription": "Allow read access to the CloudAlloc WebAPI on your
behalf",
"userConsentDisplayName": "Read access to CloudAlloc WebAPI",
"value": "Read_CloudAlloc_WebAPI"
},
{
"adminConsentDescription": "Allow read-write access to the CloudAlloc WebAPI on
behalf of the signed-in user",
"adminConsentDisplayName": "Read-Write access to CloudAlloc WebAPI",
"id": "87A81936-E765-4678-B6DB-8E12197AAA7D",
"isEnabled": true,
"origin": "Application",
"type": "User",
"userConsentDescription": "Allow read-write access to the CloudAlloc WebAPI on your
behalf",
"userConsentDisplayName": "Read-Write access to CloudAlloc WebAPI",
"value": "Read_Write_CloudAlloc_WebAPI"
}],
42
After making this update to the manifest file all that is left is to upload it
to Azure by clicking theMANAGE MANIFEST button and selecting
the Upload Manifest option.
Now the Web API application can be accessed from other applications
using these permissions.
Figure 3.4
43
The next page of the wizard will prompt you for the redirect URI
associated with the native client application. This is a URI (not a URL), so
any value will work as long as it is a valid URI and is unique to your
directory. The following Figure shows the URI for the native client
application Im building.
Figure 3.5
That is all that is required to register the application with Azure Active
Directory. The application will appear in the APPLICATIONS page of the
directory as a Native client application as shown in the following Figure:
Figure 3.6
44
3.5
Figure 3.7
they
will
now
get
the
scope
claim
with
value
46
Figure 3.8
When a native client needs to get a token from Azure Active Directory, it
needs to specify the resource it wants a token for. In this scenario the
client application wants access to the Web API so the APP ID URI for the
Web API is used as the resource name. After it has the token it also needs
to know the URL where the resource can be accessed, in this case the
address of the Web API.
// Resource settings this application wants to access
private string resource = "https://cloudalloc.com/CloudAlloc.WebAPI";
private Uri WebAPIUri = new Uri("https://localhost:44313
47
Figure 3.9
Note: The reason the reply URL is a localhost address is simply because
in the previous chapter when these applications were created and
registered in Azure Active Directory, I didnt publish them to Azure
Websites. If I had, then this reply URL would have a *.azurewebsites.net
address instead. To see how publishing a web application and/or web API
to Azure applies to applications registered in Azure Active Directory.
For ADAL to authenticate the user and acquire a token for the resource,
an AuthenticationContextmust first be instantiated by passing in the
URL of your tenant in Azure Active Directory. The URL is of the form
https://login.windows.net/<tenantID> where <tenantID> can be either
the GUID assigned to your tenant in Azure AD or the domain if you have
a custom domain configured.
// Session to Azure AD
private const string authority = "https://login.windows.net/cloudalloc.com";
48
49
// Create an HTTP client and add the token to the Authorization header
authResult.AccessTokenType, authResult.AccessToken);
if (httpResponse.IsSuccessStatusCode)
//
50
//
return (httpResponse.IsSuccessStatusCode);
// Create an HTTP client and add the token to the Authorization header
HttpClient httpClient = new HttpClient();
httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue(
51
authResult.AccessTokenType, authResult.AccessToken);
return (httpResponse.IsSuccessStatusCode);
}
52
Figure 3.10
Using the Azure Management portal, I can change the permissions for
my native client application to grant the read/write permission instead,
as shown:
Figure 3.11
53
Figure 3.12
3.8 Summary
55
Chapter 4:
Group Claims
4.1 Introduction
In the last chapter I showed how you can use the Active Directory
Authentication Library (ADAL) to build a native client application that calls
the CloudAlloc.WebAPI introduced in earlier chapters of this book. As part
of that chapter, I demonstrated how the Web API could be exposed to
other applications using ouath2Permissions that I defined in the
manifest which enabled me to assign these permissions to my native
client application as shown:
Figure 4.1
Being able to assign read and write permissions in this way provided an
easy and useful way to control an applications ability to invoke various
operations using the claims that were issued by Azure Active Directory
for an authenticated user. However, the level of granularity for which
authorization decisions can be made in the application code is pretty
coarse with this approach. In my example, it was the simple read and write
permissions I defined and if the native client application was configured
to allow write permissions, then any authenticated user would be able to
invoke such operations. While that may be sufficient for some
applications,
others
may
require
additional
information
about
the user before making such authorization decisions. For example, you
may want to restrict write operations to users in a specific security group.
As you can see in Figure 2, the claims provided by Azure Active Directory
for our authenticated user John Doe just dont provide that level of detail
56
about the user (yet). Other than some various identifier claims about John
Doe, were currently limited to the values in the scope claim to make
authorization decisions.
Figure 4.2
A common need for many applications is the ability to make authorization
decisions based on a users membership in a specific security group (or
groups). In this chapter Im going to show how you can take advantage
of some recently released features of Azure Active Directory to do just
that.
4.2
Now, you can just look for it in the Claims collection for the authenticated
user provided you enable the group claims feature for your application in
Azure AD. Lets see how this would work for the application weve been
talking about and only allow users to invoke the POST method if they are
in the Dev/Test security group.
57
4.2.1 ENABLE
GROUP
CLAIMS
FOR
THE
CLOUDALLOC.WEBAPI APPLICATION
Enabling the group claims feature currently requires that you update the
manifest for the application in Azure AD. This is exactly the same
process I showed you in the last chapter where I set
the oauth2Permissions for the application.
In the Azure Management portal Ill begin by going to
the CONFIGURE page for the CloudAlloc.WebAPI application in Azure
AD. At the bottom of the page is a MANAGE MANIFESTbutton where I
can select to download the manifest for the CloudAlloc.WebAPI
application as shown in Figure 3.
Figure 4.3
The application manifest is just a JSON file that you can edit with the
simplest of editors (ie: notepad.exe). By the way, if youre curious what
the GUID in the filename is about when you download the manifest, it is
the Client ID that was assigned to the application when it was registered
in
Azure
AD.
Scrolling
down
the
manifest
file
will
find
Figure 4.4
Im going to change this value to SecurityGroup and then save the
changes as shown in Figure 5.
58
Figure 4.5
4.2.2 LOCATE
THE
OBJECT
ID
FOR
THE
DEV/TEST
SECURITY GROUP
When Azure AD adds applicable group claims to the token it issues for
my users, the value for the group claim will be the Object ID of the security
group and not the name of the security group. Remember, every entity in
Azure AD has a unique Object ID associated with it. You may think it
would be more intuitive to refer to the group by name instead of the
Object ID. This is true. However, a groups name can be changed in the
directory so it is not a reliable identifier for the group. The Object ID will
never change as long as the group exists. So, in this case, I need to find
the Object ID for the Dev/Test security group. This can be found in
59
Figure 4.6
Now that I have the Object ID for the Dev/Test security group I am ready
to make the necessary code changes.
// POST api/values
public HttpResponseMessage Post([FromBody]string value)
{
// Look for the scope claim containing the value 'Read_Write_CloudAlloc_WebAPI'
var principal = ClaimsPrincipal.Current;
Claim writeValuesClaim = principal.Claims.FirstOrDefault(
c => c.Type == "http://schemas.microsoft.com/identity/claims/scope" &&
c.Value.Contains("Read_Write_CloudAlloc_WebAPI"));
// If the app has write permissions and the user is in the Dev/Test group...
if ((null != writeValuesClaim) && (null != groupDevTestClaim))
{
//
// Code to add the resource goes here.
//
return Request.CreateResponse(HttpStatusCode.Created);
}
61
else
{
return Request.CreateErrorResponse(
HttpStatusCode.Unauthorized, "You don't have permissions to write values.");
}
}
Figure 4.7
62
The value for the first groups claim should look familiar it is the Object
ID for the Dev/Test group I discussed earlier. The second one happens to
be a Developer security group in my directory for which John Doe is a
member. Figure 8 shows the membership for both security groups.
Figure 4.8
size of the token. Therefore, there are limits on the number of group
claims that Azure AD will place in a token as follows:
4.3
The Azure AD Graph API is a REST API that Azure Active Directory makes
available for each tenant. With it you can programmatically access the
directory and query about users, groups, contacts, tenant details and
more. In addition to querying the directory, the Azure AD Graph API can
be used to create, update and even delete entities in the directory.
For the scenario mentioned above, the Azure AD Graph API could be
used to look up the security groups a user belongs to or to check if a
user is in a specific security group. The latter is particularly applicable in
our scenario here and could be achieved using the IsMemberOf
function. To execute this query you need only the Object ID of the user
and the Object ID of the security group. The query will execute in Azure
AD (server side) and simply return true or false. Prior to the release of
the group claims feature in Azure AD discussed in this chapter, this was
the only way to check group membership for a user. In situations where
the number of groups a user is in could potentially exceed the limits
above, it is still available to you.
64
4.4 Summary
In this chapter, I showed how to take advantage of the new Azure Active
Directory group claims feature and apply it to our scenario to determine
a users membership in a particular security group. I also discussed the
group claims limit as it applies to JWT and SAML tokens issued by Azure
AD
and
how
you
can
fall
back
on
the
Azure
AD
Graph
65