What is a suggested roadmap towards implementation of a simple Attribute-based access control (ABAC)?

Question

When reading about ACL and RBAC I seem to understand it easily - there are either usernames or roles that are given access to an asset. I can also see how I could implementing those.

i.e. this image gives a clear view of ACL and RBAC for me (as in I can go on and design database tables based on above): (Image courtesy of pressbooks)

What I am struggling with is ABAC. Various images I found so far are hand-wavy or overly complicated, or suggest using a 3rd party external entity do Authorization. Or give weird attribute examples I am not entirely certain how to use.

Starting Example

So let me start with something in real life. Say I have a company with 70-200 people. And my asset to protect is a website with many various pages. I wish to allow certain people access to certain assets.

For example, I want a person Leslie to have access to a web page called Price Manager, and allow her to only manage prices for the Travel price group on that page, but not be able to manage prices for Product group on same page. How would I implement this using ABAC?

Poking around so far, my guess is I could assign Leslie some attributes (but which ones and what are these attributes?) and then have a database table storing those. I can then design an engine that looks at those attributes (but does not look at Leslie as a "Role" as is done in RBAC), and decides from there whether or not to grant access to the page. How would that engine look like? Is it a simple if/else block? Something else?

What happens if Leslie later changes her position and someone needs to change her access? What will it look like if she needs to have access moved from Product and revoked for Travel? How will it be coded if she needs to have access revoked to the Price Manager page altogether and hence no longer have access to neither Travel, or Product?

The asset in my case, just to restate it, is Price Manager, and a user can access various price groups on that page, such as Travel pricing, Product pricing, etc.

What I am looking for is a reasonably complete roadmap towards clarifying the details and towards implementation to where I could go off and implement it without guessing. i.e. it could be completed conceptually and/or have specific example to where I can visualize a database structure, etc.

Bonus: Is ABAC a proper way for a relatively small permission needs i.e. managing 70-200 people & access to some 150 - 450 assets? Will it be better to stick to ACL/RBAC instead?

Answer 1

An ABAC implementation is more complex than ACL/RBAC. Some frameworks even give you bits of infrastructure to deal with the latter. If the people and assets can be grouped under a relatively small and fixed number of roles/categories then it's probably best to stick with ACL/RBAC. If permissions differ vastly from person to person then ABAC could provide a better and more flexible solution.

If you choose to go down the ABAC path the first thing you need to do is spend some time reading and understanding the XACML standard. The examples provided in the document use XACML compatible syntax and they're a bit tough to chew at first. I'm guessing you don't want to implement a standard compatible solution so you only need the general ideas from it.

Concepts

XACML revolves around 4 concepts and their attributes: subjects, actions, resources and environment. There are a few more, but these are the most important. Everything else is built on top of them. If I were to make a sentence with these concepts it could be something along the lines of: subjects perform actions on resources in a certain environment. Applying this to your scenario would translate into something like:

• Leslie opens the price manager web page.
• Leslie creates a travel price using the price manager web page.

Attribute collection

The first thing we need to do is gather the relevant attributes of the concepts stated above. Ideally, you should not be assigning any specific attributes as XACML tries to be unobtrusive and rely only upon what the system naturally provides. And so we have:

Subject

Any actor, be it a person or a service, in your system. Our subject is Leslie. What attributes are required to uniquely identify Leslie? Probably some of the following: first name, last name, e-mail, ssn, company id, position(s).

Action

Any action performed by the subjects. Can be the standard CRUD operations or something more complex. Our actions are open/view and create. The attributes for these actions can be different based on web application framework you're using. We'll talk more about this when we get to the resource.

Resource

Pretty self explanatory. Our resources are the price manager page, travel prices and the newly created price. There could be more, if you really want to. You may want to hide actions that the users can't perform. Eg. the create price button can be a resource that can be shown/hidden based on whether the user has permissions to create prices. Since the only way for a user to see a list of prices could be through this page it would probably be a good idea to enforce authorization at this level rather than further down the stack.

Access to resources is the most complicated to implement, especially on the ones that come from a database. The finer grained option is row-level security. Some databases have a certain degree of support for it. Some XACML implementers have gone as far as creating a SQL superset. This really depends on your authorization needs but the one thing you don't want to do is pull everything from a table and then decide what to show. You could group resources by permission sets, abstract them behind an API and enforce authorization at the API endpoints.

Environment

I can't properly define it (XACML also doesn't have a proper definition) but let's say it's the "bubble" in which all this happens. This includes: web application, web server, operating system, browser, office. You could extract attributes like: ip address, time of day, user locale, user agent, operating system version. You can use these to even block user access from environments that are not supported by your application (eg. old browsers, old operating systems, computers outside of your network, access outside business hours).

Authorization request

Once we've gathered all the necessary attributes we bunch them up in an authorization request and forward it to an entity that can make authorization decisions based on the values of these attributes. In XACML lingua the place where you collect these attributes and enforce the decisions made upon then is called a policy enforcement point (PEP) and the point making decisions is called a policy decision point (PDP). The locations from which attribute values are obtained are called policy information points (PIP). PEPs, PDPs and PIPs can be a part of your application of they can be external systems. You can find a diagram of how they communicate with each other in the XACML standard.

Decision process

The decision making process is based on rules. Rules can be grouped into policies which can be further grouped into policy sets. Each of these has a target. The target is used to decide if any of the rules apply to the authorization request. Think of it as a filter. The target contains conditions built using attribute names and values. For example, the rules for your application could be grouped into something like:

Web application (policy set)
|-- target: application-name == "Web application"
`-- Version 1.0 (policy set)
    |-- target: application-version == "1.0"
    `-- View price manager (policy)
        |-- target: web-page-name == "price manager" && action-name == "view"
        `-- Leslie can view the prices manager (rule)
            |-- target: subject-name == "Leslie"
            `-- permission: allow

The PDP will match everything in the above set against the attribute values in the authorization request. What happens if there aren't rules that match it depends on the implementation of your PDP. Once the PDP has made a decision (allow, deny or not-applicable) it sends it back to the PEP which acts upon it by granting or denying access to the resource. Along with the response the PDP can send a list of obligations and advices that the PEP must or should fulfill in the enforcement process. Depending on how the rules are stored (text files or database) an administrator can use a standard text editor or a custom editing application to change these as he/she sees fit. Revoking Leslie's access to the prices manager resumes to simply changing permission from allow to deny, granted the PEP does its job.

Enforcement

This is highly dependent on your technology stack. Some web frameworks have natural enforcement points (eg. ASP.NET MVC has attribute filters). Your business layers might have to define such enforcement points. I found it easier to apply enforcement at service (think microservices) endpoints or UI level.

Other benefits

A nice side effect of implementing this is that you end up with a fairly rich audit trail which can be used for other purposes.