The importance of Grammar in IAM (AKA: Permissions are verbs)

There are two seemingly irrelevant decisions that we tend to take very lightly when creating permissions, and which will mess up our Authorization model in the long-term and make it totally unmanageable.

The first one is a bit better known: "Avoid overly broad permissions" or "Make your permissions as granular as you can". We will address it in detail in later articles.

The scope of this article, however, is the second principle, which sounds a little more arbitrary and typically triggers a deal of unrest with the application owners when pointed out. It's about "Defining your permissions as verbs" or "Properly naming your permissions". Application owners typically find this concern to be an exaggeration. Who cares about the name of permissions, right?

Let's use a simple example to illustrate how much of a problem this will become if we don't pay proper attention to it.

Let's say we have a CRM (Customer Relationship Management) application. In it, we store and maintain all the information of our interaction with customers, much of which is confidential. We, of course, create a set of permissions that our employees need to be granted in order to get access to read and modify this information.

However, because this information can only be read by Customer Service (CS) agents and modified by Senior agents, we decide that our permissions will be:

• "Basic Customer Service"
• "Senior Customer Service"

Actually, these here are not permissions at all. Not properly scoped permissions, at least. They don't define the actions that the users can perform with them. They don't specify the what, and instead go straight to the who. This creates three big problems, in the long run.

1. When a CS agent sees this permission they will think "I need to request this", but they will have no idea what for, or what it does. We will soon have employees requesting this permission "just in case", even if the criteria for accessing the CRM changes in the future. After all, the permission is called "Customer Service" (Hint: "just in case" is a very bad idea from the perspective of security and compliance).
2. From this point forward, every time our organization builds or buys a new application for the CS department (or a new module for the existing CRM application), the application owners will have to decide whether to create a new specific permission for it... or to reuse a permission which is actually called "Basic Customer Service". What I mean by reuse it, is to leverage an already existing assignment which, at least in theory, seems to be targeted at the same population that I want to authorize. So... why not? The reason why this is a very bad idea is because eventually this permission will provide access to so much that it will be impossible to manage it. At that point, it will allow access to functionality way beyond the original scope of the read-only access in the CRM. So when we look at this massively critical permission granted to all of our CS department and we ask "what does it give access to?" the answer we'll likely find is "nobody knows". More importantly, when we talk to the "theoretical owner" to find out, their response will be: "Listen: I used to be the owner of this. But it has evolved so much and is now giving access to so much that I cannot even begin to understand what it gives access to or who should get it". Huge problem.
3. In case this was not bad enough already, we need to understand (and this is the critical point) that who should have access is and will always be a changing criteria. We are now saying Customer Service. But within a year, we get a request from the marketing team. For business reasons, they need read-only access to the CRM application. Their request does make sense, no concerns there. But we now have 2 options: 
• We give them access to our existing permission, which is called "Basic Customer Service" (even though our Marketing team is not CS). I have seen "manager" permissions granted to people who are not managers, because they needed access to some of the "management" tools. At this point, your Authorization model is contradicting your HR solution, which is a very bad idea. Which one of the two should we trust?
• We create a new permission (which does the same thing as "Basic Customer Service") called "Basic Marketing Team". We now have two permissions which do exactly the same, and the new one is also subject to the issues in #1 and #2. We now have to go into the code (or settings) of the CRM application so that this new permission is also leveraged when providing read-only access to the system. Effectively, giving access to somebody who was not contemplated before requires a rollout (releasing a new version of the application), which is... you guessed it: a very bad idea.

All of these problems could have been avoided if only we had originally acknowledged one simple truth: What a permission does should rarely change. Who a permission is granted to can change very dynamically. Therefore, it stands to reason that permissions should be defined with the context of their more immutable properties. A permission should always be defined, created, and named based on what it does, not based on who we now think should get it.

Some voices will, however, challenge that "Basic Customer Service" is, in this example, not a Permission but a Role, and that is fine. It's not. In a future article I will discuss the difference between Permissions, Roles and Profiles in more detail, but for now let's simply refer to the above problems. Although Roles are indeed defined based on who will be assigned to them, they are mere ways to bundle permissions together. They constitute an additional layer on top of your permission model. You should still be able to create, re-assign and modify Roles on the go, without the need for a full application rollout. If the application knows of it, if it requires software changes to modify existing or to introduce new "Roles"... those are not roles, they are permissions. Wrongly named permissions. Because permissions are verbs.