Third project management use case

Use Case 3 (for the two previous use cases, see Part 1 of this blog) is from a project management application in which project members can gain access to project specifications. Their access permissions depend on the project phase. Authorization rules become too complex for RBAC, which is why we are using ABAC to illustrate the use case. The business rules for the project workflow are translated into XACML via the ALFA language.

Watch the Use Case 3 recording here: 

{"video":"<a href="http://youtu.be/Yl-dtPn27xI">http://youtu.be/Yl-dtPn27xI</a>","width":"600","height":"450"}

Use case details

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. From a business perspective, however, the requirements are quite modest. This is the rule:

Project members should have access to project specification documents. If the project is in a planning phase they can create, read, edit and delete documents. If the project is in the production phase, a project steering committee must make a formal decision before a change can be made to project specifications. Project documents tagged as Public Info should be generally available.

The requirement is self-evident: we cannot have people change specifications based on which formalized budget decisions have been made without further notice. From an access control perspective, legacy RBAC-based authorization would have to be enhanced with countless checks (GetRolesForUser() with corresponding if-statements cluttering the application code to determine who can do what, why, when and how).

The use case therefore illustrates obvious ABAC values.

Conclusion of use case 3:

If the business rule requirements should be met with RBAC-based legacy access control models, developers would have to add considerable amounts of code into their applications for access control purposes. Every time a new document is being accessed, we would have to write code:

  • Every time a new document is being accessed we must consider which menu options should be deactivated client-side
  • We also need to ensure we have sufficient checks in the business logic server-side to prevent users – or hackers – to send illigitimate requests
  • If a project lead changes the project phase, we’d have to ensure user permission changes are propagated
  • We would need to have a mechanisms to provision ACLs on information assets to reflect the current state
  • etc. etc.

With ABAC, for any such event in which access control requirements impact application features, you simply fire a query. In our sample application, one query function which sends the current requet context to the PDP is being re-used over and over. It is called PDPEvaluate and returns true for PERMIT and false for DENY. 

  • UIcomponent_13.enabled=PDPEvaluate
  • if PDPEvaluate {
    // action if user is authorized 
    }
    else ….
  • etc.

The result:

  1. Faster implementation because you really never have to bother about the access control decisioning when you wirte your application
  2. Code you can maintain more easily due to this clean separation of access control concerns and functional requirements
  3. Extremely simplified change management if the business rules ever change since your application code remains unchanged – you simply change the policy

Thus: For non-trivial access control requirements ABAC is your obvious choice. Spending time and efforts to tweak your framework’s legacy RBAC-capabilities to become compliant with the actual – and often changing – business requirements means fighting a long lost cause. Go ABAC instead and have fun!



Leave a Reply

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