In the first part of our Identity Governance Blog series, we talked about how Azure Active Directory has supported sign-on experiences to third-party applications for many years and discussed how automated provisioning is streamlining JML processes when a supported HR solution is used.
In the second part of our series, we’ll take a look at how to manage access with entitlement management. Firstly, I’ll introduce the concept of access packages within Azure AD. Essentially we’re using an access package to group the following three resource types – Groups and Teams, Applications, and SharePoint Sites.
NOTE: At the time of writing this blog (Summer 2021), the above three resource types are available. Expect public preview functionality to launch very soon to include Licensing, Azure AD Roles and Power Platform. This can be accessed today here.
Let’s think of this in terms of an actual group of resources we’d want to template for a team. In my example, I’m using the Marketing department. Any user who’s in the Marketing department should have access to core resources that are controlled by Azure AD security groups, SaaS applications linked to Azure AD and, of course, a few SharePoint sites. Each selection will pick up associated roles/permissions, with the resource to allow further granularity as I need.
The often-overlooked part here is that whilst we are restricted to these three resource types above, being able to add users into certain groups unlocks A LOT of potential elsewhere. For example, applications in terms of an access package are in the context of an Azure AD application but by adding a user into a security group, I could easily assign Endpoint Manager resources to this group.
By creating this access package, I now have a ready to use template for the Marketing Team that gives them access to the core resources they need. Even as it is, my access package is a single configuration item that I can update in a central location as new resources are needed by the Marketing Team and have them assigned to everyone that needs it in one change.
This may feel very similar to having a single “Master” group in Active Directory, and at this stage I guess it is. But we’re only just getting started with what’s possible.
Once I have my resources defined, I moved on to my request policy. Here I can define how I want this access package to be requested or assigned. I could take the view that actually I want this to be by direct assignment only – and therefore assignable only by administrators – or I could have it available to all users (scoped further by specific users or group members) with further choices on external users (including whitelisting by partner domain).
If I want this to be requestable by users, I need to decide if this follows an approval process or not. A word of caution: without an approval process, users will be able to freely assign themselves the package. This may be desirable for some, but not all. What follows are options to define a single or two stage approval process, whereby I can call a request to the users manager (based on Active Directory) or to one or many specific users or groups.
With my approval policy now defined, I can request that the user provides some additional information. This could be simple text or multiple choice-based options that may challenge the user for some basic information or justification, and is entirely optional when we create the package.
The final settings available when we create our package is to define the standard lifecycle of access. It may be that we want this to be a permanent assignment – very much in the same way normal group access would be provided – but in my example, I want to mix it up a little.
Enter access reviews. I can configure an access review on any package to have either users themselves, the user’s manager or other designated users review access on a time-table that suits. This all stacks up nicely to prevent users from having unchecked access for long periods of time. Alternatively, I can simply ensure that assignments to my access package expire after a certain time.
So now my package is created and assigned as an item users can request via the dedicated My Access portal, where users and approvers can handle every step of the process we’ve gone through today.
So hopefully this gives you a few workable scenarios to working access packages into your delegation of applications, groups and many more resources within Azure AD. One final devil of detail will be licensing.
Licensing for entitlement managed is thankfully quite well defined with users who want to request, approve, or review access packages needing P2 licensing. Guest users will also need to be covered under your guest user licensing model however administrators do not need additional licensing to manage any step of the process.
Want to know more?
For a complimentary consultation with a Transparity expert, just click below and we’ll be in touch!