Role-based access control overview

8 min readMay 30, 2020

Things to say in this article

This section explains the concept of role-based access control based on the ANSI material.

Motivation

To understand role-based access control (henceforth referred to as RBAC), which I had to implement in my development work.

Target audience

People who want to know the outline of RBAC in a quick, illustrated way.
A system developer who implements access control with decision flags, but is looking for a better way.

What is role-based access control?

Concept of role-based access control

Role Based Access Control (RBAC) is a method of controlling access to resources. A user is associated with a system resource that is a security target through a role, and the relationship between the user and the system resource is used to determine whether or not access is allowed.

A role is a position, in the analogy of a corporate organization. The specific access control would be something like the following.

The company’s highest level of security, confidential documents (OBS), can be viewed (OPS) by the president and executives (Role), but not by regular employees (Role).
Department A’s confidential documents (OBS) can be updated (OPS) by Department A’s manager (Role), while Department B’s manager (Role) cannot update (OPS).
A department A assistant manager (Role) was promoted to A director (Role) and was able to view (OPS) confidential documents (OBS).
- Department B documents (OBS) are available to the President, Department B Manager and General Employee B (Role).

Elements of RBAC

The following elements are necessary for the RBAC to be established.

User: The access user.
Object(OBS): the object to be accessed.
Operation(OPS): An operation on an object to be accessed.
Permission: Permission to operate on an access target, expressed as a combination of OBS and OPS.
Role: The name (role) you give to a many-to-many relationship between one or more grouped Permissions that have some meaning in the system and a User that is authorized to have that Permission.
User Assignment(UA): The mapping information of the User assigned to the Role.
Permission Assignment(UA): The mapping information of the Permission assigned to the Role.

The relationship between the elements is shown as an ER diagram.

User: Role = many: many

A user can be associated with one or more roles.
A role can be associated with one or more users.

Role: Permission = many: many

Roles can have one or more permissions associated with them.
An authority may be associated with one or more roles.

How to determine RBAC access

To illustrate the judgment method, let’s consider two examples of articles that were POSTed to a CMS.

Set the required operation (OPS) in advance for the system resource to be used for security.

Set “Browse” (OPS) for the post browsing function.
Set “Update” (OPS) for the post update function.

Set the following permissions (Permission).

Authority 1: View (OPS) of Post №123 (OBS)
Authority 2: Update (OPS) on Post №456 (OBS)

The following roles are assigned to users.

Role 1: Retain authority = authority 1, authority 2
Role 2: Retain Authority = Authority 2
Role 3: Retain Authority = Authority 2

Prepare two access users.

User 1: Role (role) = Role 1
User 2: Role (role) = Role 2, Role 3

Determining whether access is possible

When a user accesses a secure system resource, the Permission, expressed as a combination of the specified Operation and the specified Object, is used to determine whether the roles associated with the access user are allowed. A simulation of the access decision with the above data and settings would be as follows.

Accessible Cases

User 1 views post №123.

Because role 1, held by user 1, holds privileges 1.

User 1 updates post №456.

Because role 1, held by user 1, holds privileges 2.

User 2 views post №456.

Because Role 2 and Role 3, which are held by User 2, retain the privilege 2.

Inaccessible case

User 1 views post №456.

Role 1, held by user 1, is trying to access a resource that does not exist.

User 2 views post №123.

Because the role 1 held by user 2 does not hold privilege 1.

Advantages of using RBAC

Although it may seem complicated to explain, access control using RBAC has system design advantages. To illustrate this, let’s look at an example of access control without RBAC.

Black line: Access OK / Red line: Access NG

The number of SESSIONs (number of users) associated with whether or not a user can access a resource is as many as the number of Users x the number of Resources.
Since the number of users and resources changes dynamically in most systems, it is necessary to prepare a user/resource association table in the DB to manage the registration data for the number of records required.

Now, let’s consider a case in which it is necessary to change the privileges of user 1 to the same privileges as user 2.
In that case, the following process would occur.

Deletes all resource associations associated with user 1 (number of processes = number of resource associations associated with user 1).
Obtain all resource association information associated with user 2 (number of processes = 1).
Register all resources associated with user 2 in user 1 (number of processes = number of resources associated with user 2).

Next, let’s consider the RBAC case.

In the same way, let’s consider a case where it is necessary to change the privileges of user 1 to the same privileges as user 2.
In that case, the following process would occur.

Deleting the role 1 associated with user 1 (number of processes = 1).
Obtain all roles associated with user 2 (number of processes = 1).
Register all roles associated with user 2 in user 1 (number of processes = 1).

Compared to the case without RBAC, it simplifies the association management process between elements.
In the case of RBAC, the concept of a role is placed between the user and the resource, and the associated information is substituted for the role. Users would then no longer have to manage access privileges to resources directly. The user only needs to think about which role it is associated with, and the role only needs to think about which resource it has privileges to.

RBAC management commands

As explained above, RBAC has a relatively simple judgment method and the ability to flexibly respond to various access control specifications required by the system. However, it is a prerequisite to be able to accurately manage the association information between elements.
Because of its simplicity, a single mistake in tying information can cause a catastrophe. Can you imagine the magnitude of the risk when you consider that just one change in user-role association information can give you access to sensitive data of different customers?

RBAC has commands and functions to manage the information about the association between elements. Here, I’ll pick up a few things from the reference material.

Restricted role-based access control

SSD: Separation of Static Duty Relationships

Although RBAC allows multiple roles to be assigned to a single user, it is important to note that we must restrict the assignment of roles with conflicting privileges to a single user. A specific example is the approval system authority.

Permission 1: Access to the request function to have a specified user approve an article submission.

Permission 2: Access to the article submission approval function.

Consider a case in which the following roles hold these privileges.

Role 1: Retain Authority = Authority 1

Role 2: Retain Authority = Authority 2

In this case, it is not appropriate to assign role 1 and role 2 to a user A. This is because the approval function is practically non-functional. User A can submit an approval request for article submission to User A and approve it himself. This is a loss for the system and a unilateral benefit for user A. It can be said that a conflict of interest has arisen.

A mechanism to prevent this is a static separation of duty relations. The mechanism itself is simple, as follows.

Define the set of roles in which a conflict of interest may arise.
Specifies how many users can be assigned to a single role in the set of roles.
The following functions are used to check the role allocation timing at the time of new user registration.

def is_static_separation_of_duty_relations(restrict_roles, restrict_num):
    """
    args: restrict_roles The set of roles where a conflict of interest can arise
    args: restrict_num How many users can be assigned to a role in the set of roles
    """
    ...
    return bool
# No more than three of R1, R2, R3, and R4 shall be assigned to a single user.
if not is_static_separation_of_duty_relations((r1,r2,r3,r4), 3):
    # 指定ユーザの登録不可
else:
    # 指定ユーザの登録可

AddUser(user:NAME)

Define the new user registration in RBAC.

def add_rbac_user(user):
    """
    Define the new user registration in RBAC.  
    
    args: user Register User
    """
    # user is not included in the set of registered users.
    # Include user in the set of newly registered and already registered users.
    # Registering new roles and permissions to associate with users.
    # Registering newly registered roles and permissions to user.

DeleteUser(user:NAME)

Define the user deletion in RBAC.

DeleteUser(user):
    """
    Define the user deletion in RBAC.  
    
    args: user Delete User
    """
    # user is a member of the set of registered users.
    # Deleting system data registered by user.
    # Remove role and permissions association information associated with user.
    # Removing roles and permissions associated with a user.
    # Deleting a user.

There are some other function definitions in the ANSI document that can be used in RBAC implementation.

AddRole(role:NAME)
DeleteRole(role:NAME)
AssignUser(user,role:NAME)
DeassignUser(user,role:NAME)
GrantPermission(object,operation,role:NAME)
RevokePermission(operation,object,role:NAME)
CreateSession (user : NAME ; ars : 2NAMES ; session : NAME )
DeleteSession (user , session : NAME )
AddActiveRole (user , session , role : NAME )
DropActiveRole (user , session , role : NAME )
CheckAccess (session , operation , object : NAME ; out

…

Other access control

In addition to RBAC, there are some other typical access control methods.

Discretionary Access Control

A method in which the owner of an object decides what can be done (Read, Write, Execute) for each attribute (owner, group, etc.) of the user accessing the object, which is adopted by Unix.

owner: The owner of the object.
group: A set of users who can share an object.

In the Unix case, each object must have 11 permissions relationships.

Who’s the owner?
Is the owner R-able?
Is the owner able to…
Is the owner X-able?
What is the group?
Is the group R-enabled?
Is that group W-able?
Is the group X-enabled?
Can other users and groups be R?
Can other users and groups be W?
Can other users and groups be X?