International Journal of Engineering Trends and Technology (IJETT) – Volume 26 Number 5- August 2015
Role Based Access Control System
Dr. Gregory Onwodi#1
#1
Lecturer I & CIT Unit & National Open University of Nigeria
14/16 Ahmadu Bello way V/I, Lagos, Nigeria
Abstract- The development of a Role-based access
control system proffers solution to the problem
being encountered in a non Role-based access
control system such as presence of errors, high rate
of fraudulent attack and all associated problems.
This research therefore introduces the concept of
a Role-based access control system (RBAC)
which is an improved alternative to the non role
based access control. With the concept of a Rolebased access control system, users do not have
unrestricted access to enterprise objects. Rather,
access permissions are administratively associated
with roles, and users are administratively made
members of appropriate roles. It is a two – tier
architecture software.
This notion greatly simplifies the four major
action lists: Create, read, Update and Delete
(CRUD). With the four system client privileges
(Insert, Update, Select and Delete) which have been
classified into three (Class A, Class B and Class C).
Class A have four privileges (Insert, Update, Select
and Delete); Class B has three privileges (Insert,
Update and Select); while Class C has two
privileges (Insert and Select). This Paper presents
a
developed
application
tha t
makes
a u t h o r i z a t i o n available t o s c r i p t s a n d
application for the system and also an Audit Trail
to keep track of activities done. This was
developed and achieved using PHP and MYSQL.
The system was built to override SQL injection
and to reset all session variables at the end of
each session. We conclude that an enterprise
should move to Role-based access control system
to maintain and keep tracks of activities in the
organisation and also to reduce exposure to fraud
and conflict interest.
Keywords RBAC, CRUD, PHP, MYSQL, Audit Trail
I. INTRODUCTION
Role-based access control is an access
control method that organizations implement to
ensure that access to data is performed by
authorized users. Unlike other access control
methods, Role-Based Access Control assigns users
to a specific roles and permission are granted to
each role based on the user‟s job requirements.
Users can be assigned any number of roles in
order to conduct day-to-day tasks. For example, a
user may need to have developer roles as well as an
analyst role. Each role would define the permissions
that are needed to access different objects. Role-
ISSN: 2231-5381
Based Access Control RBAC, is an approach
to restricting system access to authorized
users.[1] It is used by the majority of enterprises
with more than 500 employees,[2] and can be
implemented via Mandatory Access Control (MAC)
or Discretionary Access Control (DAC). RBAC is
sometimes referred to as role-based security.
Within an organization, roles are created for
various job functions. The permissions to perform
certain operations are assigned to specific roles.
Members of staff or other system users are
assigned particular roles, and through those role
assignments, acquire the computer permissions to
perform particular computer-system functions. Since
users are not assigned permissions directly, but only
acquire them through their role or roles,
management of individual user rights becomes a
matter of simply assigning appropriate roles to the
user's account; this simplifies common operations,
such as adding a user, or changing a user's
department,[3] . Access controls are security
features that control how users and systems
communicate and interact with other systems and
resources. Access is the flow of information
between a subject and an object. A subject is an
active entity that requests access to an object or the
data within an object. E.g User, Program, Process
etc. An object is a passive entity that contains the
information. E.g.: Computer, Database, File,
Program etc. Access controls give an organization
the ability to control, restrict, monitor, and protect
resource availability, integrity and confidentiality[4]
II. MODULES DESCRIPTION
The architecture below describes the
underline information system model for
the system.
Fig. 1 Systems Architecture
http://www.ijettjournal.org
Page 233
International Journal of Engineering Trends and Technology (IJETT) – Volume 26 Number 5- August 2015
The information system lies on role based
authentication where system clients‟ actions are
mapped to their various roles. During authentication
the system determines users‟ roles and routes the
user to the appropriate controller providing the
matching actions. The action list contains four (4)
major options (CRUD actions) as listed above (fig.1)
in the model.
A. SYSTEM CLIENT
Users are termed as the system client
according to the model above. Users are created by
the super administrator which is in charge of the
entire system. The super administrator assigns an
action class to an entity based on their role and level
in the system operational flow. The authentication
manager spool validates and authenticates users‟
actions based on their action class in the system data
backbone.
B. ROLE MANAGER
System client‟s roles are divided into four (4)
i.e. Insert, Update, Select and Delete. Every user class
contains roles unique to them, based on the users‟
action class. The system retrieves this information
about the action class at the point of entry into the
system (authentication). Class A process all four
roles of the role class i.e. They can insert new
record, update existing records, fetch records from
the database as well. Class B calls only three (3)
actions of the role class; select, update, insert. Finally
Class C references selection of records as well as
creating new records.
C. DATABASE
Authentication is done based on the action
class by the role manager, action flows from the role
manager to a transport module which maps actions
to the clients classes based on their privilege in the
data backbone.
There four system client privileges
Class A (Insert, Update, Select, Delete)
Class B (Insert, Update, Select)
Class C (Insert, Select)
III FRONT END DESIGN
A. ADMINISTRATORS LOGIN
This is the systems Administrators interface
where login credentials are entered to gain
access to the system after logging – in (fig. 2).
ISSN: 2231-5381
Fig. 2 System Administrator Login
B. STAFF REGISTRATION
This function is available to all user
classes i.e. (A, B, C). It validates inputs and
enforces the input of all required fields by
prompting and disabling the submit button until
this field are filled. Fig.3 shows the form where
administrator enters the data of a new staff to be
registered.
Fig.3 Staff Registration Form View
On a successful completion of this form, the
page prompts a message notifying the user of
a successful submission of the record to the
database.
C. RECORD UPDATES
This role is available only to users in
privilege classes „A‟ or „B‟. The Graphical
User Interface (GUI) of this action provides
the user with an input field where the user
enters the file number of the record to be
updated; the record is lifted from the database
and displayed to the user from where
appropriate fields can be modified as desired.
Fig. 4 shows the form where the user enters
the assigned file number of the record to be
updated.
http://www.ijettjournal.org
Page 234
International Journal of Engineering Trends and Technology (IJETT) – Volume 26 Number 5- August 2015
Fig. 4 Record Update Form
Fig. 6 Record Truncation Form
On modification, the submit button is clicked
and the user is notified on a successfully
update with a message notification on top of
the form.
The lift handle provides the capability of
reviewing the record to be deleted on
supplying a valid file number. When the delete
button is clicked, the record is taken off the
system permanently.
D. RECORD TRUNCATION
This action is only available to system
clients on the privilege class A, where a user is
authenticated again before data truncation can
occur. The users have to re-enter their login
credentials before the form which serves this
purpose is loaded. Fig.5 shows the form which
is loaded when the user clicks on the „delete
option‟ link.
E. ROLE PRIVILEGES
This function enables the administrator create
new system client as well as assign roles to
them. The administrator supplies the username
and password as well as defines a privilege
class to the new system client as described
below:
Fig.5 Data Truncation Window
When a user enters a valid username and
password which processes the privilege of
truncating records, the transport module of
the application loads the form containing
the data truncation controls as illustrated in fig. 6.
Fig.7 Administrators Privileges
F. USER AUDITING
The administrator queries the log of activities
using system client‟s username as a seed in the
audit as illustrated in Fig.8. Audit results are
attached to a section of the page as the event
which triggers the audit takes place („on
Change‟):
ISSN: 2231-5381
http://www.ijettjournal.org
Page 235
International Journal of Engineering Trends and Technology (IJETT) – Volume 26 Number 5- August 2015
B. CLASS B PRIVILEGE VIEW
Based on the actions available to this system
client role, the landing view of a user in this
class is populated with just three actions i.e.
record viewing, updating of record, and
inserting new staff record into the database
(figure 4.10).
Fig.8 Client Auditing Templates
IV. BACK END DESIGN
Authentication is done based on the action class
by the role manager, action flows from the role
manager to a transport module which maps
actions to the clients classes based on their
privilege in the data backbone.
There four system client privileges
Class A (Insert, Update, Select, Delete)
Class B (Insert, Update, Select)
Class C (Insert, Select)
A. CLASS A PRIVILEGE VIEW
On supplying login credentials to the
transport module, a user found in this
privilege class is stacked up with an interface
having all four property of the action class role
i.e. the ability to add new staff to the
current database, update staff record, fetch
staff‟s record and truncate staff‟s records(fig.
4.9).
Fig.10 Class B Privilege View
C. CLASS C PRIVILEGE VIEW
These privilege class processes the least
underlying list of actions on its view after a
successful authentication on login. The listed
actions include insertion of new records and
selection of existing records.
Fig.11 Class C Privilege View
V. DATABASE SCHEMA
A. TABLE “SYS_CLIENT
This holds system clients information such as,
username, password, action class (privilege)
and access levels. This table is affected by a
super administrator, who has the function to
add a new user and to drop an existing user.
Fig.9 Class A Privilege View
The swatch on the left switch between record
views and basic information to staff
specialization.
ISSN: 2231-5381
http://www.ijettjournal.org
Page 236
International Journal of Engineering Trends and Technology (IJETT) – Volume 26 Number 5- August 2015
Fig.12 Table Sys_Client
C. TABLE “TRAIL”
This holds a complete log of users‟ actions
starting from the point of entry into the system
(authentication) to exit (logout) as shown in
fig.13.
Fig.14 Table Basic_Info
The information contained on this table include
staff file number which is the main index of the
table (primary key), full-name, nationality, state
of origin, local government area, ward, date of
birth, his/her grade and level in the commission,
the current post he/she are holds, the primary
assignment and contact information.
D. TABLE “DATES”
This contains staff timeline information
including first appointment date, date of first
appointment,
date
posted
to
current
establishment/unit and last promotion date.
Fig.13 Table_Trial
C. TABLE “BASIC_INFO”
This table holds the data of the subject matter
of the system that is been implemented fig. 14.
Fig.15 Table Dates
E. TABLE SPECIALIZATION
Function information as to staff qualification are
contained on this page. These are information such
ISSN: 2231-5381
http://www.ijettjournal.org
Page 237
International Journal of Engineering Trends and Technology (IJETT) – Volume 26 Number 5- August 2015
as qualifications, subject(s) specialized in, and
subject(s) taught.
Role Based Access Control has being designed to
automate and simplify access control administration
and to make authorization available to script and
application implementing Mandatory Access Control.
It assigns users to specific roles and permission is
granted to each role based on the user‟s job
requirements. This application was implemented in a
virtual reality environment.
It is well known that there is a high rate of
fraudulent attack online and there is an everincreasing need to adapt to changing requirements.
Therefore, it is of a great importance for the
development and view of consideration that will
bring about an upgrade from a non-Role-Based
Access Control system to Role-Based Access Control
system to facilitate separation of duties, a more
secured system and a robust application.
Fig.16 Table Specialization
F. SECURITY ISSUES
Security is a major concern for the
modern age systems. In order to safeguard this
information system, the system has been tested
and optimized to override SQL injection and
other system vulnerabilities. Also, proper
measures were taken to ensure the proper
clean up of data by resetting all session
variables at the end of each session i.e. when a
logout action is called. A log of every user‟s
action is tagged in the audit trail of the
system.
V. CONCLUSIONS
Role-based access control is an access control
method that organizations implement to ensure that
access to data is performed by authorized users.
ISSN: 2231-5381
ACKNOWLEDGMENT
I wish to acknowledge Eyo Esther for typesetting
this work and Stephen Ariyo for the systems
development.
REFERENCES
[1] Sandmu. R, Ferraiolo, D.F & Kumn,D. R (2000)@The
NIST Model for Role Based Access Control: towards a
unified Standard @5@ ACM Workshop role Based
Access Control: 47-63.
[2] Sandhu, R. (1988):. “Role Based Access Control” In
Advances in
Computers, Vol. 46, M. Zelkowitz Eds .
Academic, 237-286. (1998).
[3] Anderson, A. O (2005):Core and Hierarchical Role Based
Access Contol (RBAC) rofile of XACML Version 2.0
(2005). ASIS Standard.
[4] Sylvia, Osborn, R. Sandhu, and Q. Munawer
(2000).”Configuring Role Based Access Control to
enforce
mandatory
and
discretionary
control
policies”.ACM Trans. Inf. Syst. 85-106. (2000).
http://www.ijettjournal.org
Page 238