Protect What Matters Most: Fine-grained, Policy-based Authorization for your Data

Introduction

When I speak to customers about what Axiomatics does (fine-grained, externalized, policy-based access control), I tell them that historically access control was implemented within each and every app or system in a very crude, technical way. That meant it was hard to maintain, update, and audit the authorization controls. Forget about answering, “Who can do what?” 

That’s where externalizing authorization to a central point of management and decision making came into place. In the early days at Axiomatics, we focused on applications and APIs: these were the first priorities for externalized authorization. If you have an API, Axiomatics will write policies that control how they can be used and what information can be retrieved through that API. Or for applications, use our SDK to call our Policy Decision Point (PDP) to retrieve authorization decisions about what your users can do on that given app.

Three Dimensions of Authorization

Little by little, though, we realized it was not all about apps, that in fact there was something just as precious and sensitive: data. With that in mind, we presented authorization in three different ways:

  1. Functional authorization
  2. Transactional authorization
  3. Data-centric authorization

A good system should address all three – ideally from a single control plane. In other words, we were starting to expand from transactional authorization into data-centric authorization and functional authorization.

What’s functional authorization?

Functional authorization is a means to check whether a given user or client can execute a given function. For instance:

  • Can Alice view documents as a whole?
  • Can Alice manage bank accounts as a whole?
  • Can Alice print?

Notice that I write “as a whole”. What I mean by that is I’m not interested in knowing specifically which documents Alice can view or accounts she can manage. I just want to know generally whether she can view documents.

Functional authorization is useful when you are trying to either:

  1. Generate scopes from Axiomatics you would then insert inside of an identity token (think OAuth2)
  2. More commonly, control access to portals where you want to enable or disable features / widgets / buttons / menu items…

What’s transactional authorization?

This is without a doubt the most widely used and well-understood type of authorization. In transactional authorization, a user or client is attempting an action on an item. They are trying to run a transaction. For instance:

  • Alice wants to view document #123
  • Alice wants to publish document #123
  • Alice wants to approve payment #123
  • Alice wants to edit claim #123

In transactional authorizations, we always know:

  1. Who the user / client is
  2. What the item they want to get access to is (both the type e.g. payment and its identifier e.g. 123)
  3. What action the user wants to perform on the item (print, view, delete, transfer, approve..)

When I mention that, in the early days, we focused on APIs and apps, what we primarily delivered was transactional authorization. It’s what XACML was designed for from the get-go. There is a perfect fit between the XACML / ABAC architecture and transactional authorization.

That said, controlling access to transactions is not always enough. Sometimes, we want to control access to the data itself even before we start working on it. This is where data-centric authorization kicks in.

What’s data-centric authorization?

Transactional authorization works well when we want to control access to a known, relatively small subset of items (data entries). Small could be in the hundreds or thousands but not typically beyond that.

So… what if we want to control access to an unknown number of items or a large set of items? I cannot possibly iterate through a list (given I don’t know it or it’s too large). What if I want to dynamically filter data out? How can I apply the same fine-grained access control to my database? This is where data-centric authorization kicks in.

Rather than send a binary authorization request (Can Alice view item #123?), we are going to send open-ended queries such as “tell me which records Alice can view”. And rather than receiving a Permit / Deny, the authorization service will return a set of filters expressed in the relevant language. More on that in Part 2.

To sum up…

For comprehensive protection, you want to apply authorization in depth (think defense-in-depth) and have checks on the functional side (inside a portal), on the transactional side (inside an API for instance), and on the data side. They can all work together and can all be driven from the same set of policies.



Leave a Reply

Your email address will not be published. Required fields are marked *