Readers know that Attribute-based Access Control (ABAC) is a bit of an obsession with me. It stems from the want to have something like an ABAC system in my little bag of tricks. An authorization engine that scales to everyday usage, without proprietary, bloated or cumbersome baggage to weigh it down.
So I comment, lament and nothing seems to come of it.
Until I leaned that ABAC can be combined with RBAC.
We like RBAC, use it in our everyday applications, but it has some serious shortcomings, and we don’t know what to do about them.
ABAC also good. It’s adaptable, but lacks meaningful standards, we struggle during implementations, and are left wanting more.
Now, let’s somehow combine the two. Hopefully allowing the strengths of each to be preserved while eliminating their shortcomings.
What would such a system look like?
Simple apis that are easy to understand and use.
Standard data and api formats, something that can be shared between all of my apps and systems.
Flexible decision expressions allowing unlimited instance data types and values to be considered.
How would this system work?
Standards-based RBAC adheres to the NIST model, later becoming an ANSI standard — INCITS 359. Long story short, RBAC allows attributes to be applied during two separate phases of the access control decision:
1. User-Role Activation – instance data used to constrain whether an assigned role is eligible to be considered in the access control decision, i.e. permission check, that happens later. For example, user may only activate the cashier role at store 314.
2. Role-Permission Activation – these constraints apply during the permission check itself. An example is the action may only be performed if account #456789.
Apache Fortress 2.0.2 now supports type 1. For a test drive, there’s this rbac-abac-sample in Github. Have a look under-the-hood section of the README.