Using Azure AD Entitlement Management to onboard and manage users.

In the previous post, I talked about using self-service sign-up via user flows to onboard an external user. With self-service sign-up, you can integrate with custom REST endpoints to implement approval workflows and other business logic. I’ve learned of another way to onboard and manage a user’s access by using Entitlement Management, which has built-in rich approval workflow and access lifecycle so you don’t have to build additional APIs to implement an approval workflow.

What is Entitlement Management

Microsoft has a good description of what’s entitlement management:

Azure Active Directory (Azure AD) entitlement management is an identity governance feature that enables organizations to manage identity and access lifecycle at scale, by automating access request workflows, access assignments, reviews, and expiration.

Entitlement Management Overview

In this post, I discuss the following features under entitlement management: access packages, catalogs, and connected organizations.

What is an access package?

Conceptually, an access package is a container of resources a user may need. The types of resources can be groups, applications or sharepoint sites. For example, suppose a user needs access to applications A, B, C and groups A, B C. Instead of assign the user each resource individually, you can package the resources into an access package and assign the user the whole package. If the user’s request to the access package is approved, azure ad shall deliver the package to the user. In this example, delivering the access means that azure ad will add the users to the groups A, B, C and apps A, B, C, all at once.

An access package belongs to a catalog, which is basically a way to group resources and access packages together. By default, azure provides the General catalog. You can create more catalogs as necessary. As an example, I created a catalog called Finance and added several applications and groups into the catalog.

Before you can create an access package, you’ll need either the Azure AD Premium P2 or the Enterprise Mobility + Security (EMS) E5 license.

You can find the tutorial with step-by-step instructions on using access packages to assign and manage access to resources so I’m not going to cover it here.

Connected organizations

Azure AD has the ability to look up an organization based on a domain. For example, if XYZ organization refers to another azure AD, you can look up and add the tenant as a connected organization. In my testing, I created two azure ad tenants with trial licenses and was able to add one tenant to the other as a connected organization. Furthermore, you can add any domain, not just the ones that associate with an azure ad tenant. In fact, you can have a policy that allows users from a connected organization to request access to the package, even if the organization does not represent an azure ad tenant. On requesting the access, the users can authenticate using email one-time passcode authentication. Note that email one-time passcode only works if the URL contains the tenant info. For instance, if the user goes directly to https://myaccess.microsoft.com to view and request access packages, the user will not be able to authenticate using one-time email passcode. When the user enters the email with the format: https://myaccess.microsoft.com/@{tenantName}.onmicrosoft.com#/access-packages/{accessPackageId}, the user can authenticate using email one-time passcode.

Access package policies

Upon creating an access package, you can use policies to specify who can request the access, manage approval workflow and lifecycle of the package. For example, when adding a policy to an access package, I can specify whether the package is for internal users, external users, or direct assignments only.

If I select the option “For users not in your directory”, then azure AD will create an account for the user as part of delivering the package to the user. Furthermore, I can limit requests to the access package to users whose emails are of certain domains via connected organizations.

Approval workflow

Access package has a rich approval workflow. In an access package policy, I can assign an approver who can approve or deny a request to access the package. I can further specify an alternate approver if the first approver has not reviewed the request within a specific amount of time. In addition to the first approver, I can specify another one who must approve the request before the user can have access.

Note that if you specify a second approver, both approvers must approve the request before the user can have access.

Access package lifecycle and reviews

You can set the user’s access to the package to expire after a certain period of time. You can further specify if a user can request an extension after the access has expired, and if so, whether the extension requires an approval. Per the document, Once the user no longer has access to any access package, azure ad shall block the user from signing in for 30 days, and subsequently remove the user’s guest account.

After a certain period of time, the user may no longer need or have access. For example, the user may have retired, found a job at another organization, or moved on to a different department, got promoted or moved to a different department. Usually, you do not have knowledge when this happens, and so it is helpful to conduct periodic review of the user access. With access review, you can specify someone to review the user’s access or you can have the end user do a self review.

End user experience

An access package has an object id. You can share the URL to a user who wants to request access to the package. The URL is a link to view the package under My Access Portal, provided by Microsoft. The URL has the following format: https://myaccess.microsoft.com/@{tenantId}.onmicrosoft.com#/access-packages/{accessPaageId}.

Within the access portal, the user is able to request access to the package, and check status of the request. If the request is approved, then the user is able to see the content of the package and associated resources.

As for the approvers, the experience is similar. An approver receives an email from Microsoft with a link to the My Access Portal. Upon successful authentication, the approver can view the details of the request and approve or deny, all within the same My Access Portal.

Thoughts

No double that Microsoft has carefully thought out the different problems of access management and design the features to solve a variety of them. For instance, suppose you have a few resources that you want to share with users of different companies, and you need to manage access of those users based on their companies.You can group the resources into an access package and create a policy for each company. Then, when a user requests the access package, azure shall apply the appropriate policy based on the email / domain which the user uses to authenticate.

My Access Portal is available to all the users and is an easy and fast way to allow users to request accesses to packages. However, the look and feel of the portal may not be user friendly, especially to a non Microsoft or azure AD user. For instance, the end user may not be familiar with the concept of an access package and how it works. Perhaps, providing a way to add personalized messages and logos may help. Better yet, it would be awesome if Microsoft allows customizing the portal using CSS and Javascript to make My Access Portal more beautiful and user friendly.

Overall, Entitlement management is a great azure AD B2B module worth checking out. Microsoft provides trial licenses, and you can also create a test tenant to play around with the features without affecting your current environment.

References

Identity Governance overview

Entitlement management overview

Govern access for external users in Azure AD entitlement management