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.
Authorization is a different story. The incumbent, Role-Based Access Control is broken, causing pain, use Attribute-Based Access Control instead.
ABOUT ROLE-BASED ACCESS CONTROL
Symas provides commercial support for an open source product, called Apache Fortress[1]. It’s a representation of a mature standard[2]. RBAC’s not a new trend, has been practiced for decades, pretty much everywhere. It works well but has one big problem.
ROLE EXPLOSION
It’s a widely accepted fact that 'Role Explosion' occurs 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. Infinite flexibility while remaining interoperable. Policies 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, any resource.
The attributes are 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.
"While ABAC is an enabler of information sharing, when deployed across an enterprise, the set of components required to implement ABAC gets more complex. At the enterprise level the increased scale requires complex and sometimes independently established management capabilities necessary to ensure consistent sharing and use of policies and attributes and the controlled distribution and employment of access control mechanisms throughout the enterprise."[3]
ABAC’s flexibility is both its main advantage and biggest drawback. How do you standardize on an interface that allows infinite variability?
ABAC Anti-pattern
/**
* NotSureWhat the Something Interface is an extension of.
*/
public interface Something extends NotSureWhat
{
/**
* The method that does something.
* @param things One and maybe Two, Three, Four, ...
* @return List one and maybe more objects gets returned.
* @throws Exception Dependent on what happened.
*/
<T> List<T> doSomething( Object... things ) throws Exception
}
Obviously, we use hyperbole despite pointing out an obvious fact. Too much flexibility makes standardization (functional specifications) impracticable, hence the doSomething method.
To be fair, XACML and UMA do provide for a kind of authorization. Their XML and JSON protocols (respectively) do not lend themselves to dynamic authorization at scale. Neither have gained sufficient traction to overtake the incumbent (RBAC).
We can go back further, to earlier dynamic authorization standardization attempts. Who remembers CORBA's Resource Access Decision[4]?
Today's dynamic authorization solutions are no different. They're not lacking ingenuity. One invents a Domain Specific Language to express its policies. Echoing back to the era of the Rule Engine, circa late 90's, early 00's.
Fortunately, the old wounds heal. Unfortunately, we tend to forget the lessons learned and the cycle repeats.
BACK TO THE OLD PROBLEM
We were told by vendors, at the Garner Summit, using attributes solves the role explosion problem. We tend to agree. But, that doesn’t mean RBAC must be replaced.
ROLE-BASED ACCESS CONTROL WITH DYNAMIC CONSTRAINTS
It has some desirable characteristics and is in use, pretty much everywhere. But, we need to add context without bringing complexity. If we can do that, it'll fix the role explosion problem, while preserving interoperability.
HOW IT WORKS
The RBAC standard allows, indeed prescribes[5] 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.
RBAC Code Sample (with constraints)
// Nothing new here:
User user = new User(userId);
// This is new:
RoleConstraint constraint = new RoleConstraint( );
// In practice we don't pass hard-coded key-values,
// but, you get the idea:
constraint.setKey( "organization" );
constraint.setValue( "A" );
// Followed by a little boilerplate:
List<RoleConstraint> constraints = new ArrayList();
constraints.add( constraint );
// Now, create session with dynamic constraint asserted:
Session session = accessMgr.createSession( user, constraints );
...
// AuthZ checks occur in the normal RBAC way, later:
boolean result = accessMgr.checkAccess( session, permission );
More Code Samples
RBAC ABAC Sample Project
Apache Fortress ABAC Demo Project