Why Identity Governance needs authorization controls

Identity Governance is a powerful tool in the hands of an organization. It helps govern access and authorization, provides separation of duties for critical tasks, and even handles privileged access to ensure that only those entitled can do certain things. But there’s one big problem that identity governance doesn’t address: authorization controls. With authorization controls, organizations can enforce policies on how entitlements are assigned across their enterprise, ensuring that only those with appropriate privileges get them. This blog post will discuss why identity governance needs authorization controls to be truly complete!

Authorization controls provide a logical enforcement point for entitlement assignments, which are specified in identity governance policies. This can be done by implementing authorization rules to determine what types of users access data and functionality they need across the enterprise. If you’re thinking to yourself, hey, that sounds a lot like the rules you implement in identity governance systems, you would be correct. The issue is that the rules are trapped in the identity governance systems and aren’t accessible at enforcement time. For example, if you wanted to enforce that no one but executives has access to financial data — or any information about finances — then you would implement an entitlement policy in the IGA system that ensures that only executives can be assigned entitlements grant access to financial data. Let’s say that those entitlements are groups within Active Directory. The first group is called Finance-All, and the second group is called C-Suite-All. The policy created in the IGA system would ensure that only executive users could be assigned the Finance-All and C-Suite-All groups, but that’s where it stops. The IGA system would not be able to enforce that rule whenever the application is accessed.

The issue is that the rules are trapped in the identity governance systems and aren’t accessible at enforcement time. For example, if you wanted to enforce that no one but executives has access to financial data — or any information about finances — then you would implement an entitlement policy in the IGA system that ensures that only executives can be assigned entitlements grant access to financial data. Sounds good, right? You’ve got protection on both sides, and you can wrap this up and go home. Not so fast, my friend.

You still have an issue that leaves a gap in your protection.

There is a potential for the governance system and the authorization policies to be out of sync because governance systems poll the backend applications for data and don’t control admin access to the application. In our example above, the Active Directory system can still be accessed by an administrator or any other application and make changes to the Active Directory system itself. The governance system would not see these changes until its next polling event. So if a change were to happen to the Active Directory account of a user, in between the polling times of the governance system, then the user could be assigned improper access. You solve this issue by making a deeper connection between your authorization policies and your governance system. Update the authorization policy to check for the user’s group memberships and respect the identity view as reflected by the governance system. If the governance system doesn’t reflect the user’s group membership, then that would be the authoritative view for the user. Now you have complete enforcement of your policy that a user cannot access financial data unless they are an executive in the company. The governance systems ensure users aren’t assigned improper access and authorization policies to ensure that if a user does get assigned improper access, it is still enforcing policies with the attributes available from the governance system.

This was just one example of the use cases we can solve by connecting IGA systems to authorization policies. Given a mature IGA deployment, 100’s hours have been spent implementing separation of duty policies, role compensation policies, and entitlement policies that govern how users can be assigned access within an environment. Why let all of that effort go to waste by not having those policies enforced where they matter the most? So as you start to go down the path of deploying an authorization solution or (gasp) building your own, make sure you talk to your identity team and understand the work that’s gone into the IGA system. Make sure you take some time to understand the policies and make sure you are providing complete protection for your applications and your data. Together IGA and authorization are a match made in heaven and ripe for integration. Let me know how you’re tackling your authorization issues in your environment and what conversations you’ve had with your identity team.