Identity Governance – the “Why” and the “What”
Is Identity Governance not the same as Identity (and Access) Management? Why not? Technically, what we consider as IAM stems from the need to support network-based access within a corporation, government agency or education facility. This includes tasks like provisioning an identity in Microsoft Active Directory (AD) or some other directory that works with the Lightweight Directory Access Protocol (LDAP). This would not only be done to represent the user authorized to access services and systems within the network, but also to authenticate the user by way of their password or certificate in their badge.
Access management was achieved assigning users to groups, which could be relied upon by operating systems or applications – again, all using LDAP (or even the secure transport version, LDAPS).
So, if what I’m explaining is IAM, what is Identity Governance (and Administration, or IGA)?
The governance of the identity and the access associate to the identity is more offline than in real-time functions that IAM addresses. For example, if you fail to authenticate yourself in AD, or via an Identity-as-a-Service (IDaaS) – such as Microsoft Azure AD, Okta or PingFederate – these capabilities will report back to the application (or the single sign-on, or SSO, system) that you should not be permitted to continue. This is a real-time enforcement.
IGA enables the ability to represent the identity and all its access and ownership, but not in real-time situations. For example, a financial institution may need to complete a Sarbanes Oxley (SOX) or Security Operations Center (SOC2) certification every quarter. Yes, revoking access through an access review, or certification, may result in effective termination of the access of an identity to an app or service, but there are times this decision must be facilitated more immediately than on the frequency of the access review.
In summation, IAM tends to enforce access controls, whereas IGA tends to govern what type of access an identity should have.
Microsoft Azure AD Identity Governance
Microsoft offers an IGA capability in their Azure AD service. However, it leaves every organization that wishes to use it with much to be desired. Take the identity lifecycle management capabilities found in SailPoint or Saviynt – Microsoft offers none. Of course, one could be creative and use something like PowerShell to create the same functions, or even use someone’s GitHub project, but that solution would have to hosted it somewhere – you end up, basically, building the functionality that missing from Azure AD Identity Governance altogether.
And to top it off, you cannot set any identity in Azure AD to expire at a future date. So, treating HR SaaS or HR Information Systems (HRIS) as the source of truth for identities in Azure AD only goes but so far.
Azure AD Identity Governance does, on the other hand, offer the ability to configure approval workflows for access to applications configured in Azure AD, regardless of whether the application can be signed into through Azure AD SSO. But even this leaves you with the result of one or a composition of the following:
- Group assignment
- Microsoft Teams assignment
- App assignment
- App registration
- Enterprise app
- SharePoint Sites
Essentially, the only “applications” to which a user will be provisioned with access are one or more teams in Microsoft Teams or one or more sites in SharePoint. Group and app assignments only result in the access controlled within Azure AD, such as by group or direct assignment. The user would still need to be provisioned with some type of account and permission in the third party application, which Azure AD does not support out of the box. This is also a clear difference with the likes of other IGA solutions, like SailPoint.
Azure AD Identity Governance offers the ability to configure approval workflows for access to applications configured in Azure AD, regardless of whether the application can be signed into via Azure AD SSO. While this may be useful in a self-service capacity, it is quite cumbersome for any app, group, identity governance or global admin to perform assigning users to an app via the best IGA practice.
What do I mean?
To add a member to a group in Azure AD, a group or global admin can perform the action in the following :
- Go to Groups menu
- Search for the group by name
- Click on the name of the group to update
- Click on Members on left menu
- Click + Add Member button
- Confirm the section to update the group membership
In contrast, notice how a group admin, Identity Governance admin or global admin would create the access request:
- Go to Identity Governance on left menu
- Click on Access packages on left menu
- Search for the access package
- Click on the access package that represents the application
- Click on Assignments on left menu
- Click + New assignment
- Fill out the request, select the person or people
- Submit the request
While the number of steps don’t seem to differ by much, the process is not elegant. Check out the navigation differences in the following series of screenshots.
The following image shows where a global, group or identity governance admin would go to assign access.
The following images begin to show the differences. For the next few images, the first image in the pair will show group-based assignments, whereas the following image will show the assignment via Azure AD Identity Governance.
The group membership assignment and Identity Governance access assignment at this point take a similar number of steps, namely to search for either group or the access package. However, knowing that access to an app via Identity Governance is managed by an access package is not as intuitive as looking for a group associated to an app.
Adding a user to a group is as simple as selecting the Members menu and clicking the + Add members button, but within Identity Governance, the user request must be submitted as an Assignment.
The final step is where the two paths diverge drastically. When assigning a member to a group, the task is as simple as searching for the one or more users and confirming the selection. Via Identity Governance, however, things are more elaborate and quite noticeable – and for good reason.
Microsoft should add governance.microsoft.com to allow the streamlining of the assignments and requests view for admins. Obviously, a group admin won’t have much in terms of permissions (as an Azure AD role) to access the Azure AD Identity Governance capabilities, and Identity Governance admin won’t have the permissions to make or manage group memberships. But the Global Admin can see both and may be tempted to circumvent the process, making access governance a moot effort.
Of course, the fact that the identity governance or global admin can also just bypass approvals does not help to enforce proper practices of IGA to ensure compliance enforcement. Another failing for Microsoft Azure AD.
Provisioning access via Azure AD requires the third party application to support just in time provisioning. The app roles provisioning, ironically in the Enterprise Applications menu does not synchronize the user associated to the direct or indirect role assigned to them, nor does it use the Systems for Cross domain Identity Management (SCIM) API.
IGA solutions like SailPoint offer true access provisioning capabilities, whether out of the box or by way of a software development kit (SDK).
Access Governance vs IGA
There is no doubt that Azure AD Identity Governance can immediately provide access request and reviews functions. But true IGA is all about managing the identity from creation to termination, as well as all access associated to the identity in between.
This is how we score Microsoft Azure AD on the IAM “dartboard.”
iVision’s team has thorough experience (and partnerships) with SailPoint, Saviynt and Microsoft Azure AD Identity Governance, and we’re just one click away! To get started, please fill out your information below and we’ll be in touch.