Identity and Access Management

Why has the adoption of ABAC been so slow?

A short while ago, someone asked why ABAC has been so slow to adopt on https://security.stackexchange.com/. Here’s my take below.

Top 5 reasons ABAC has been slow to adapt

  1. Companies were simply not ready. A lot of companies had to figure out their identity management story first and it looks like we’re now turning that page. See more details below.
  2. Authorization is not in the hands of a single team, rather it requires orchestration between different parties: the identity (IAM) team, security, app teams, and compliance. This dance makes it harder to find the one stakeholder capable of driving forth the ABAC initiative.
  3. The ‘boil the ocean’ syndrome: a lot of early-day ABAC projects wanted to solve ABAC for an entire enterprise rather than take it one step at a time. That hindered ABAC adoption massively.
  4. Legacy software (COTS, SaaS, and homegrown): when I say legacy I don’t necessarily mean old. Many apps and SaaS are still built with identity, permissions, roles, and groups in mind. For as long as these software don’t provide hooks to externalize authorization, implementing ABAC will remain hard. This is partly what Danny means with “Authorization doesn’t stop at the point of implementation.”
  5. Lack of standard, out-of-the-box policy enforcement points (PEP): most vendors provide you with a framework to implement fine-grained ABAC but don’t give you enforcement points. It’s up to the implementer/customer to write their own. That puts a lot of burden on the developer. Instead we need to come together as an industry and provide OOTB PEPs.

But ABAC is still worth it…

Everyone’s talking about it. Should you do it? I’m biased so I’ll say yes. But don’t take my word for it. Look at NIST’s Guide to Attribute Based Access Control (ABAC) Definition and Considerations, Gartner’s research, as well as Kuppinger Cole and Group 451. So how can you speed up ABAC adoption?

Get Authentication Right First

There are many reasons why ABAC hasn’t picked up as quickly. This year (2023), at the European Identity Conference and Identiverse, vendors, attendees, and analysts alike all said that identity management and authentication had now reached a level of maturity that would now let companies focus on the next chapter: authorization. In fact, we’re seeing a slew of new authorization vendors, stacks, and approaches in the market. In addition to the veterans like Axiomatics (ABAC, policy-based vendor), you also now have the likes of Aserto (based on Open Policy Agent and Zanzibar) and 3Edges (based on Graph).

Understand the taxonomy of authorization

Navigating the authorization waters can be hard: ABAC, RBAC, ReBAC, Graph, ACLs… So many acronyms that are hard to understand. Fortunately, my friend Alex Babeanu laid out A Taxonomy of Modern Authorization Models. This should help you understand what options exist along with their pros and cons.

In a nutshell, there are 3 main ways to achieve externalized authorization (which is what ABAC is about):

  • Using a policy language e.g. XACML, ALFA, Rego, and Cedar
  • Using a graph (e.g. 3Edges)
  • Using access control lists and tuples (Zanzibar-style) e.g. OpenFGA

These 3 approaches decouple your app’s logic from the authorization logic (that’s the end game) and they allow you to centralize authz config management and in turn audit the config or run access reviews.

My (biased) view is that policies are the best way to configure things. But, in fact, it depends on your use case.

What’s the use case for authorization?

Are you trying to save developer time? Implement complex pieces of legislation? Provide business logic? Give end-users/consumers control over their data in your app? Depending on the answers to these questions, you might want to choose different approaches.

Developer Efficiency

Your developers don’t need to implement their own DB, logging, or authentication. They shouldn’t have to develop authorization code. This is where Open Policy Agent in particular but also any (open-source) framework comes into play. It’s not so much about the breadth of the authorization solution you choose but simply its developer friendliness, its SDK support, and how much time it saves your developers. Things like audit and access reviews are nice to have but clearly an afterthought.

Comply with the law

If your app needs to comply with one or more laws (HIPAA, privacy, GDPR, Export Control, ITAR), then a policy-based approach (ALFA) makes more sense. Policies are a good way to reflect an app’s legal, compliance, or business requirements. This is how Boeing uses XACML to implement export control for instance.

This type of authorization is sometimes known as mandatory access control (MAC)

Give your app’s users options

Maybe there’s no logic to the authorization in your app. Perhaps you just want to let users decide who can do what on the data they own in your app. Think Google Drive, Docs, Photos… In that case, an access control framework at scale is what makes sense and that’s exactly what Zanzibar is. Google’s paper is just a paper though so you have to look to Topaz or OpenFGA for implementations.

Determining ownership of authorization

In the world of authentication, it’s relatively clear that the central IAM team owns identity management and authentication (though CIAM has challenged that point of view). In authorization, while a central may provide a framework for authorization, it’s the app owners, product managers, and developers who ultimately care about authorization. The requirements may be radically different from app to app. This means the central framework (if any) needs to have delegation features built into the product so that independent teams can work concurrently.

Additional Resources