Role-based access control (RBAC) is an approach to restricting system access to users based on defined roles. Many companies have built internal system like these, but usually in a very archaic and haphazard way.
There are a few primary semantics to a role and a set of attributes, operaters, and actions that define a role.
Defining a Role
A role should have five semantic components:
- Name — a human readable and business-friendly way to identify a role
- Description — the role’s purpose, clearly defined
- Tags — important for managing multiple roles and creating roles to manage to roles
- Assignments — assigning roles to individuals or groups of individuals
- Policies — specific rules and permission sets assigned to a role
Defining a Policy
A policy has one primary component:
- Array of Statements — a policy can have many statements. You should be able to save policies and re-use them across multiple roles. In other words, a policy is a collection of specific permission rules.
Defining a Statement
A statements has three components:
- Resource — the targetted feature, environment, or operation
- Effect — typically “Allow” or “Deny”
- Action — a resource can have many actions, like deleteUser, addUser, modifyUser. These actions should have human readable names, like “Delete a User” for “deleteUser”. This is essential when you get into more complex actions, like “Modify Image Upload” for “imgUploadMod”.
{"effect": "deny","resources": ["prod/primaryDB/*"],"actions": ["deleteDB"]}
Mapping Roles
You should be able to assign multiple roles to an individual user. Ideally, you would have a clear user interface that allows you to build these roles and attach them to individual users or groups of users.
Avoiding Technical Debt
It is very common amongst large companies to accrue hundreds or thousands of roles over time. Having an intuitive GUI lets you manage this debt, keep your roles up-to-date, and keep your system secure.