Let me first give you a short introduction to Access Control Lists (ACL). In software, an ACL, is a list of permissions granted to subjects on an object, where the subject might be Bob or Alice and the object might be the vacation calendar. The ACL is (typically) attached to and administered on the object and (again: typically) each list entry contains a user or a group and a permitted action such as ‘read’. Simpler lists contain the user identity only which means all actions are possible.

Now, you might see ACLs in anything from Google Docs, routers and switches to operating systems and proprietary and COTS software. If you haven’t: right-click (I am assuming you are on Windows) on a resource on your desktop and click ‘properties’ and then ‘security’ (tab): you see, given the current resource (object), a list of users/groups, and the actions upon the given resource as granted to those users/groups (subjects). Good, that’s the gist of it and now we can all relate to the topic at hand.

The Evolution of Access Control

A lot of times when we take part in a project, a customer is starting from a basis they have. It makes sense of course: access control has been around since the dawn of man and even in computer systems, we’ve had the evolution of MAC, DAC, RBAC (…) and so while Attribute Based Access Control (ABAC) enables both externalized, incredibly fine-grained, and dynamic/adaptive access control, more often than not: initial work will relate to what the customer has and what the customer knows. And everybody knows ACLs.

An Access Control List in ABAC

Scenario

Coming back to my simple example then, let’s take the vacation calendar and say that Bob can read it and Alice can read and write from/to it. We might depict it something like this:

Vacation Calendar
User Read Write
Bob Permit Deny
Alice Permit Permit

 

Sample ALFA Policy

In ABAC and using the ALFA pseudo code language, this might look like:

/*Vacation calendar*/
policy vacationCalendar{
          target clause resource.resourceId == “vacation calendar”
          apply firstApplicable

           /*Bob can Read* /
          rule BobCanRead{
                   target clause userId == “Bob” and actionId == “read”
                   permit
          }

          /*Alice can Read and Write*/
          rule AliceCanReadAndWrite{
                  target clause userId == “Alice” and actionId == “read” or
                  actionId == “write”
                  permit
          }

          /*Deny all other access*/
          rule denyAll{
                   deny
          }
}

 

Using the Axiomatics web-based policy editor the same ACL might be expressed as follows.

Considerations

Do note that in both examples, this ACL might be (is likely) a very small part of a larger application wide or even enterprise wide policy set.

Note also that this example (above) is provided simply to prove a point (ABAC can implement ACLs): a “real life” implementation would likely be both more granular and more dynamic. You might have an ACL “layout” as above where the authorization engine (Policy Decision Point) effectively goes through a list in a resource-centric model from top to bottom, but you would use groups or roles resolved from information sources (Policy Information Points) in real-time and you would likely want to look at things like subject and object relationships (Bob can view the vacation calendar for his team members only or for his region…). And that’s just scratching the surface of how the traditional ACL can be both implemented – and enhanced using ABAC.

Conclusion

So to recap: Attribute Based Access Control (ABAC) can implement ACLs with ease. In fact ABAC, and especially the solutions from Axiomatics that do not force the hand of the policy writer (some competitive solutions permit only a specific resource centric workflow for example), can be used to implement ANY access control logic. There is, in theory, nothing that ABAC cannot do.



Leave a Reply

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