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.
