In this blog series on building a full Identity Governance and Administration solution, we have until now covered application roles extensively, and how these can be sent to an application.
For a quick summary, this is how you can define custom application roles, here is how to send these roles using the SCIM protocol, this article shows how to transfer the roles using the OpenID Connect ID Token or SAML claim and here I can show you how to use PowerShell to query the Microsoft Graph for application role assignments for your users and groups.
So, having covered those topics in a detailed fashion, let’s have a look at how these application roles can be managed using Entitlement Management. In a later post, I will show how to do re-certify access using Access Reviews and assigning the different application roles in an automated manner using dynamic groups.
In Azure AD Entitlement Management, there are several new “words” to understand:
- An Access package is a set of permissions, such as a group/team membership or application role assignment, and a list of policies for who can request the access package
- A Policy, is a rule on who can request an access package, which approvals are required, when the access expires and how access is to be reviewed
- Catalog is a container of access packages and linked resources, where delegation can occur, such as delegating the ability to create new access packages for a limited set of resources in your Azure AD
- Connected Organization is a a way for you to defined external organizations, and who is both the internal and external sponsor for that organization.
- A Sponsor is a person that can approve access for a certain connected organization
- An Access Review is the process of someone going through the permissions and saying “Yes, this person should still have these permissions” or “No, revoke this access”.
When you start digging into Entitlement Management, you’ll find that you can achieve pretty cool things, such as:
- Allowing any random external user to request access to an access package, just by knowing the url of the package (you can also open it to be discoverable for anyone, but that might be a little too much). Example usage:
- Your IT department can send any external party a url in order for them to use their own Azure AD account to request access to the “External consultant” access package, giving access to VPN, RDP gateway etc.
- Your marketing department can send any external party a url in order for them to use their gmail account to request access to the “Photographer” access package, giving access to marketing apps and picture vaults
- Allowing a group employees to request access to an access package, with approval by their manager. Example usage:
- Any employee can request access to the access package “Microsoft Project License”, approved by their manager
- All IT employees can request access to the access package “Extended remote access”, approved by the security team, and reviewed every 6 months
- Allowing a defined set of external organizations to request access to an access package, with approval by an external or internal sponsor
- Any employee in Contoso and Northwind Traders can request access to the “Project Nextgen” access package. Peter, who is the internal sponsor for Contoso, and Amber, the internal sponsor of Northwind Traders, must approve requests for their relevant organizations.
Because the product is both complex and simple at the same time, I will first define a few scenarios and solve them below:
Scenario 1 – A new partner organization
Northwind Traders and Contoso are becoming close partners, and Contoso want to provide access to some of their applications to any Northwind Traders employees, but with an approval by the Northwind Traders partner contact, employed in Northwind Traders.
First, Contoso defines Northwind Traders as a connect organization:
Please note that if you want to add an external sponsor, he must be an existing guest account in your Azure AD (or a regular member account).
Please note that no “external approval of the established relationship” is required. This is simply a policy on your side.
Second, Contoso defines an access package “Partner applications”, allowed for their new partner Northwind Traders:
Third. That’s it. No third step… A Northwind Traders user can now navigate to https://myaccess.microsoft.com/M365x030202.onmicrosoft.com, (demo tenant, but it could have been https://myaccess.microsoft.com/contoso.com or a web redirector of course), signing in with his/her own Northwind Traders account, and request access. No pre-invited guest account required.
Scenario 2 – Any external user
The marketing department of Contoso want any external Photographer to be able to request access to relevant services, approved by the marketing department manager.
Let’s create an access package for this scenario:
Select ‘For users not in your directory‘, and now let’s use the “All users” option:
Now, after creation the access package, there is one important thing to notice:
The access package is visible to anyone navigating to your myaccess.microsoft.com tenant url by default. This is not good, and don’t understand why this is the default option.
Luckily we can hide it:
Now, after hiding the package, users will need to know the url https://myaccess.microsoft.com/@M365x030202.onmicrosoft.com#/access-packages/b42567ad-09e7-4f44-8d9d-b70aea813b3f in order to find the access package and request it. Try it out if you want – Adele doesn’t really respond though… 🙂
That’s it for now. Both scenarios were around external users, but of course you can also scope to your internal users.
Hope that helps someone out in understanding Entitlement Management. I will add more scenarios and stuff later. Feel free to request on twitter if you have a particular scenario in mind.
Good Workaround! 