A thing I’ve noticed about working in a large organization is that you often have to make access requests.
The access requests are something like: “I have a business reason to be able to use system X. Please grant me access.”
Usually the end result of this request is being added to a group. Sometimes it involves being given a role in some third party system, but most often it just gets you added to a new LDAP/Active Directory group. (Sometimes the LDAP/AD group is set up to imply that you should get a certain role in some third party system.)
I started thinking: Shouldn’t the organization know which tools I need, given the role I am in?
A lot of the time, they don’t.
Groups vs roles
Let’s distinguish groups from roles.
- A group is something that you happen to belong to.
- A role describes your local identity (as my dictionary puts it, a role is “the function assumed or part played in a particular situation.”)
Groups are always multiple, and you belong to them contingently. At a given time, you can belong to group A, B and C, and not to D or E, without any special contradiction. (Think of groups in the Unix sense: no systemic logic governs their assignment; you can be in n different groups at once.)
Meanwhile, roles are often mutually exclusive. You have Role A or Role B, but not both simultaneously. You are an administrator or an end user. You are playing the role of Romeo or of Juliet, but not both simultaneously.
(Admittedly, there can be roles that are not exclusive, but I would argue that mutual exclusivity often does go along with the notion of a role. You are an individual contributor or you are an engineering manager; if you try to be both, it doesn’t usually go well.)
It’s usually easy, in a big organization, to know what someone’s role is. At least their main role that goes on their human resources records.
Why is this not the primary key for one’s system access needs?
Seeing like a state
In the abstract, it makes sense to allocate permissions by role. We know what role you are in, so we should be able to give you access accordingly. (By role in this sense, I mean “your primary job role.”)
Somehow, in a big enough organization, this doesn’t work well at all.
I’ve never actually read James C. Scott’s Seeing Like a State. But from what I understand, it’s all about how top down visibility never quite works out. Big organizations systematically can’t quite see everything that’s happening on the ground across all the different territories they govern. When top-down visibility is imposed, this erases local diversity, making things awkward or disastrous, and leaves things out.
From the perspective of centralized IT or HR systems, I don’t think anyone knows the exact tools that hundreds or thousands of different employees need to use. It’s too difficult to infer from someone’s role what they will need to access.
Instead, we adjudicate this question using the access request.
Access requests, or decentralized access control
An access request: “I need access to system X because Y.” The Y provides individual context, which is lacking in the top-down role-based model.
Access requests are evaluated case by case. I’m a developer who needs access to production logs to analyze an error. I’m a manager who needs access to usage statistics to see how our product rollout is going. I’m an on-call engineer who needs access to some infrastructure settings to fix a problem. I want to get to review the source code of some other team whose source code I can’t see.
All these kinds of things end up in an access request. The access request is the court of appeals for all the exceptions to the rules, for all the unforeseen needs. It changes the unit of analysis from roles to group memberships.
In a way, it’s great that it works like this. It allows individuals to figure out what they need, and the organization to accommodate. It makes big organizations more flexible, more decentralized.
But it’s also a symptom of the opacity of big organizations. The people who run centralized IT systems don’t know what you need. Why do two developers in the same team need different access permissions? There isn’t always a good philosophical answer to that. Everything is context.
What then?
As you spend time in this kind of system, your access requests pile up. You can access more things. You belong to more LDAP groups.
There usually isn’t any clear lifecycle for an access request. Once you have it, you have it. You usually aren’t asked, “Do you still need this?” You might end up retaining access to things you don’t still need. When you change roles, you might still keep some of your old permissions, because permissions weren’t tied to your role in the first place.
From a security policy perspective, it’s bad to have group memberships that don’t necessarily expire. That adds unneeded risk.
All the access requests also take time, which you don’t notice, because it’s spread out over months or years.
But you start to notice the inefficiency of this when someone new shows up and wants to use the tools you have. “Oh, you have the same role as me? But if you want access to the tools I use, you have to make 17 separate access requests, and we don’t even remember how to submit all the access requests…”
What’s the moral of this?
Access control is an area where we have to compromise between top-down visibility and local autonomy. (It rarely works to create top-down access control systems that are too rigid, because if people can’t do their jobs because they can’t get access to the right systems, they tend to look for workarounds.)
When I started writing this, I imagined that permissions ideally should be top-down, and purely role based.
Now that I’m at the end, I feel like I understand more clearly why we need autonomy and case-by-case evaluations.