This document discusses implementing role-based access control (RBAC) on a web application. It begins by defining access control and RBAC. It then examines different approaches to access control, including level-based, user-based, role-based, and responsibility-based. For the project, it recommends a role-based or responsibility-based approach using tables to define users, roles, tasks, and permissions to allow restricting access based on a user's role(s). It also discusses designing this as a draft and considering requirements to control data updates based on user roles.

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

2. 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

3. 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

4. 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

5. 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

6. • 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

7. • 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

8. • 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

9. • 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

10. • 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

11. • 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

12. 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

13. o Design as ‘Draft’?
Role-Task Field
Task-Field
Menu
Navigation
Button
User User-Role
Role-Task Role
Task Pattern
Subsystem
13

14. 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