Implementing Role Based Access Control (RBAC) on OLSS Web Application

Content:

o Introduction

o What is Access Control?

o What is ‘Role Based’? • Level Based

• User Based

• Role Based

• Responsibility Based

o DSF requirement?

o ‘Design’ as Draft?

2

o Introduction

An 'access control' system is just another name for a 'security system' or a 'permissions' system.

In computer systems security, role-based access control (RBAC) is an approach to restricting system access to authorized users. It is used by the majority of enterprises with more than 500 employees,[3] and can implement mandatory access control (MAC) or discretionary access control (DAC). RBAC is sometimes referred to as role-based security.

Source: http://en.wikipedia.org/wiki/Role-based_access_control

3

o What is Access Control?

In a single-user application typically no need access control - the user has access to every function within the application. However, in a multi-user application which is deployed over numerous devices which are linked together in a network it is more than likely that not all functionality will be available to all users.

In this situation a method is required whereby functions within the application can only be accessed by persons to whom permission has been granted. This will typically require the maintenance of the following details:

• A list of all the functions that are available within the system. These 'functions' are sometimes referred to as 'transactions' or 'tasks'.

• A list of all the persons who are allowed to access the application as a whole. These 'persons' are sometimes referred to as 'users'.

• A list of permissions which identifies which functions are accessible by which users.

• Each of these lists is normally maintained as a table within a database.

4

o What is 'role based'?

There is more than one way to give different permissions to different users, but each method has its own set of advantages and disadvantages. Here are some that can be encountered:

• Level Based

• User Based

• Role Based

• Responsibility Based

5

• Level Based

This is a simple system as it only requires two database tables - USERS and TASKS - without any relationship between them.

In this system each TASK is given a security level number in the range 1 to 99, with 1 being the lowest level and 99 the highest. Each USER is then given a security level number and is allowed to access only those TASKs which have a security level which is the same or lower. Thus a USER with a security level of 5 can access a TASK which has a security level in the range 1-5.

The problem with this system is that it is totally cumulative - by raising the level number you can add more tasks, and you can only remove tasks by reducing the level number. Groups of tasks that share the same level number are either included or excluded as a group, there is no possibility to mix'n'match. For example, take a simple setup with two users, 'A' and 'B', and two tasks, 'A' and 'B'. Now try to give user 'A' access to task 'A' but not task 'B', and user 'B' access to task 'B' but not task 'A'. You will find that it cannot be done:

• If both tasks have the same security level then access can be granted to both or neither.

• If one task has a lower security level than the other then access can be granted to the lower level on its own, or to both levels. It is not possible to grant access to the higher level and exclude tasks at a lower level.

Users Tasks

6

• User Based

In this system permissions are defined for individual users. This involves a many-to-many relationship between USERS and TASKS with PERMISSIONS being the link or intersection table. This disadvantage of this design is that where several users share the same permissions any change to those permissions needs to be repeated for each user.

It seems several different implementations of this design:

• In a system with complex tasks - where a single tasks can operate in create, read, update and delete mode - access to a task will include all of those modes.

• Where access to individual modes within a task is required then the PERMISSIONS record needs to have a YES/NO switch against each one of those modes. This is often referred to as a CRUD matrix (where 'CRUD' stands for Create, Read, Update and Delete) as the arrangement of tasks rows and permission columns resembles a matrix.

Users Tasks

Permissions

7

• Groups Based

In this design the users are split into groups and permissions are assigned to the group, not the individual user.

This design has the following advantages:

• Once the user has been identified the USER record will supply the USER-GROUP identity which is all that is needed to access the PERMISSIONS table.

• Any change made to a group’s permissions will automatically be inherited by all members of that group. Changes to a group's permissions can be made very easily as there is only one table, the PERMISSIONS table, to maintain.

• If an individual user is switched to another group this will sever all connections to the permissions of the previous role and replace them with those of the new role.

Users

Permissions

User-Groups

Tasks

8

• Responsibility Based - Simple

In this design it is possible for a user to belong to more than one group at the same time. This involves two many-to-many relationships. The USER-GROUP table is sometimes referred to as AREA-OF-RESPONSIBILITY because an individual user may have responsibilities in more than one area.

This design has the following disadvantages:

• It is only possible to add permissions by linking a user to another user group. It is not possible for the addition of another group to undo any permissions granted by an existing group.

• There are now two tables to maintain in order to give a user access to a task - the USER-USER-GROUP table and the TASK-USER-GROUP table.

Users

Task-User-Group

User-Groups

Tasks

User-User-Group

9

• Responsibility Based - Complex

A more complex version of this design is shown below:

Users

Task-User-Group

User-Groups

User-User-Group

Task-User-Group

Tasks-Groups

User-Task

Tasks

Tasks-User-Group

10

• Responsibility Based – Complex (Cont.)

In this design there are now five many-to-many relationships which enables a far wider range of customization. In this design the tasks were complex (a single task could operate in Create, Read, Update and Delete mode) which meant that each of the link/intersection tables was a CRUD matrix. As these tables were read in a strict sequence and the task permissions on one table could be replaced by the task permissions on another table. It was therefore possible for a record with a permission checked ON to be superseded by a record from another table with that permission checked OFF.

Even though in theory this design appears to be much more flexible, in practice this created a problem with usability. As permissions can exist on five tables, and the permission granted on one table can be taken away by the contents of another table it becomes a more difficult process to track down which user has access to which task.

11

o DSF Requirement?

Issue:

• Restrictive data management to avoid tampering.

Requirements:

• Control data updating based on user role, or prepare workflow mechanism for data modification – approval.

• Need to consider scope and level of data update handling based on role (based on menu or screen, based on function, based on data item, etc.).

Pro’s:

• To protect unhandled data modification (except authorized user who has proper privilege to update data), or to prepare update checking mechanism by superior or supervisor. Some user may have several roles concurrently.

Con’s:

• There is a possible to increase managers work load when system implements workflow (approval) feature.

• There is concern about number of test cases increased explosively when considering combination roles and workflow.

12

o Design as ‘Draft’?

Role-Task Field

Task-Field

Menu

Navigation Button

User User-Role

Role-Task Role

Task Pattern

Subsystem

13

o Design as ‘Draft’? (Cont.)

Due to the modular design any changes in functionality can be made easily either by changing an existing module or by adding in a new module.

• Implement group based security around the USER<==ROLE==>ROLE TASK<==TASK tables as this gave sufficient flexibility with a simple set of options:

• Permissions for each Role and Task can be maintained on a single screen.

• A User's single Role can be maintained on the 'Update User' screen.

• At run-time permission can be verified with a single lookup on the ROLE-TASK table using a ROLE_ID and a TASK_ID.

• Implement responsibility based security around the USER==>USER ROLE<==ROLE==>ROLE TASK<==TASK tables as this provides the ability to link a User to more than one Role with only a slight increase in complexity:

• Permissions for each Role and Task can continue to be maintained on a single screen.

• A User's list of Roles needs to be maintained on a separate USER-ROLE table. One of these Roles must be marked as the primary Role for that User.

• At run-time permission can still be verified with a single lookup on the ROLE-TASK table, but using a list of the User's ROLE_IDs (instead of just a single ID) and a TASK_ID.

14