Getting ready for talk at ApacheCon next week. The slides are here: anatomy-secure-web-app-acna-2018-v5.
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.
Created a new project corresponding with earlier blog post, rbac with abac…
[Link to the Apache Fortress RBAC-ABAC-SAMPLE project on Github]
We’ve all heard the complaint, RBAC doesn’t work. It leads to Role Explosion, defined as an inordinate number of roles in a production environment. Nobody knows who must be assigned to what because there are hundreds if not thousands of them.
What’s a system implementor to do? We could give Attribute-Based Access Control a try, but that has its own problems and we need not go there again.
There’s another way. RBAC allows the usage of dynamic attributes.
- Recent standards include dynamic policies, most notably, ANSI INCITS 494 RBAC Policy-Enhanced
- The existence of entities to conveniently apply dynamic policies, e.g. User-Role and Role-Permission.
- No language discouraging the usage of dynamic attributes alongside RBAC in the standard.
Indeed, dynamic attributes are encouraged if not prescribed. Here’s where I should be pointing to evidence substantiating my arguments.
This brings us to Apache Fortress and a new enhancement to use dynamic attributes.
What is Apache Fortress?
Both followers of this blog (wife and boss) know about Apache Fortress. Especially my wife. It’s the itch that leads me to three years of work in a garage, alongside two of my brothers, who got dragged in also.
It’s also an implementation of the classic RBAC specification – ANSI INCITS 359. If anything’s prone to exploding roles, it’s Apache Fortress.
How are we going to stop the dang exploding?
The Tale of Three Stooges and Three Branches
Once upon a time there were three branches, North, South and East managed by The Three Stooges that worked there, Curly, Moe and Larry.
They were nice blokes, but a tad unruly, and so we try to keep them separated. Curly works in the East, Moe the North and Larry runs amok in the South. All three are Tellers, but each may also substitute as coin Washers at the other two.
All is well because each Branch has only one Teller. It’s never good when two Stooges combine without one being in charge.
Here are the Users and their Role assignments:
Curly: Teller, Washer
Moe: Teller, Washer
Larry: Teller, Washer
By now we know where this storyline’s headed. How do we prevent one going off-script, wandering into another branch, activating Teller, and running slipshod?
The classic Role explosion theory goes like…
Create Roles by Location with User-Role assignments:
Curly: TellerEast, WasherNorth, WasherSouth
Moe: TellerNorth, WasherEast, WasherSouth
Larry: TellerSouth, WasherNorth, WasherEast
This works pretty good with three branches and two roles but what about the real-world? How many branches will the medium-sized bank have, a thousand? How many types of roles, at least ten? If we follow the same Role-by-Location pattern there’d be over 10,000 Roles to manage! We may be keeping our Stooges in check, but at the IT team’s expense. Our roles have indeed exploded. What now?
Time for something different, back to the earlier discussion over using attributes. Let’s try controlling role activation by location, but store the required attributes on the user object itself.
User-Properties to store Role-Locale constraints:
Curly: Teller:East, Washer:North, Washer:South
Moe: Teller:North, Washer:East, Washer:South
Larry: Teller:South, Washer:North, Washer:East
What just happened here? It kind of looks the same but it’s not. We go back to only needing two Roles, but have added dynamic policies, Role-Locale, to properties stored on the User. Our medium-sized bank only needs 10 roles not 10,000.
Now, when the security system logs in a User (createSession), it pushes its physical location attribute into the runtime context, e.g. North, South or East, along with the already present Userid attribute. The security system compares that physical location, along with its corresponding properties stored on the User, to determine access rights, specifically which Roles may be activated into their Session.
Sprinkle in a policy that defines the role to constraint relationships.
Global Config Properties store Role-Constraint mappings:
That way when the security system activates roles it knows to perform the extra check on a particular role, and which attribute to verify.
In addition to location, we can constrain role activation by project, organization, customer, account balance, hair color, favorite ice cream, and any other form of instance data imaginable. There may be multiple types of constraints applied to any or all roles in the system. It truly is a dynamic policy mechanism placed on top of a traditional Role-Based Access Control System.
With this minor change to the security system, our IT guys return to the good life without worrying about exploding roles or what the Stooges are up to. 🙂
Frequently debated within info sec circles. Which one of them is better?
Use the right tool for the job as they say. RBAC, like any access control model, has its weaknesses. Many are well understood, even discussed by the original NIST team who framed the model.
However, there are a number of common fallacies wrt how RBAC works. For example…
1. RBAC is static. It cannot use contextual information e.g. time, user location, device type.
Constraints are commonly applied during user, role and permission activation in RBAC. For example, placing temporal constraints on a role activation. Indeed INCITS 494 prescribes their use:
5.4 RBAC Policy Enhanced Constraints
Enhanced constraints go beyond the INCITS 359 RBAC Standard by including additional types of constraints. Constraints on roles may be static or dynamic. Static constraints are applied off- line before the role is activated by the user. Dynamic constraints are applied on-line after the role(s) are activated. These enhanced dynamic constraints can introduce attributes into the RBAC environment.
INCITS 494-2012, p. 8
2. RBAC cannot perform dynamic segregation-of-duty.
RBAC supports dynamic SoD constraints. From the spec:
5.3.2 Dynamic Separation of Duty Relations
Dynamic Separation of Duty Relations Static separation of duty relations reduce the number of potential permissions that can be made available to a user by placing constraints on the users that can be assigned to a set of roles. Dynamic Separation of duty (DSD) relations, like SSD relations, are intended to limit the permissions that are available to a user. However, DSD relations differ from SSD relations by the context in which these limitations are imposed. SSD relations define and place constraints on a user’s total permission space. This model component defines DSD properties that limit the availability of the permissions over a user’s permission space by placing constraints on the roles that can be activated within or across a user’s sessions.
ANSI INCITS 359-2004, p. 10
3. It relies on custom code within application layers (API, apps, DB…) to implement finer-grained controls.
Presumably what is meant here is that custom code must be written because RBAC controls don’t adequately satisfy security requirements for authorization.
Where are ABAC’s published functional specifications? Where are the standard object (data) and functional (api) model for computing (and storing) its decisions?
Perhaps it is better to use a proven, non-standard ABAC implementation than a custom app widget? If that is what is being said then I agree, but neither are ideal.
ABAC has its place as does RBAC. Knowing when to use one, the other, or both, is important. Understanding the limitations and strengths of each is crucial before adequately addressing the challenges we face as security practitioners.
As a security architect I have long-awaited the means to express authorization policies using dynamic constraints – in a standard way. Over the years there have not been many models to choose from.
What do you think about XACML?
Now the buzz is Attribute-Based Access Control (ABAC).
Blurring the lines, supposedly XACML implements ABAC, because attributes combine with decisions.
There are commonalities across the three models:
- Grammar to express very fine-grained access control policies.
- Rules containing variables captured from subjects and resources. Facts such as location, time and date included.
- Adjudication when rules combine or clash.
- Separation into multiple components, e.g. Policy Enforcement Point (PEP), Policy Decision Point (PDP), Policy Information Point (PIP).
The promise is reuse.
So where are the functional specs? I must understand and share.
“Despite the clear guidance to implement contextual (risk adaptive) role or attribute based access control ABAC, to date there has not been a comprehensive effort to formally define or guide the implementation of ABAC”
NIST – ATTRIBUTE BASED ACCESS CONTROL (ABAC)
Until formal specifications are drafted, ABAC is useless because it’s non-standard and/or proprietary.
Back to square one – awaiting an industry standard dynamic authorization model.