The Symas BlogKeeping our clients up to date on bug fixes, helpful tips, and more.
Adding Contextual Information to the RBAC Decision
Just back from Gartner’s IAM Summit in Vegas where I learned about industry trends surrounding Identity and Access Management, its problems and solutions. One thing I picked up on, we’re all good with authentication. There are many choices using standards-based approaches, pick one, they work.
About Role-Based Access Control
Symas provides commercial support for an open source product, called Apache Fortress. It’s a representation of a mature standard. RBAC’s not a new trend, has been practiced for decades, pretty much everywhere. It works well but has one big problem.
It’s a widely accepted fact that Role Explosion is a problem with RBAC implementations, or if you will, how it’s being practiced. To get at its root, we must understand the cause — context. That is the introduction of context into an access control decision is where the trouble starts. What’s contextual data? Anything that differentiates one situation from another for a given decision. For example, organization.
What happens is quite simple to imagine. We need to regulate access to a resource by that bit of context. So, a user may be a manager in organization A, but a team member in organization B.
This is when we start creating roles by context. We’ll create ManagerA and ManagerB roles, along with MemberA and MemberB. All’s well with just two organizations. Things go bad with hundreds, thousands of them. Obviously, having to manage hundreds, even thousands of roles is not a good idea.
Attribute-Based Access Control
An ABAC system provides what can be called dynamic authorization, the holy grail of secure computing. It’s viewed by some as a silver bullet. Infinite flexibility while remaining interoperable. Policies easily fit within business-like use cases. In ABAC, a role is just another attribute, which are stored inside databases, directories, behind other IAM systems, application properties, env variables, metadata files, all of the above. Whatever, wherever, all is fair game.
The locations of the attributes are hidden behind an interface called the Policy Information Point (PIP) which are then wired into policies (expressions) at the Policy Administration Point (PAP), checked by the Policy Enforcement Point (PEP), and routed to the Policy Decision Point (PDP), where the actual evaluation takes place.
ABAC’s flexibility is both its main advantage and biggest drawback. How do you standardize on an interface that allows infinite variability? Complexity always equates to hard-to-implement, thus few open source choices. This is good for the vendors and bad for us. We get stuck with expensive proprietary solutions that don’t interoperate.
To be fair, XACML and UMA do provide standard interfaces for ABAC authorization (think PEP). Their XML and JSON protocols (respectively) are fine when computing on the edge, but neither require an ABAC implementation.
Back to the Role Explosion Problem
We were told during the sessions and out on the exhibition floor (by vendors not analysts) at the Garner Summit, ABAC solves the role explosion problem. I tend to agree, it could. But, that doesn’t mean we need it, along with its complexity.
Role-Based Access Control with Attributes
We don’t have to throw the baby out with the bathwater. RBAC has many good aspects that we’d like to preserve. It’s standards-based, meaning various implementations should interoperate. It works, and is already in place, pretty much everywhere. But we’d like to sprinkle in a bit of context, allowing us to fix the role explosion problem, without breaking its interoperability, or bringing in another implementation.
How it Works
The fix was under our noses all along. The RBAC standard allows, indeed prescribes contextual data inside its access control decisions. One place, the user-to-role activation phase. Back to our earlier example of Manager and Member roles by orgs A & B. We may restrict a particular user to be a Manager at organization A, and Member at B, using just two roles instead of four.
They’re called dynamic role constraints, and have been supported by Apache Fortress since its first release, back in 2011. Then it worked with temporal data, i.e. time/date. Now it supports placing arbitrary contextual tags like organization, location, project, tenant, status, strength of authentication, etc, into the authorization decision.
If you’d like to check it out, a couple code samples demonstrating its use.
Or contact us for a live demo.