Download your copy of our State of Authorization: Playbook Edition Get it now »

Q&A: IGA vs Access Management vs Authorization

Our Head of Product Marketing and Chief Technology Officer discuss the difference between identity governance administration (IGA), access management, and authorization.

We recently sat down with our Head of Product Marketing, Jamie Manuel, and Chief Technology Officer, David Brossard, to discuss the difference between identity governance administration (IGA), access management, and authorization.

What is the difference between IGA, access management and authorization?

Jamie: I view access management as a component of IGA. Access management is where the rubber hits the road in terms of actually enabling the user to get access. Authorization can also be viewed as a component or element of IGA. Authorization is about providing the appropriate decision/analysis of whether or not the user should have access to something or to perform an action. They are equally important parts of the IGA model and while many only focus on the access management component, you really aren’t satisfying the governance aspect of IGA if you don’t also address the authorization component.

David: It depends on how broad your definition of IGA is, but in my mind the bigger family is identity and access management (IAM). Inside of IAM, you have things like role-based access control (RBAC), fine-grained authorization, user management, strong authentication, and IGA.

A typical IGA solution has specific advantages, but it is like a bandage approach when it comes to authorization. IGA helps manage users, roles, entitlements, and their assignments more efficiently but it doesn’t help with the expressiveness and transparency of the authorization configuration. It also scales poorly and does not mitigate the role explosion challenge observed in role-based access control (RBAC). This is where you need policies and attributes that policy-driven authorization provides.

Access management is a broader field aimed at making sure people have access to the right thing. In access management, you might define your model by saying you are going to use a corporate (business) policy that determines which roles get access to which business applications. Access management also refers to identity federation (think Siteminder back in the day and SAML – single sign-on across a slew of enterprise applications). You would join a company, get a computer and be given credentials. Prior to single sign-on (SSO), as you needed access to different things, you needed more credentials. Access management tackles keeping track of the credentials and access granted users.

Some vendors in both IGA and access management talk about solving solutions in a way that sounds like they offer authorization. What are the most common misconceptions you hear?

Jamie: I have marketed several IGA solutions in the past and I would use terminology that I now understand to be very confusing in terms of how it relates to the authorization we are talking about here.

I think there is an established misconception that authentication is all you need. People think that authentication covers what authorization does because it looks at “admin-time authorization”. Days, months or even years ago, someone decided that anyone in this role is “authorized” to edit records in this application. Therefore, when my authentication solution checks to see whether or not the user is in an “authorized” role, I’m covered. Therefore, I already have authorization covered, right?

WRONG. Because admin-time authorization is based on a decision made long ago and only based on one attribute – the role – it doesn’t take into account current risk levels, whether that user should still be in that role, and a multitude of other things. It is using the word authorization, but defining it differently.

I also think a lot of the confusion comes from how the recertification process is marketed. During the recertification exercise (or attestation report), managers can be asked whether or not these users should still be “authorized” to retain their access. It’s using the same word, but again, a slightly different definition.

David: I agree with everything you said, but I would add on one more thing. When we talk about authorization here at Axiomatics, we think a lot about the application, the API, and the data. We think in terms of digital identity and digital assets. In fact, authorization and access management extend into (or even stem from) the physical world: the devices you have, the buildings you can access, the badges you are given.

We know enterprises invest a lot in deploying IGA and access management platforms and solutions. Where can authorization offer more value for that investment?

David: If you have the luxury to rewrite your applications systems from scratch, so you could use policy as a means to drive authorization then we would be in a perfect world. If that policy can reflect the original business, compliance, or legal intent, that’s even more perfect.

The challenge with an IGA is that it accepts (dare I say encourages) the fact you have clunky and different authorization models depending on the application, frameworks and processes you are dealing with. This makes it hard for a manager to do access recertification of an employee or their direct reports’ entitlements. The manager thinks they know and do trust that the employee has the right things. The employees themselves do not necessarily know what the permissions they have represent; you just want to make sure your job doesn’t fall apart if someone removes an entitlement from you.

The whole IGA process is broken from that point. When you start to look at how things are configured and hope it is configured the right way, it really shows how messy it is. It highlights that the traditional way of doing authorization and getting by with an IGA is not a good fix. It is just putting a bandage on it.

Jamie: Real-time context. The key distinction in the above “authorization” that many IGA solutions talk about, versus what we do is around the time of when the authorization decision is made, and what attributes are being considered to make that decision. For an example of this, imagine each of your applications as a hotel, and that your entire enterprise is a full chain of hundreds of hotels. The granularity required to manage access runs from low to high.

On the low end, a guest needs to enter their room, if they have the keycard and the right room number, it will provide them access. That’s the simple case that a typical IGA solution can manage as well. But let’s say you want to limit which floors a guest can access, and you want to ensure they can access the loyalty lounge which is on a different floor, and you want them to be able to get a free alcoholic drink in the lounge, BUT only if they are of drinking age and so on… As we keep going higher in the access granularity, we can see that it can get very specific and require real-time context to handle different outcomes, even for different guests in the same room/reservation.

Fine-grained access-granularity access example using hotel access as an example with Axiiomatics

What are some things people should take away from this?

David: First, I always like to start by saying IGA is good and organizations need an IGA, but it isn’t enough. They have to go beyond the idea of anything that’s identity-centric is great.

If enterprises want to have meaningful entitlements and authorization, writing policies in plain old English is important as you want the policies to be easy to understand over time. This is why organizations should add authorization onto their IGA.

Lastly, IGA and authorization work hand in hand, so it is best to integrate them.

Jamie: First, if they do not have a real-time point of access authorization solution, they are not addressing authorization properly. They are lacking the ability to include context in their decisions.

Secondly, authorization solutions close the risk gaps that regular access management solutions miss because authorization solutions  operate in real-time, based on real-time attributes to provide the necessary context.

Lastly, aside from the security/risk benefits, authorization can provide serious benefits to your users by adapting the user experience to their specific use cases, identity and needs. This can be a very real differentiator for your users whether they be internal or external.

Want to add into your IGA solution?

Request a demo to learn how a policy-driven authorization solution can increase the value you get from your IGA solution, decrease your organization’s risk level and is flexible enough to grow to meet future needs.

In the meantime, download our white paper to learn how an authorization strategy can fill in gaps and help IGA reach its full potential.

Have 30 minutes? Let's show you a demo!

See how our award-winning solution can help you meet today's access control and Zero Trust needs.

Request a demo

  Join us on LinkedIn for more insights
Archived under:
About the author

As the Marketing Communications Specialist, Emme Reichert helps execute content that resonates with customers, partners, and influencers. She has experience with marketing in the healthcare and tourism industries.