Why we need Function-based Access Control
Methodological Frameworks don’t auto-update
In the late 1980s, software developers started using the phrase “Role-Based Access Control” (RBAC) to describe the who-can-do-what feature requirement in applications. By the early 1990s, NIST had formalized both the technical and economical benefits of RBAC. The thinking that led to RBAC was probably the best possible conceptual model we could expect for rights- and permissions-management at the time it was conceived.
However, much has changed since the basic RBAC framework was first hatched. RBAC was born at a time when people still put in 20+ years at one job for one employer — so the concept of the “Role” was a reasonable focal point for security features. Object-oriented programming was still pre-adolescent. The Web was a year old. And phones were smart or portable, but not both.
A new generation of smart folk gave us Attribute-Based Access Control, or ABAC, in an attempt to update the fundamental assumptions of access-control for the present day. With ABAC, the Role is no longer the central focus, and the attributes — which can be thought of as logical constraints or conditions — can apply to either the subject (the person who can do something, or not) or the object (the asset, data or resource to which they may or may not be granted access).
ABAC is great and affords a lot of potential improvement over RBAC. It presents its own problems however. Here are a few:
- In its eagerness to get rid of the Role as the central pivot, ABAC leaves a vacuum. ABAC systems have no central pivot — great for implementing policy-compliance, less great for sustainable administration over months and years of staff changes and evolving work flows.
- Like its predecessor RBAC, ABAC does not sufficiently factor in time as a critical modifier in access control (we already wrote about this problem).
- Existing ABAC implementations don’t go far enough in addressing new software realities like cloud computing, containers, serverless architectures, or to put it in more general terms, the inevitable (if not imminent) demise of monolithic applications.
Be everywhere, but tread lightly
Access-control implementation presents many of the same challenges as authentication & user identification. Everyone benefits from advances like SSO: users don’t have to remember dozens of different passwords; application developers can reliably identify a single user across applications; IT managers can enforce password-complexity requirements because there’s only one password to remember.
Access control needs to be more like SSO. It needs to be a service, like the clipboard or the file system, that can:
- be shared across applications,
- work the same way in each of them, and
- allow policies to be expressed centrally, from humans’ point of view, not each application’s perspective.
ABAC is too Developer-centric
The bane of applications, from the very beginning, has been that developers and users often speak at cross-purposes, and in two very distinct languages. But progress has been made by both groups in the last 20 years. The advent of Web and mobile applications, not to mention a generation of young adults who have never known a world without Facebook, has produced a large population that is digitally literate.
New development and project-management methodologies such as Agile and Scrum, and emerging application categories such as Business Process Management (BPM), created a large population of “Developers with human skills.” These developers respect the importance of (visual & behavioral) design in applications; they focus more on use cases than functional requirements; and they generally show more empathy toward users in the way they build their products.
But a still-greater population of users remains digitally illiterate, and among the literate ones, awareness of specific areas is uneven. Mainstream media now cover major cyber attacks, and Edward Snowden made a big splash with his cyber-intel revelations, so a growing number understand at least the value of cryptography etc. Yet even among the digi-literati, awareness & understanding of access control is rare.
The same problem exists on the developer side of the fence. The developers who have joined “Team Human” (or started out that way) strive to bring some kind of sex appeal to their applications, and thus focus on “sexy use cases.” And access control, by its nature, proposes profoundly unsexy features.
Let’s face it: in terms of sexiness, access control is the toilet seat of functional requirements.
It would be a necessary evil, except it’s too boring to even be evil. It’s just kind of mean.
The result of all this: when it comes to access control, even the digitally literate behave like the “clueless users” of the 1980s; and developers with strong access-control kung fu tend to be less human-friendly than average.
Here’s my argument summarized in a handy little Venn diagram:
Can’t We All Just Get Along?
To sum up my amateur sociological analysis: in the world at large, an ever-increasing number of people have ever-increasing digital savvy, and an ever-increasing number of developers are becoming “human first” in their approach to application architecture, design and implementation. But many “fringe areas” — use cases and features at the edges of the digital (r)evolution — have yet to benefit from this rapprochement.
Access Control is the index patient of this problem, and ABAC is the symptom.
We Seem to Need a Verb: Function-Based Access Control
The ambition of the Hubrix team is to solve the problem of access control, on three levels:
- Technical (it has to work, it has to scale, it has to be flexible)
- Developer Experience (learning curve, ease of integration, adaptability)
- Human Experience (comprehension, ease of management, use-case diversity)
We propose to do this by building a system that puts actions or “verbs” at the center of the system, where the “Role” used to be in RBAC.
We toyed with “Verb-Based Access Control” but that seemed a smidge too poetic. We like “Action-Based Access Control” but the ABAC acronym is already taken.
So we settled on Function-Based Access Control, which is awfully plain, but clearly states our intent.
What does this mean specifically? Practically? Technically?
You’ll have to read the next blog post to find out.