In an RBAC system, organizations must first create specific roles and then define which permissions and privileges those roles will be granted. Organizations often begin by broadly separating roles into three top-level categories of administrators, specialists or expert users and end users.

To further configure different roles for specific sets of users, more fine-grained factors such as authority, responsibilities and skill levels are considered. Sometimes, a role might correspond directly to a job title. In other cases, the role might be a collection of permissions that can be assigned to a user who meets certain conditions, regardless of their job title.

Users are often assigned multiple roles or might be assigned to a role group that includes several levels of access. Some roles are hierarchical and provide managers with a complete set of permissions, while roles below them receive a subset of those role permissions. For instance, a supervisor’s role might grant that user write access to a document, while team members have read access only.

An example of RBAC in action

1. An IT administrator at a hospital creates an RBAC role for “Nurse.”
2. The administrator sets permissions for the Nurse role, such as viewing medications or entering data into an electronic health record (EHR) system.
3. Members of the nursing staff at the hospital are assigned the RBAC Nurse role.
4. When users assigned to the Nurse role log on, RBAC checks which permissions they are entitled to and grants them access for that session.
5. Other system permissions such as prescribing medications or ordering tests are denied to these users because they are not authorized for the Nurse role. 

Many organizations use an identity and access management (IAM) solution to implement RBAC across their enterprises. IAM systems can help with both authentication and authorization in an RBAC scheme:

• Authentication: IAM systems can verify a user’s identity by checking their credentials against a centralized user directory or database.
  
  
• Authorization: IAM systems can authorize users by checking their roles in the user directory and granting the appropriate permissions based on that role in the organization’s RBAC scheme.

The National Institute of Standards and Technology (NIST), which developed the RBAC model, provides three basic rules for all RBAC systems.  

1. Role assignment: A user must be assigned one or more active roles to exercise permissions or privileges.
   
   
2. Role authorization: The user must be authorized to take on the role or roles they have been assigned.
   
   
3. Permission authorization: Permissions or privileges are granted only to users who have been authorized through their role assignments.

There are four separate models for implementing RBAC, but each model begins with the same core structure. Each successive model builds new functionality and features upon the previous model.  

• Core RBAC
• Hierarchical RBAC
• Constrained RBAC
• Symmetric RBAC

Core RBAC
Sometimes called Flat RBAC, this model is the required foundation for any RBAC system. It follows the three basic rules of RBAC. Users are assigned roles, and those roles authorize access to specific sets of permissions and privileges. Core RBAC can be used as a primary access control system, or as the basis for more advanced RBAC models.

Hierarchical RBAC
This model adds role hierarchies that replicate the reporting structure of an organization. In a role hierarchy, each role inherits the permissions of the role beneath it and gains new permissions.

For example, a role hierarchy might include executives, managers, supervisors and line employees. An executive at the top of the hierarchy would be authorized for a full set of permissions, while managers, supervisors and line employees would each be granted successively smaller subsets of that permission set.  

Constrained RBAC
In addition to role hierarchies, this model adds capabilities for enforcing separation of duties (SOD). Separation of duties helps prevent conflicts of interest by requiring two people to complete certain tasks.

For example, a user who requests reimbursement for a business expense should not be the same person who approves that request. Constrained RBAC policy ensures that user privileges are separated for these types of tasks.

Symmetric RBAC
This model is the most advanced, flexible and comprehensive version of RBAC. In addition to the capabilities of the previous models, it adds deeper visibility into permissions across an enterprise.

Organizations are able to review how each permission maps to each role and each user in the system. They can also adjust and update the permissions associated with roles as business processes and employee responsibilities evolve.

These features are especially valuable to large organizations that must ensure that every role and every user has the least amount of access required to carry out tasks.