How such high-level business requirements translate to ABAC on a technical level is not always obvious. The blog post series use a sample application to illustrate the difference between existing, often role based concepts, and ABAC to examine when the latter can be motivated.

The application used to illustrate authorization concepts is very simple. It is a Windows-application written in the object-oriented version of Pascal used by Embarcadero Delphi. Axiomatics SDKs provide rich toolboxes for Java or C#. For the sample app, however, I decided to only use the web services API of the Axiomatics PDP (Policy Decision Point). The reason for this was that I wanted a) to verify that we easily can adapt ANY programming environment to use externalized authorization via these APIs and b) because I liked the RAD capabilities which matched the objectives of this blog. For other language samples, I’d recommend David Brossard’s various blogs, such as the one on using XACML with Perl.

Project management use cases

I have intended to illustrate authorization models based on use cases which in turn are based on somewhat tweaked real-world scenarios. In this first part we are looking at use cases that do NOT necessarily motivate a shift to Attribute Based Access Control:

Use Case 1: A project supplies ordering portal with minimal authorization requirements. Here we could actually manage with authentication only – dynamic authorization is not needed unless…

Watch the Use Case 1 recording here: 

{"video":"<a href="http://youtu.be/Y30HFRPJLpw">http://youtu.be/Y30HFRPJLpw</a>","width":"800","height":"600"}

Use Case 2: A simple interface intended to grant department managers access to project documentation within projects they are sponsoring. In this use case we use Role Based Access Control (RBAC) and look at its benefits and limitations. 

Watch the Use Case 2 recording here: 

{"video":"<a href="http://youtu.be/BgHd-PUKjew">http://youtu.be/BgHd-PUKjew</a>","width":"800","height":"600"}

Use case details

If authentication is all you need, never mind ABAC – unless…

Most real-world applications are rich in functions but tend to be lacking fine-grained authorization capabilities. Our sample application takes the opposite approach – it implements a variety of authorization techniques but is rather barren when it comes to real functionality. In the first video the sample app is used to examine the relation between authentication and authorization…

Conclusions of use case 1:

  • If you don’t have complex authorization requirements, chances are you have little to gain by switching to ABAC unless….
    • … permissions to log in vary dynamically over time or depending on a broader context such as the state of data in other applications.

Can all of the use cases your application must support be well implemented in spite of your framewok’s RBAC limitations? 

The second use case uses RBAC. When you write a new applications you never start from scratch. You are coding in some kind of framework such as Java with Spring security, Python with some fullstack web application framework, C# in a Microsoft environment with claims, and so on. Legacy authorization models supported by your framework are probably, like in these examples, based on the RBAC concept.

Conclusions of use case 2:

Our second use case looks at a corner case. Is it manageable with RBAC? Answering this question typically determines whether you have a business case for ABAC. This is the generic answer:

IF

  1. the framework you are using to develop your application provides easy-to-use methods/objects to implement role based access control and
  2. the application does not have more dynamic or complex authorization requirements than what you can manage with these tools and
  3. you also feel comfortable that future versions are fine with static definitions of user permissions

THEN there may not be much value in considering Attribute Based Access Control.

On the other hand:

  • The access rules which your RBAC settings invoke are static and inflexible. If the permissions granted to a role may become dependent on other conditions or external factors dynamically, the model fails.
  • To compensate for limitations you may have to create very many roles and/or write additional code to modify the RBAC model to make it context-aware.

If these problems are considerable, you probably do have a business case for ABAC.

Use Case 3: If your applicaton has non-trivial access control requirements, you have a lot to gain by switching to ABAC

Our third use case comes with an access control requirement which from a technical perspective is a bit more elaborate. It will use ABAC to illustrate how you can manage a business rule that definitely goes beyond what a conventional RBAC model can handle. For details, see Part 2 of this series.



Leave a Reply

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