RBAC stands for Role Based Access Control.
RBAC is an extremely common design pattern for permissions systems where each user is assigned a role, from which the user's permissions are derived. When a user changes roles, as do their permissions. This is as specific as the definition gets because implementations can vary greatly.
An note-taking application could have two roles defined for each note: editor and reader.
Editors have access to be able view and edit notes. Readers have access to view notes, but not alter them.
When the application needs to check if a user can edit a note, it checks to see if the user has the editor role. When the application needs to check if a user can view a note, it checks to see if the user has the editor or the reader role.
Because RBAC is a very general design, it leaves lots of details unexplored for implementers to discover and decide the best behavior for their application. Often fleshing out these details and implementing additional behavior is referred to as Advanced RBAC.
Because permissions are tied to particular roles, users that do not perfectly fit into these roles cannot be represented. RBAC also doesn't specify whether roles are required to exist for every object.
For example, a note-taking application could check to see if is a user has the admin role on a collection of notes rather than the admin role on the particular note the user is accessing.
Groups are sets of users organized into arbitrary collections that can be assigned roles. A naive implementation of RBAC use the roles themselves as groups, but this can be confusing and limiting for users.
Groups can also have hierarchies where the users are inherited into other groups. For example, the users in an owners group might be included in every group in the application.
Roles may or may not be implemented to exist within a hierarchy.
For example, an admin role on a group of users might mean that admins can only manage group membership or it could also transitively inherit admin roles on each of the resources owned by the team.
It is not immediately obvious if every user should have roles assigned by default. Users without roles can be considered a bug or interpretted as having an implicit role.
Descriptions of RBAC use examples where an administrative user assigns roles to new users. However, there are events that can occur in applications where a human is not assigning roles manually. These can be simple, such as "creating a resource assigns the creator the admin role." However, not all of these scenarios will have obvious or intuitive solutions.
Imagine an application whose users originate from another system. Events such as a user's first-login, which creates their account, puts the application in an awkward spot. It can not assign any roles at all or it can guess which roles to assign for the new user. If the application does the former, administrative users will have to manually assign roles for every user. If the application does the latter, roles could be assigned incorrectly and the application and user system likely needs to become deeply coupled to be correct.
Enterprises often list RBAC as a requirement for applications that they want to adopt. Businesses have different roles of employees that will use the software, so it's intuitive that they would require a permission system based around roles. However, it may not be intuitive what functionality they need beyond the simplest definition of RBAC.
Predefined groups might not be enough for enterprises attempting to map their existing company structure into an application.
When there are multiple organizations using the same appplication, there has to be something that owns a set of users or groups for each organization.
On applications like GitHub, this container is actually called an organization and organizations contain user-defined groups called teams which have roles assigned to them.
While GitHub has only one parent, there are times where a container is needed for a set of organizations, and then a parent for that, ad infinitum.
There are a variety of roles that are often overlooked until enterprise requires them.
- IT or operations employees often require a role for an administrating absolutely everything.
- Employees tracking expenses can require access to only configure and collect billing information.
- Auditors or security specialists can require access to only collect logs of actions for compliance.
There are many companies that already have groups, teams, and roles stored in their authentication service. Enterprises want these users to be able to log into the application -- often with their existing groups matched to particular roles. This sometimes requires active synchronization with protocols such as SCIM and other times the application can lazily create accounts on first sign-in.
The following are common enterprise Identity Providers: