From Groups to Roles to Context: The Emergence of Attributes in Authorization

Last week, I introduced my favorite topic—digital context—and laid out a plan for how to consider the case. Today, we’ll dive in with a real-world example, looking at how freeing context from across application silos helps us make more considered, immediate, and relevant access control decisions. For those of you who have been following along (and thanks for sticking with me in my madness), this is blog 8 in response to Ian Glazer’s provocative video on killing IAM in order to save it. And if you haven’t been with me from the beginning: I’m in favor of skipping the murder and going straight to the resurrection.

It All Starts with Groups: The Simple, Not Especially Sophisticated Solution

Let’s start first with the notion of groups and their implementation. On the surface, nothing could be more straightforward: If I have to manage a sizeable set of users and assign them different rights to applications, I need to categorize those users into groups with the same profile, whether that’s by function, role, need to know, hierarchy, or some other factor. This is the simplest approach to any categorization, creating some “relevant” labels, then assigning people that fit within those label to define groups.

So let’s say we’re creating groups based work functions, such as sales, marketing, production, and administration. All we need to do is list all the people under a particular function, create a label, and then assign this label to those people. Couldn’t be easier, right? The simplicity of the process explains the huge success of groups—and although we implementers tend to make fun of groups as crude categorizations, I would guesstimate that at least 90% of our authorization policies are still implemented through groups. (So much for all that talk about advanced fine-grained authorization! But I’m getting ahead of myself here…)

In fact, we’ve become so dependent on groups that in many cases, especially with sizeable organization where the business processes are quite refined and well managed, we’re seeing that there are often more groups than users! At first glance, this seems paradoxical—after all, what’s the point of regrouping people if you have more groups than people? But the joke is on us technical people because we ignored another key reality: the business one. Sure, we could have a lot of people, but generally a well-managed and productive organization can have more activities (or different aspects of a given activity) that require the multiplication of those groups. So we gave our users a simple mechanism to categorize people into groups, and they used it—talk about being a victim of our own success! 🙂

Basically, we played the sorcerer’s apprentice and our simple formula yielded a multiplication of groups, which quickly became  un-manageable. So we went back to the formula and started to tweak it, creating groups inside groups, hierarchies of groups, and nested groups; introducing Boolean operations on groups; aggregating them into roles, and so on. So what we were just saying about groups being simple? Simple for whom? Simple for the group implementers—yes, definitely. Simple for a user in charge of the initial creation of the group—sure. But add any complexity into the mix and the chaos begins.

So Much for the Digital Revolution: Every Change, Managed Manually

From a computer’s point of view, the assignment of a user to a group is totally opaque—just an explicit list entered by the person in charge of creating the group. This explicit list contains no information about why or how a user is dispatched into or associated with a group. In short, the definition of membership rests with the group owner, which is fine on the face of it. But that excludes any automated assignment of a new member to the group without manual intervention of the group owner. That means every change must be entered by hand—imagine the complexity as people constantly change roles and shift responsibilities. And imagine how easy it would be for an overworked manager to miss removing the name of the person she just fired from just one of the groups he was part of. Now imagine the security risk if that guy’s still got access to sensitive files.

Without explicitly externalizing those rules, those policies, the administration of the system becomes tied to the group owners/creators. The effort of sub-categorizing with nested groups or introducing more flexible ways to combine groups by using Boolean operators just reveals the root of the problem: When you give users better ways to characterize their groups, you are forcing those users to either make explicit the formation rules of their groups—or continue to make every single change manually, even as those changes become more complex and unmanageable.

And that’s how we (re)discovered the value of attribute-based group definitions.

Machine-Readable Groups: Using Attributes to Simplify Management and Make Policies Explicit

We realized that if we wanted to automate, to simplify the management of all these groups, we needed to describe them at the lowest level as the set of attributes that defined a given group, role, and—yes—context. We discovered that groups and policies can be managed in a more finely-grained manner with increased automation (and greater productivity!) if we characterized them as a set of attributes, combining them with the usual arsenal of Boolean expressions and functions. Basically, we needed an explicit computer representation of this characterization, instead of leaving such definitions in the head of an overtaxed administrator, hoping that auto-magically our human semantic would be interpreted and executable by our machines.

So we looked at how we represented those policies, groups, and roles and saw that an attribute-based system was a necessary condition. But unless we go further with this the analysis, we run the risk of oversimplification, of coming up with a solution that’s simplistic, instead of elegantly simple—and that would only create another set of problems down the road.

So we could keep all the elements—group, subgroup, etc.—as separated “entities” and link them to a person, as in the first example above. Or we could fuse them together with the definition of a user, as we’ve done in second example. After all, both implementations can technically yield the same categorization, meaning you can get to the definition of the groups and subgroups you need with the right members in both solutions.

But semantically, we’re not talking about exactly the same thing. In one case, we have a notion of groups and subgroups separated from the definition of the person. In the other, we’ve bolted those groups and subgroups on as attributes of that person. So which one is the right definition? That all depends on what you need in your representation—by which I mean it’s contextual—but it’s very important for us to fully grasp the difference. The decomposition into attributes is key for fine-grained authorization, but unless we have a clear understanding about what we are doing, we can take the decomposition too far. In such a case, the world becomes a chaotic set of attributes, where we can’t see the forest for all those trees. While we can peer into a universe made up of the most elementary particles, most real-life problems demand that we recompose that world by gluing all those objects back together again.

Breaking It Down and Building It Back Up, Better Than Before

And that is where we begin to see the need to not only decompose the world into attributes, but also to reorganize that world into objects, relationships, and context. What you get through this reorganization of your information representation is a more complete view of your system, where authorization can be enforced in a more granular way. This is the way we really intend to do it in our policies, as we would define them in natural language—and that’s exactly what we’ll be looking at in my next blog post.

So thanks for reading this introduction to my favorite topic, and be sure to check back for a deep dive into objects, relationships, and context. I’ll even show you how a marketing coordinator and a computer can learn to speak the same language!