Comments

You need to address the following issues in your project:

1. Formatting: Add page numbers, use paragraph settings to create white
space rather than blank lines, start new chapters on a new page. Consider
whether an object is a figure or a table.
2. Introduction: did you have a clear aim and set of objectives for the
project? If so, you need to refer to them in the conclusions. The
introduction spent too long describing what RBAC was, whereas it should
introduce the project and how you carried out the work.
3. References: started well but then they disappeared. A lot of text was
presented unreferenced, when I Googled the text, it returns a particular
document/website. Only three references had a URL. Didn't the others
come from the web? Add date last accessed to websites.
4. Figures/Tables: get the term correct. Why can't you create your own
tables for consistency of font? Many of your figures just added confusion
rather than understanding. Ask yourself whether they were necessary,
what they were doing in the report and could they be replaced or
improved upon. Why aren't they referenced?
5. Content: this is the biggest problem with your project. The flow between
chapters is poor and explanation of the different types of RBAC was not
helpful. Consider revising your report to make it flow more logically.
Discussing ACL and ABAC was good but an example for these methods
would have improved things. The charity shop/medical examples need to
be extended if they are to have any weight. Both would provide an
opportunity to explain how RBAC works if handled well. You added
figures showing different types of RBAC but failed to explain why they are
important.
6. English: difficult even for English speakers but get someone else to proof
read your work. Avoid using the same phrase in consecutive sentences.
The meaning was not always clear, hence the need for proof reading.
Spelling was good and the use of the apostrophe was excellent.

1
 Student Number:

Table of Contents
List of Figures: ............................................................. Error! Bookmark not defined.
Chapter 1 ........................................................................................................................ 5
1.1. Introduction ........................................................................................................ 5
1.2. Examples of RBAC: .......................................................................................... 6
1.3. Best Practices for Implementing RBAC: ........................................................... 8
1.4. Objective: ........................................................................................................... 9
1.5. Methodology: ..................................................................................................... 9
Chapter 2 ...................................................................................................................... 11
Literature Survey ......................................................................................................... 11
Chapter 3 ...................................................................................................................... 13
Types of Access Controls and implementation RBAC................................................ 13
3.1 Role Based Access Control:............................................................................. 13
3.2 Types of Access Control: RBAC Alternatives: ............................................... 17
3.3 Implementing Role-Based Access Control: ..................................................... 20
3.4 Sample Use Cases: Role-Based Access Control:............................................. 21
3.5 RBAC and its Standards: ................................................................................. 24
3.6 Extensions to RBAC Models: .......................................................................... 28
3.7 Different RBAC models with simple examples: ............................................. 29
3.8 Applications of RBAC and its extended models: ............................................ 32
Chapter 4 ...................................................................................................................... 33
Research Opportunities ................................................................................................ 33
Chapter 5 ...................................................................................................................... 34
Risk in Role Based Access Control Model .................................................................. 34

2
5.1 Traditional Access Control Models: ..................................................................... 37
5.2 Dynamic Access Control Models: ..................................................................... 38
5.3 Risk-Based Access Control Model: ...................................................................... 39
Chapter 6 ...................................................................................................................... 41
RBAC features and supporting policies ....................................................................... 41
6.1 Roles and role hierarchies: ............................................................................... 43
6.2 Role authorization: ........................................................................................... 44
6.3 Role activation: ................................................................................................ 45
Chapter 7 ...................................................................................................................... 47
Proposed Model ........................................................................................................... 47
7.1 Attributed Role Based Access Control Model: ................................................ 47
7.2 Example Study on Learning Management System : ........................................ 54
Conclusion: .................................................................................................................. 57
References: ................................................................................................................... 58

List of Figures:
Figure 1: Image representing lock and unlock property ...........................................5
Figure 2 : Image representing access control of the users .........................................6
Figure 3 : Importance of RBAC ............................................................................8
Figure 4 : Users, roles, and operations. ................................................................15
Figure 5 : Characteristic differences of RBAC and ABAC. [51]. ............................20
Figure 6 : Traditional Role Based Access Control Model. [48]. ..............................24
Figure 7: Flat RBAC[51]. ...................................................................................26
Figure 8:Hierarchical RBAC[51]. .......................................................................26
Figure 9: Constrained RBAC[51]. .......................................................................27
Figure 10:Consolidated RBAC[51]. ....................................................................27
Figure 11: Maturity of Role-Centric Extended RBAC Models [50].........................29
Figure 12: Role Centric Extended Models [50]. ....................................................30
Figure 13: Flow of an access control operation. ....................................................37
Figure 14: Main elements of a risk-based access control model. .............................40
Figure 15: User and subjects. ..............................................................................41
Figure 16: Operations and objects. ......................................................................42
Figure 17: Example of a role hierarchy. ...............................................................44
Figure 18: Model comparison of RBAC and ABAC .............................................49
Figure 19: Feature of RBAC and ABAC ..............................................................49
Figure 20: Automatic Permission Creation ...........................................................50
Figure 21: Attributed Permissions in RBAC Model ..............................................51
Figure 22: Attributed RBAC Model ....................................................................52
Figure 23: Permissions Assignment to Roles ........................................................53
Figure 24: Object Containers and Action Levels ...................................................55
Figure 25: Permission assignment to Roles and Roles to Users ..............................56

3
List of Tables:
Table 1: NIST Standards for RBAC…………………………………………………26
Table 2: Comparative Analysis of Role-Centric RBAC…………………………......43
Table 3: Comparison between traditional and dynamic access control approaches ...43

4
Chapter 1
1.1. Introduction Commented [MW1]: This is a lengthy introduction that mixes
two things: what the project is about (RBAC) and how it will be
conducted. You should keep the RBAC intro here brief and
concentrate on the intro to the project. Then in chapter 2
Role-based access control (RBAC) is the concept of assigning roles or onwards you can develop RBAC.

permissions to individuals based on their position within an organization. It is a

straightforward, easy method to get access for management which is less susceptible to
errors than granting permissions to each user individually. With RBAC it's important
to consider the requirements of your users and divide users into roles based on common
obligations. You give each person one of a few roles as well as the appropriate
permissions for each role. Role-permissions and user-role relationships allow for easy
user assignments because users do not need to be individually managed, they are instead
granted rights that are based on the rights given for their role(s).

Figure 1: Image representing lock and unlock property Commented [MW2]: Different font size and type. Reference
for these images?
For instance, if a Company is making use of RBAC to manage access to an HR Commented [MW3]: What does this image add to the
project?
system for example, HR managers can access role that allows them to modify
information about employees however other employees would have access to only their
own information. which represents the lock and unlock property in Fig.1. If you are
planning your access control strategy, it's best to grant users only the smallest amount
of access rights that will allow them to complete their tasks.

RBAC restricts access to network resources depending on the position of an

individual within the organization. It is now one of the primary methods to control
access in the modern age. The functions of RBAC relate to the degree of access that
employees must network. Employees have the right to gain access to the data to perform
their duties. Access to information is based on various factors, including the authority,

5
responsibility, or competence for the job. Additionally, accessibility to resources on
computers could be restricted to specific functions like the create, edit, or view a file.

Figure 2 : Image representing access control of the users

Fig.2 represents the model that how the users or employees in the company can
access to the data based on their roles. This is particularly important if you have a lot
of employees who work with contractors and third-party companies which makes it
difficult to keep a close eye on the access to networks. Utilizing RBAC will assist in
protecting the company's sensitive data as well as critical applications.

1.2. Examples of RBAC:

With RBAC You can manage the activities of users at the board level and at
more granular levels. You can decide if a user is an administrator's specialist user or an
end-user. You may make sure that the access rights and roles to the roles of your
employees within the organization. Permissions are only granted to those who have the
access to perform their work. Let’s consider Facebook here, the users have different Commented [MW4]: Meta?
Deleted: let’s
kinds of permissions and options to choose such as user cannot set an option that who
Deleted: company
can view their profile. the user can set an option only his friends or public. Based on
the chosen options the access rights are granted. What happens if the task of the end-
user changes? You can manually assign the role to another user, or include roles in
groups, or implement an assignment policy to assign roles. take away or add members
to an organization.

The principle behind this is to provide only the necessary access to an employee
in order to fulfil their task. If the job of an employee is changing, you may have to

6
remove or add them from their current working group. When a user is added to in a role
group already existing, the user will be granted access to the full capabilities of the
group. When they're removed members’, access is restricted. Users can be granted
access to specific software or data in order to complete an assignment. They will be
removed from the group following.

Common examples of RBAC include:

• Software engineering role
• Marketing role
• Finance role
• Human resource’s role

In each of these roles, there could be a manager tier as well as a contributor’s tier which
has different levels of authorization within the applications that are granted to every job.

Some of the designations in an RBAC tool include: Deleted: can

• Management role scope

• Management role group
• Management role
• Management role assignment

When a user is added to a role group, the user has permission to perform all the
roles in the group. When they leave the group access will be restricted. Users may be
added to multiple groups in the event they require temporary access to specific software
or data, but then removed once the project is completed. Commented [MW5]: Can you represent this with a diagram?
For example, a Venn diagram showing how roles can overlap?
Or could you show this hierarchically?

7
 Figure 3 : Importance of RBAC

1.3. Best Practices for Implementing RBAC:

Role-based access control will help you increase your security, remain fully in
compliance with the applicable regulations and reduce operating costs as shown in Fig.3.
But the procedure of implementing access control that is based on roles for the entire
business isn't always straightforward and could cause a negative reaction from your
customers.

To implement RBAC, we should follow these best practices: Commented [MW6]: Different font size 14pt

1. Start with your requirements: Before we can move to RBAC, you must be aware
of the job functions that use the software, technology, and business functions. In
addition, you should take into consideration any audit or regulatory requirements
that we may be required to meet.

2. Scope your implementation: It isn't necessary to implement RBAC across the Deleted: the
Deleted: implementation
entire company immediately, but you might want to consider limiting the
Deleted: of
capability to the storing sensitive data first. Deleted: your
Deleted: be limited to the scope to only capable of

8
 3. Define roles: After you've done your research and determined the scope of your
analysis, you'll be able to start to create roles that define what permissions various
roles require. Beware of common design mistakes such as too much or not enough
degree of granularity, overlap between roles or granting excessive exceptions.

1.4. Objective: Commented [MW7]: What is the objective here?

Attribute based access control (ABAC) is an access control model that is

dynamic that allows for easy structuring roles. The analysis of roles and permissions
following creating an access control model and managing it isn't simple with ABAC. A
model for access control is designed that builds on the advantages that are present in
RBAC in addition to ABAC and removes certain weaknesses of the models mentioned
above. The model proposed utilizes and makes use of the characteristics of objects as
well as permissions, roles, and users to form the basis. Additionally, the model
leverages the role capability for ABAC and security for RBAC.

To study the working model of RBAC and how ABAC will help and solve the
limitations of the RBAC by providing the access controls to user, user groups etc.

1.5. Methodology:
If you want to be successful in the working with RBAC model, we must
approach the entire procedure with following steps presented below:
Commented [MW8]: It seems you have picked the layout
terms for a project (objectives, methodology, etc.) but have not
filled out the following sections correct. Objective and
methodology refer to the project and not the subject matter.

Step1: Knowing the business's requirements - along with making the transition to
RBAC we should conduct an extensive analysis on the tasks, the technology and
business processes. It is also important to be aware of any audit or regulatory
requirements and evaluate the security situation of your business. It is also possible to
benefit from other forms that control access.

Step2 Limit the capabilities of your application - To applications or systems which

store sensitive data. This will allow your business to keep track of the change. Planning
the purpose of implementation--knowing the work of your RBAC requirements and
better plan with the implementation to mark the align with the needs of the organization.

9
Step3 Defining roles - The definition of roles will be much simpler to define roles after
you've completed the analysis of needs and understood the way that individuals carry
out their duties. Beware of common design mistakes including excessive or insufficient
degree of granularity, overlap between roles, and giving authorizations.

Step4 Implementation - The final phase is the rollout of RBAC. The process should
be carried out in phases to avoid the creation of a massive workload as well as to limit
disruption to the businesses. Begin by dealing with a first user group. Start using access
control which is granular prior to expanding the detail. Collect comments from users
and monitor your surroundings to determine the next steps to implement.

10
Chapter 2
Literature Survey

This chapter discusses concepts, terminologies, as well as methods that Deleted: The
Formatted: Indent: First line: 1.27 cm
constitute the basis of knowledge on the research that is on are reviewed. The research
concentrates on creating RBAC configurations with the most suitable approach to role
engineering. A brief review of the authorization procedure that is based on the
assignment of roles to users and groups is provided. The procedure involved in creating
roles using the algorithm of role mining and the assignments it makes to users as well
as permissions are explained. The discussion is restricted to the aspects discussed in
subsequent chapters, and that are pertinent to the research proposed. Furthermore, in
this chapter, a review of work on cloud data security with respect to confidentiality and
privacy is discussed. Commented [MW9]: You can remove blank lines and use
paragraph settings to keep paragraphs apart.
Researchers from various fields have suggested a variety of methods to enhance Deleted: ¶

RBAC in addition to Attribute the BAC. Al-Kahtan et al [1] has proposed the concept Commented [MW10]: ABAC?

of assigning users roles automatically based on attributes. For instance, they are
identified by their age, name, and place of residence.

Each user is automatically assigned their roles based on their attributes. For
instance, those aged 16-20 are assigned a distinct role (Role1) Users of 21-35 years old
have a different job (Role2) and those who are older than 25 years are assigned Role 3
and so on. Kuhn et al [2] suggested a variety of strategies to merge RBAC as well as Deleted: . They

ABAC. They found that RBAC is simple to use and allows for the ability to easily
analyze permissions but the process of structuring roles. ABAC is also easy to use for
role structure, but the analysis of permissions once you assign them users is a challenge
when compared to RBAC. The authors suggested three strategies to combine ABAC
that address the shortcomings in models. They also give more reliable and dynamic
role-shaping as well as analysis of authorizations to the administrator.

Atlam et al. [3] The paper suggested eXtensible Control Markup Formatted Table

11
 Language (XACML) as the suitable language to
implement access control policies in the IoT. IoT system. Commented [MW11]: Repeated phrase

The paper also made use of XACML to create access

policy for the model of access control based on risk.
Atlam et al. [4] The paper presented the background of various risk-
estimation techniques used to control access which are
based on risks from the IoT. The paper analyzed the
advantages and drawbacks of the different methods of risk
estimation required to implement the access control model
which is built on the risk.
Dankar et al. [5] The paper presents an abstract risk-awareness model that
utilizes context and real-time information from the
surrounding environment to make the decision about
access. The paper also included mitigation measures to
make sure that access decisions in the event of high-risk
factors when requesting access.
Rahmati et al. [6] The paper introduced an access control model that is based
on risk that was developed to build the system known as
Tyche which is a system for managing the risks associated
with physical devices. Tyche can be described as a system
for access control built on risk that categorizes different
types of applications into distinct risk groups. Each risk
group is assigned specific access rights, based on risk-
value
Armando et al. [7] The paper suggested a framework that combines trust and
risk to give access decision-making. The decision to grant
access is made by comparing risk to the trust value, which
access is granted only if that value of trust is greater than
the risk. The paper also provided mitigation strategies that
can increase the trust value while reducing the risk.

Caption for this table?

This chapter is far too short. You should break out the details from the above table and Formatted: Justified, Line spacing: 1.5 lines

discuss them. Are there any other writers who discuss RBAC/ABAC Deleted: ¶
¶

12
Chapter 3 Commented [MW12]: Start chapter at the beginning of a
new page. You can add a page break to do this.
Deleted: ¶
Types of Access Controls and implementation RBAC ¶
¶
¶
3.1 Role Based Access Control: ¶
¶
¶
Many companies are currently converting to access control based on role. The ¶
¶
¶
process of setting up the RBAC framework for an organization is now referred to as ¶
¶
"role engineering". Role engineering is a complex procedure, for instance when it came ¶
¶
to establishing RBAC for a large European bank with nearly 1400 branches, and more ¶
¶
than 50,000 employees serving over six million customers, more than 1500 roles had Formatted: Font: Arial

been identified. Due to the sheer complexity, RBAC is best implemented by breaking Commented [MW13]: Reference?
Deleted: .
every task into its distinct elements. The fundamental idea is that users do not make Commented [MW14]: Reference?
access to the resources of an enterprise.

Roles are given access rights, and users are then made part of the roles they are
assigned to. This makes it much easier to manage the management of authorizations
and gives an abundance of flexibility in creating and enforcing particular security
policies for businesses. Users can be part of roles based on the qualifications of their
respective roles. They may be capable of being moved into a different role without
changing the access arrangement. Roles are granted rights whenever new applications
or actions add roles or permissions are removed from roles when necessary.

A few vendors and users have realized the potential advantages of RBAC but
there isn't a precise understanding of the concept RBAC means. Certain RBAC features
are currently being used in commercial products, however with no reference framework
for the purpose and benefits of RBAC. A lack of a clear definition could cause
customers to be unable to evaluate products, and for companies to understand the
efficiency of their products in dealing with security concerns that are widely recognized.
To remedy these weaknesses there are a variety of research initiatives funded by the
government currently in progress to assess RBAC specifically in terms of its advantages
and attributes [32].

The research involves surveys that allow to understand the requirements of Commented [MW15]: Allow who to understand?

security for commercial and government users, as well as the development for an

13
officially recognized RBAC Model Design Architecture, prototypes, and
demonstrations to demonstrate the effectiveness of RBAC and its usage. In the wake of Commented [MW16]: Reword this phrase

these research, provide more information regarding the motivations behind this system,
as well as capabilities that could go further than the RBAC name [33].

The primary reason behind RBAC is to set up and enforce specific enterprise
security policies, and to simplify the often-complicated security management. RBAC
is a significant step ahead in terms of freedom and control in comparison to current
standards of both discretionary and mandatory access control. In many businesses, both
industry and civilian government, users don't "own" the information for which they
have access to, which it is often assumed through traditional access control techniques. Commented [MW17]: Right word?

In these kinds of organizations either the organization or agency is the true "owner" of
system objects and their decision-making as a representative of the users might not be
the best choice. In terms of access control, it is based on roles. access, decisions will be Commented [MW18]: Given in the name RBAC!

based on the role that users have in their roles as members of the company.

This is the reason RBAC is often described as an access control that is not
discretionary in the sense that users are restricted by security policies of the company.
When the settings are not classified, they do not focus on solving security issues at
multiple levels like the norm for restricted access control that is non-discretionary. In
contrast, RBAC allows for the specification and enforcement of a variety of protection
policies that can be tailored on an enterprise-by-enterprise basis. The policy applied in
a particular system or dispersed system is an outcome of the specific configurations of
the various parts of RBAC.

The RBAC framework lets administrators have the authority to decide who has Commented [MW19]: Careful over repeating words,
authority is in the next sentence
the authority to carry out which actions at what time and from what location and in what
way, in particular circumstances, and in which circumstances [34]. From a practical Commented [MW20]: Occurs twice

standpoint the core concept behind the RBAC is to treat the operations as the activities
of users and roles who participate in roles. The connection between the roles of the
users their roles, as well as the actions are illustrated in the following figure.

14
 Figure 4 : Users, roles, and operations.
As shown in the above Fig.4, the double arrows of Figure suggest a multiple-
to-many relationships. Here the user could be linked to any single roles or all roles that
contains at least one member. Roles can be created to fill different roles within a
company. For instance, one role could be one of an agent for loans or tellers at the bank Deleted: agents

and nurses or doctors in hospitals. The duties associated with these positions bind those
who are in the job to carry out specific tasks.

For example, in an institution, the role of a doctor may include the need to
diagnose or prescribe medications and require laboratory tests. The researcher's job may
be restricted to collecting the clinical data needed for research, while working as Social
Worker could examine patient profiles in order to identify suicidal patients or to spot
the possibility of abuse.

The link between operations and the functions of an organization is based on

rules that are self-imposed. A health professional could determine that the work of a
clinician is to publish only a few results, and not disperse them when human errors or
routing could result in a violation of the privacy rights of the patient. The procedure can
be explained in a way that can be used in the demonstration and enforcement of
regulations and laws. For instance, nurses are only able to create a new entry into the
history of treatment for a patient instead of being able to alter the patient's medical
record. A pharmacist might be granted the possibility to administer medication,
however, they cannot prescribe medications. Commented [MW21]: The medical example is a nice one
that could be expanded. It is easily understood by the lay
reader. Could a diagram be added to show the various roles
interact with one another?
Although RBAC is not a proponent of any particular security guidelines
however, the company has proven that it adheres to various established security Commented [MW22]: What company?

guidelines and guidelines that are essential for both government and commercial
businesses who handle sensitive information, however, not classified information. It
includes the determination of what constitutes skills required to perform specific duties,
as in addition to the enforcement of the principle of the least privilege granted to rules
that may include the assignment of duties as well as the dynamic or static assignment

15
of tasks [35]. These rules are in effect at the point that an action is authorized to be
carried out to a specific role when users are authorized to become part of a role at the
time of the activation of the role (e.g., at the time the role is created within a user's
current session) or whenever the user attempts to perform any action using an object.
To emphasize the importance of these laws, take note of the uncontrollable the
actions by Nicholas Leeson that led to the downfall of the world's most renowned
investment company, Barings, in the 1995. Particularly, Leeson had the power to Commented [MW23]: Would RBAC have prevented this?.
Deleted: year
oversee trading on trading in financial derivatives markets in Singapore and back-office
operations to settle trades. There's a variety of roles that could lead to and in this
scenario, it could have turned out to be disastrous. If a firm is determined to stop fraud,
the system was not functioning. The top management of Barings PLC should never
have been the one who was accountable for trade and settlement. A policy regarding
conflicts of interests could be created in the central management group and then
implemented administratively, and then enforced through an RBAC framework.

Alongside RBAC has the potential to aid in the implementation of policies that
are essential for classified environments. The policies could comprise one-way
information flow is facilitated by the creation and implementation of most notable
feature that is unique to RBAC is its ability to manage. The management of
authorization information is widely regarded as a time-consuming process which has a
significant and continuous cost. Based on the RBAC system, users have permission to
perform the role they have been assigned according to their qualifications and tasks.
Users' as per the requirements for the job dictate. With RBAC users, they don't have
the authority to carry out tasks on a personal basis however they are tied to roles. Role
affiliation with the new operation is established, and so are old operations be eliminated
as the functions of the organization shift and evolve. This concept is essential in making
it easier to manage and understand rights [36]. Deleted: of

Another advantage for administrators who use RBAC is that they can control
access in a manner that is abstraction, which is in line with the way businesses typically Commented [MW24]: Abstract?

manage their businesses. This is accomplished by constantly and continually regulating

the behavior of users via the creation and definition of roles, hierarchies the limitations,
roles, relationships and functions. So, when it is established that the RBAC framework Commented [MW25]: What does this mean?

is established, it is the principal administrative process that includes removal and the

16
granting access to and out of roles. This differs from the traditional and less intuitive
way of governing the lower security methods for access directly employing an object-
by-object method.
Another benefit is that RBAC administrator tasks are delegated to protection
domains. When establishing a health system, the duties connected to health work
providers could be centralized and applicable to all clinics and hospitals however, the
grant of memberships and the cancellation of memberships in specific functions can be
determined by the local administrative of the location.

3.2 Types of Access Control: RBAC Alternatives:

Access Control List (ACL):

Access control lists (ACL) is a set of rights that are associated with computing Commented [MW26]: Is it worth discussing Capability Lists
and the Access Control Matrix?
resources. It tells the operating system which users have access to the object, and what Commented [MW27]: Can you show this via a diagram?

actions they are allowed to take. Each user is assigned an entry This is connected to the
security characteristics that are associated is generally used alongside conventional
systems.

RBAC vs ACL: Commented [MW28]: Can they be combined?

For most of the software designed for businesses, RBAC is superior to ACL
regarding security as well as administrative load. ACL is better equipped to provide
security at the highest level of the user and for managing information at a low level
while RBAC is more suited to an enterprise-wide security program that has an
administrator who manages the system. ACL could, for instance, permit the writer is
unable to determine the way a user could alter the data file. Commented [MW29]: Reword

The ACL model has entities which work based on the rules designed at the time
of creation of the applications. The model works on the rules and rules can be some Commented [MW30]: Similar wording

time diplomatic where there is no chance for the bifurcation of the rules. As compared
to the RBAC the roles will be given based on the priority and can be changed from the
employee perspective which can be overridden as per the recommendations.

17
 From all the above alternatives of RBAC we see there are pros and cons, but
every model has its own way of implementation methodologies but has some cons
which makes them lack in terms of implementation when compared perfectly with
RBAC, thus RBAC stands out with full working features and controls over all the user
in a paradigm or model when it’s been deployed in a particular team for implementation.

Attribute-Based Access Control (ABAC):

ABAC looks at a set rules and guidelines to control access rights in accordance
with specific characteristics of objects like the environment, system, or user data. It uses
Boolean logic in order to permit or block user access on basis of an in-depth assessment
of set-valued and modular attributes and their connection to them. Practically speaking,
such as Categories=Financial or Role=Manager.

RBAC vs ABAC:
While RBAC is based upon predefined roles ABAC has more flexibility and
makes use of relation-based access controls. It's possible to utilize RBAC allows access
control ABAC policy grants access to managers who belong to the finance department.
ABAC is a more complicated search and demands the most processing capabilities and
more time Therefore, you should only consider ABAC if RBAC isn't enough.

As per Garnter analysis based on RBAC and ABAC, ABAC has lot of Commented [MW31]: Reference [49]? References are a bit
thin on the ground here.
advantages compared to the RBAC which in turn can negotiated as per the user levels
and can be assigned the other group level access to the users to overcome the burdens
of the users with constrains, this makes works easier for the users of different groups to
access and control them. In 2011 The Garnter Identity& Access Management also
predicted that 70% of the businesses use the ABAC to protect their critical assets [49].

RBAC pros and cons:

RBAC is the most well-known method of limiting access. The major benefit of Commented [MW32]: Repeated phrase in the next
paragraph
this method is that organizations don't have to grant or deny access on a per-user basis,
instead of bringing users together according to their role instead. The process of
establishing a set of roles within a small or medium-sized business isn't difficult.
However, creating a system in a large company isn't an easy job.

18
 RBAC can be the best and most well-known technique for restricting access. Commented [MW33]: See above

The primary advantage of this technique is that businesses don't have to decide whether
they want access to users based on user, instead, they can group users in accordance
with their roles. It is a process set up an array of roles within a small or medium-sized
company that isn't difficult. However, establishing an organization within a larger
business isn't a simple task.

ABAC pros and cons:

The main advantage of ABAC is, it allows access not based on the role that is
assigned to the user, but rather on the characteristics of each component of the system.
In this particular way, you can define a business rule with any level of degree of
complexity. Even if you have to limit certain information to be accessible during
working hours, this can be accomplished with a simple rule. In addition, ABAC rules
can evaluate the characteristics of subjects and resources that aren't yet discovered in
the authorization systems.

For ABAC restrictions, this kind of system can be difficult to set up due to the
manner in which policies have to be defined and maintained. It is difficult to conduct
an audit prior to the event and identify the rights granted to a particular user. It's not
possible to establish the risk level for any particular employee position.

In the Fig.5 it is clearly mentioned about the characteristic differences of RBAC

and ABAC

19
 Figure 5 : Characteristic differences of RBAC and ABAC. [51]. Commented [MW34]: Figure or table?

3.3 Implementing Role-Based Access Control:

RBAC can help companies to work to improve the security while remaining in
compliance with security regulations. The procedure of implementing access control
based on role across an organization can be a bit complicated and may result in
opposition from those who are involved. In order to be successful in implementing
RBAC it is crucial to view the implementation [37]

Knowing the needs of the business prior to transitioning towards RBAC it is

suggested to conduct an extensive analysis of the needs to understand the work
functions as well as the processes and technologies. It is also essential to be aware of Commented [MW35]: Could be expressed better

the requirements of any audit or regulatory requirement and examine the security status
of your company. There are a variety of security measures to control access.

Avoid software or systems that store sensitive information. This will aid your Commented [MW36]: Why?

company in managing the changes process.

Define roles: It's much easier to define roles (by the super user / admin) after
having done a thorough analysis of the needs and figured out how people perform their
tasks. Be aware of typical role design flaws, such as too much or not enough detail, the
overlap of roles and granting excessive the right to RBAC authorizations.

20
 Implementation: The final phase is the one that involves taking the steps
necessary to start rolling out RBAC. The process should be completed in sections to
avoid an overwhelming load and limit disruption to the businesses. Begin by addressing
a small set of users. Start by implementing access control that is basic before moving
towards higher level of fineness. You can get feedback from your users and keep an
eye on your environment to determine next steps to take for the implementation [38].

3.4 Sample Use Cases: Role-Based Access Control:

Let's look at an example of what you could be required to know and how to
utilize RBAC, or role-based access control (RBAC) to control to manage the process
of authorization.

Let's say you are a business who provides business-to-business software-as-a-

service to non-profit organizations. The software lets nonprofits develop, manage, and
sell their merchandise to donors who wish to donate. The program you have purchased
includes several modules. Two are:
1. A gift shop point of sale (POS) application that allows non-profit
organizations to create pop-up stores and keep track of their sales.
2. An online marketing tool allows non-profit organizations to make
newsletters and then send the newsletters to donors.

The pseudo model for the authentication groups to get access for the roles.

You must make use of Auth0 to restrict access for your clients who are not for Commented [MW37]: Company product? Explain more.

accessing various features of your application. Without RBAC the employees and
volunteers will have the ability to use all the functions of your app. This isn't a good
thing, especially since one of the non-profits has a rescue animal which includes a
variety of volunteers who are experts in only the area, they are volunteering in.

Instead installing RBAC and then create authorizations for are required by the gift shop
POS module requires:

Read: catalog-item

21
read: customer-profile

create: invoice

To simplify the management of these shops, make a role that is named Gift Shop
Manager and then, add the required permissions to the role.

Like this the way you create the permissions of users of your software to fulfill the
following purposes:
Create: newsletter

Edit: newsletter

Unsubscribe from the newsletter

Send: newsletter

edit: distribution-list

Create a new role which is referred to as Newsletter Admin Add the rights to the role.

When your animal rescue organization recruits the volunteer Astrid to run their Commented [MW38]: This wasn’t mentioned at the
beginning of the example
Pop-Up shop to sell t-shirts, Astrid can be given the role of the Gift Shop manager.
When you assign this role to Astrid, she will be granted all the rights you granted to the
job. Because Astrid isn't knowledgeable about creating newsletters (and isn't the most
efficient in the field of email) This is why you didn't designate her as a Newsletter
Administrator, therefore she's not allowed access to the marketing module

From a technical point of view, Astrid logins to your application. Auth0

validates and allows her. It adds authorizations to Access Token. Your application then
examines your token and determines which of the modules is displayed to Astrid [39].

22
 By using the Auth0 RBAC system, you'll be able to not create an authorization
system distinct from the one you have currently. Instead, you use the authorization
token that you already have when you authorize. If Astrid is absent or decides she's not
interested in managing the gift shop and would rather supervise the foster care program
it is possible to swiftly remove the gift shop manager position from her and provide her
with an opportunity to take on a new position.

If managing the roles and rights for every customer is too difficult it is possible
to utilize an API known as Auth0 API to create an application inside your product that
permits customers to manage their own RBAC and reduce the chance of liability as well
as reduce staffing costs.

So, the example for a Gift shop will be as Super user will be the shop owner
who can have the access to all the levels to the application, while the manager levels
can have the access to other levels such as adding the articles to the store, updating the
prices, checking the stocks and the other things except the money transaction to the
clients from where they get the products so called dealers.

The next level of user like assistant manager can create the lower levels access
to the employees for making the transactions, applying the leaves, billing the products
etc. This user group cannot access the articles addition or updating them as they are
restricted to the upper group users, now to over these issues the assistant manager can
provide some partial activities in ABAC models. Commented [MW39]: Again, can this be expressed in a
diagram? The model could be clearer, so if you don’t use a
graphic can you tabulate roles and permissions?

Secure Data Access using Role Based Access Control:

RBAC is a variation of an access control mechanism that is flexible, scalable Deleted: and

and controls access to users based on roles. Role introduces an access control level
which assigns users to a restricted number of roles. Once the roles are assigned
permissions. The principal function for the control system is to give or deny access to
the user in accordance with the roles assigned to them. Therefore, access control
mechanisms can be classified within strict RBAC as well as adaptable RBAC systems.
The traditional RBAC mechanisms offer two choices, TRUE or FALSE, for access Deleted: that make
Deleted: to make
grant and denial, respectively and is an example of an inflexible RBAC system.

23
3.5 RBAC and its Standards:

The fundamental RBAC model is illustrated in this model. It illustrates the three
main elements: role, user and permissions. The term "user" according to RBAC model
is an individual who is a user of the system, and roles are assigned to each user. A role
can be defined by a task job in the organization, and roles are granted permissions. The
permissions are those that control access to system's resources. In the RBAC model
when a user wishes access to specific resources in the system the user assumes the role,
and the permission of the role defines the rights of the user. There are three kinds of
relationships among the three RBAC components such as the user-role and role-role
and role-permissions. RBAC systems are modeled using these relationships [40]. The
relationship between the user and role defines the roles that users in the system could
play. There is a multiple-to-many relations between the person and their role, but at any
moment of time, an individual user may play only one role. The role-role relation
establishes the hierarchical relationship between the roles and the roles-permission
relationships determines the range of permissions that are given to the roles. Commented [MW40]: This isn’t obvious from the figure. Can
you re do this?

Figure 6 : Traditional Role Based Access Control Model. [48]. Commented [MW41]: This needs a better explanation than
was given above. Do you really need this diagram? What is
PRMS?
The above Fig. 6 specifies the model with users, roles, sessions, operations and
observation. The user relates to the roles sessions bases on which he must perform
operations and observe the things where the things are delayed, which are in control of
other users a hierarchy model.

An international standard of RBAC models was developed by NIST [8] and they Commented [MW42]: I would have considered introducing
this earlier in the report.
have identified four distinct models of RBAC that are described in Table 1. The models

24
are classified in terms of flat model, hierarchical model, constrained model, and
consolidating model. Flat models are regarded as the model that is the basis of RBAC
and is the base for the other models. Hierarchies as well as constraints of component
models aren't supported by the flat model. The inclusion of hierarchies for roles in the
flat model is a hierarchical model, while the including constraints in the flat model
creates the model that is constrained. The model that is consolidated is one that
incorporates both role hierarchies as well as the constraints.

RBAC Models
Model Name Features
Flat Model Users, Roles, Permissions, Sessions
Hierarchical Model Hierarchical Roles
Constrained Model Constraints
Consolidated Model Role Hierarchies and Constraints

Table 1: NIST Standards for RBAC [51]. Commented [MW43]: Can you link these models to actual
examples? They are hard to follow at this point.

FLAT RBAC:

Flat RBAC is the basic functionality of the RBAC model where the user gets
the permissions after assigning to the specific role in the company. Here, the user can
be assigned to multiple roles, or a single role can be assigned to many employees in the
company. Commented [MW44]: For the four models, where did the
text come from? Have you just reworded someone else’s
work? If so you should acknowledge their efforts.

25
 Figure 7: Flat RBAC[51].

HIERARCHICAL RBAC:

In the company role structure, it implements the hierarchy. Where the users in
the higher roles inherit the rights and permissions of their juniors in the company. The
complexity of the hierarchy is based on the individual company.

Figure 8:Hierarchical RBAC[51].

CONSTRAINED RBAC:

Constrained RBAC is adapting RBAC based on company security policies and

administrative policies. It adds a best practice called the separation of duties to a system
which is mostly helpful for small and medium scale enterprises.

26
 Commented [MW45]: What does SOD stand for?

Figure 9: Constrained RBAC[51].

Consolidated RBAC models suggested earlier control of the system resources
through statically assigning access rights to the roles responsible for managing systems
resources. However, the software in the present-day environment requires an ongoing
assignment of permissions to roles in accordance with the changes in the environment.
The RBAC concept is expanded to include the capabilities required in an ever-changing
environment. Based on the needs of the software, in order to accommodate other
concepts like time, location and context, the RBAC model is expanded, and numerous
researchers have employed these extended versions of the base RBAC models.

Figure 10:Consolidated RBAC[51].

27
 Determining the right role is an enormous challenge. It is important to think Commented [MW46]: Does this apply to any particular
RBAC model?
about the various permissions that a user must have to carry out their job and the place
of this role within your hierarchy. If you give too many permissions to one job, it breaks
the principle of least privilege and can cause misuse of privileges.

Role-based access control is frequently used in medium and small-sized

businesses. They typically have simple workflows, limited numbers of users, as well as
a straightforward hierarchy that makes it easy to identify and explain user roles.

When all the roles that are required are in place it doesn't require much
maintenance or assistance from the IT department. Implementing RBAC can assist you
in meeting IT security requirements with minimal hassle. However, the creation of a
complicated role system for large enterprises could be a challenge. A company with
thousands of employees may end up having a couple of thousand roles. This is referred
to as role explosion and it's a fact of life for any large company.

3.6 Extensions to RBAC Models:

Expansions of RBAC models were suggested over time to accommodate the Commented [MW47]: By whom?

dynamic modifications that occur in modern day applications. This article outlines a Commented [MW48]: Copied from an article?

few of the modifications to RBAC models that were proposed by research communities.
These RBAC models are generally described as Attributed-centric and Role-centric
models. They are Role-centric models. RBAC models are extensions to the base RBAC
models to accommodate specific features needed from the systems. In Attribute-centric
models, user is assigned with permission and access to resources of a user is based on
the attributes that are associated with the user. A role can be one attributes of a user [9],
[10].

28
 Figure 11: Maturity of Role-Centric Extended RBAC Models [50]. Commented [MW49]: Are you going to explain what these
models are? It seems you are adding diagrams to fill up your
report.

The Fig.11 depicts the RBAC concepts and their level of improvements over a
period with different levels of transformations in the structure of the RBAC.

3.7 Different RBAC models with simple examples:

In the fundamental RBAC model the permissions is assigned to the role and the
individual that is assigned to the role receives access based upon the permission the role
is granted. The issue with this approach is when multiple users is assigned to the same
role and needs access to various resources at different times of time. To discuss this
issue more in specific detail, let's look at an organization that manages the Hospital.
The roles that are identified by the program are (Doctors as well as Nurses and Commented [MW50]: Nurses not mentioned below, why
not?
patients) and the resources are the files that contain the medical records for each patient.
There exist two separate units (Day and night) within the Hospital and each unit is cared Commented [MW51]: No need for initial capital in Day and
night. Are these really units? The wording could be improved
for by a physician who oversees the unit, and the doctor works on a shift. here.

The principle of the system is that if an individual is present during Day time
and is assigned the Doctor role, the user can look over the records of patients that are
coming in Day time only. The other patient who arrives during the night hours is
allowed access to the records of patients who are in the hospital during the night. In this
case the required permissions for a specific role depend on the date and time at which
Commented [MW52]: Using the phrase day time leads to
confusion.
Commented [MW53]: The doctor is allowed access, not the
patient. Why does the night working doctor have different
access to patient records?

29
the user is given the job. Similar situations occur when roles are assigned permissions
depending on the location where the role was activated. In order to meet all the specific
requirements created in the model, the base RBAC model must be expanded. Specific
requirements are outlined by researchers during their study, and they come up with the
needed modifications to the core RBAC models. The roles-based extensions are studied.

Location-Based RBAC:
There are instances where it is necessary to limit access to specific resources
based on the location from which the resources are accessed by users, by taking on the
role. For instance, an organization could allow its staff to be at home however they
would still want to limit certain important information from being accessible from their
home. In such a case, access to the critical information is secured depending on the
location which the employee makes the request. In this case, both resource and users
were assigned a location. The action of an account by the user is contingent upon the
location where the user is activating it, and the location of the resource influences the
permissions for access to the resource.
Commented [MW54]: Are you going to explain these
different models? What does this graphic bring to the project?

Figure 12: Role Centric Extended Models [50].

Time-Based RBAC:
Time-Based RBAC as described within the Hospital System Time-Based
RBAC, the time-based activation of roles is needed and an extension of the timing based
RBAC (TRBAC) Model was suggested by the researchers in [11,12] and a generalized
RBAC model (GTRBAC) is described as providing periodic enabling and disabling of
roles based on when that the roles are activated.

30
Access Control Based RBAC:
Access Control based on spatial location The situation is that the time and the
geographical element together form the basis to access certain resources. Consider an
example of an online shopping site that provides a special offer for the specific time
frame for certain countries. To confirm the eligibility requirements to receive the
discounts and discounts, the system must examine the time as well as the country where
the request is made. The spatiotemporal-based control systems that consider both time
and location to access system resources are explained by their authors' research papers. Commented [MW55]: Again it appears text has been cut
and pasted from elsewhere. No reference has been given so
how can the reader check the authors’ research papers?

Commented [MW56]: Why all the white space between

paragraphs?

Context-Based RBAC:
Context-Based RBAC In some instances, in which only the location and time
of access are not enough to determine access to specific resources. In these instances,
along with location and timing, context for the role when accessing resources is needed
[13]. In this case, the RBAC model is expanded to accommodate the environment in
that the role can be activated. The contexts were modeled using the events that allow
an action to take place within the environment, in the place from which the role is
activated, or the time when the role was active [14]. The semantic and context-based
model is proposed and utilized by the researchers conducting their studies to access
resources.

Organization-Based RBAC:
The authors of their research paper in [15] have recognized the challenges in
expressing the hierarchical relations between roles within RBAC (i.e.) that when the
roles of an organization are defined by an organizational hierarchy of roles, but the roles
that are portrayed by the role hierarchy are not clear in their terms of. In his work on
research the author has suggested the concept of "Organization-Based Access Control
(ORBAC)" to overcome the shortcomings of the inheritance relationships that are

31
present in current RBAC models by focusing on the context of the organization and the
role. A model for administrative use of ORBAC built on temporal context is suggested
in [16].

RBAC/ Extended RBAC Constraints supported by the RBAC Models

Models Location Time Context Collaborative
Environment
Location-Based RBAC Yes No No No
Models
Time-Based RBAC Models No Yes No No
Spatio-Temporal RBAC Yes Yes No No
Models
Context-Based RBAC Yes Yes Yes No
Organization-Based RBAC No Yes Yes No
Models
Task, Team and Coalition- No No No Yes
based RBAC Models
Table 2: Comparative Analysis Of Role-Centric RBAC Models [50]. Commented [MW57]: Examples of these models would help
explain how they work

3.8 Applications of RBAC and its extended models:

Although the idea of RBAC is used extensively in a variety of instances, there

may be some instances in which the basic idea of RBAC cannot be able to handle the
changes in the dynamic world. The software that supports the changing environment
must have extra features that can be included in the basic RBAC model.

Developments in RBAC Models:

The primary aspect to consider when it comes to RBAC design is the creation
of a standard for the model. Since the introduction of RBAC it has been acknowledged
and accepted as the primary model for supporting access control within an organization.
A consensus standard for the model has been accepted by the main standards body. Commented [MW58]: NIST?

32
 Other advancements in RBAC models comes from an administrative
perspective to think about other important aspects to employing RBAC models in
various applications, such as identifying roles and assigning roles to users and defining
the access control rules in a particular application. Roles are identified by Role
Engineering methods and there are numerous research in this field to determine the
roles by using roles mining techniques.
When the roles are defined for a particular application, The roles are assigned
to individuals who will use it. the assignment criteria are subject to the administration
policies. The specification of RBAC policies for an organization is another important
element that should be considered in implementing this RBAC model. Research
communities follow different terminology to describe the policies for access control in
their RBAC models.

Chapter 4 Commented [MW59]: New page

Research Opportunities Commented [MW60]: Is this your recommendations for

further work?

This section examines the research possibilities in RBAC that were identified
through the Literature survey. The latest research findings in RBAC have raised several
questions that lead to more research in this field. In the current technological age, the
amount of data that must be secured increase dramatically, while the system for access
must be able to meet the demands of today.

In our current world businesses' model of operation is evolving and the software
that supports the business needs behaves differently with the exact same person. This
means that based on the person's position and responsibility, the access rights to assets
within the company need to be restricted. Although RBAC models allow a certain
access control mechanism, there are some areas that this model should be studied. Here
are some areas of research that can be further explored in RBAC.

Ability to handle dynamic change with the rapid advancements in the area of
Information Technology like Cloud and IOT The support for the constant changes in

33
responsibility and roles is inevitable. The RBAC models must be updated to meet the
scalability of users, roles and resources.

Context Sensitive:
The conventional RBAC models define the role in terms of a static element and
the permissions assigned to the role are also defined. The issue of this system is its lack
of flexibility which are inherent in the application of the standard RBAC model in a
context sensitive setting. Due to the changing context, the roles as well as obligations
of users are evolving, which require permissions to be reviewed regularly.
The RBAC models must be expanded to accommodate the application in a context-
sensitive environment. Standardized Framework: While RBAC models are used
extensively uniform framework that supports the roles of an organization for accessing
the resources of the organization isn't in place and there's the need for a standardization
of an RBAC-based framework.

Security Metrics: Another research opportunity in this field is assessing the

degree of security for the resources within the company when resources are protected
by RBAC models. The metrics used to evaluate the RBAC models are necessary since
this can help identify the features that are required to improve security of resources.

Chapter 5 Commented [MW61]: New page

Risk in Role Based Access Control Model

Access control models do not change to the changing environment or

unexpected scenarios. With the advent of dynamic systems like that of Internet of
Things (IoT) with a greater number of objects that are scattered across the globe the
world, access control models are no longer relevant. Thus, models for access control
that are dynamic are needed. These models include not only access policies as well as
the context and data in real time in order to decide on access. One model which is
constantly changing is that of control access that is based on the risk. The model
assesses the security risks associated with the request for access in a fluid manner in
order to determine the most appropriate access decision. Recently, the model of access
control based on risk has been attracting the attention of a variety of research

34
organizations and research groups to allow greater flexibility when accessing the
resources of the system.

Security is the biggest challenge for all modern technology. The creation of a
security problems is the creation of a reliable and effective access control system. The
model helps control access to the system's resources by permitting only users to access
the system who are authenticated successfully. Access control models consist of three
primary elements that are system that make requests to access resource of the system
(targets). Rules are used to make the decision about access when the granting or deny
of access [17,18]. The main purpose of rules is to stop users who are not authorized and
to make it easier for the task that authorized users can perform on certain device. In
addition, it discourages any act that might result in an incident that could be considered
a security breach. [19].

There are two kinds of access control techniques that are both traditional and Commented [MW62]: Control techniques that are traditional
or dynamic?
dynamic. Traditional methods of access control use strict rules that are pre-defined for
making an access decision. These static rules give the same access control decision in
different circumstances. This rigid approach is not a solid security solution to different
situations. It is a distributed and dynamic approach platforms like cloud computing, the
Internet of Things (IoT) and cloud computing [2020. In addition, the methods for
controlling access dynamically utilize not only static policies, but as well real-time,
dynamic capabilities to determine access. These dynamic features may involve the
context of trust, history, times, events, locations and security risk.

The model of access control based on risk is among the most dynamic Commented [MW63]: Repeated phrase in the next
sentence
approaches that use the security risk score for every request for access to determine
access options. A model for access control based on risk offers a variety of advantages
over existing through the latest and relevant tools to make the accessibility decision.
Additionally, it considers the extraordinary and unpredictable access requests that are
crucial in certain areas, like military and healthcare in which granting access could
literally save the lives of thousands. The main purpose of the access control based on
risk model is to create an arrangement that encourages sharing of information for the
benefits of the organization, while simultaneously ensures that the users are accountable

35
for their actions. It also protects against collateral damage that is expected to be caused
by confidential information disclosure.

Access control is currently implemented at different levels in various areas like

databases management systems as well as Subjects represent various entities that may
be users, agents or any other type of process that sends requests to the system resource
(objects).

Description of objects which include the data, or any other type of information which
must to be accessible to people or other subjects.

Actions: represent the different kinds of actions that can be carried through using a
specific instance.

Privileges: They are permissions given to the subject to execute a specific action with
respect to a specific object. Commented [MW64]: Why have you adopted single
sentence paragraphs?

Access policies: They are a set of guidelines or procedures that outline the criteria used
to make the access decision of granting access is granted or denied for each access
request which is shown in the below Fig.13.

36
 Figure 13: Flow of an access control operation.

5.1 Traditional Access Control Models:

Access control that is traditional (also known as static or classical) methods rely
on results for various scenarios. While the more traditional methods of access control
have worked successfully used in various contexts to resolve various issues, they are
designed to create a link between the data that is associated with access control rule's
logic as well as an item for which access is required.
The application of a strategy can be manipulated that can result from an
unanticipated situation, such as inadequately access policies are written to different
criminals who gain access to accounts that are already in use. So, the traditional
approaches to access control come with several advantages, but they do have drawbacks.
One of these disadvantages is that they are not able to handle unexpected situations
because they are static and pre-defined policies [21].

This inflexible approach is not able to provide an adequate security strategy for
distributed and dynamic systems like IoT or Cloud Computing, which need greater
flexibility when accessing resources of the system. In contrast, this method of static

37
access is the most effective solution when there's not a way to identify a specific
characteristic or feature prior for operating system.

There are a variety of conventional approaches to control access, such as Access

Control List (ACL), Discretionary Access Control (DAC) along with Mandatory Deleted: d
Deleted: a
Access Control (MAC) and Role-Based Access Control (RBAC). ACL comprises an
Deleted: the
overview of all objects which are associated with the legal rights of users, as well as Deleted: m
Deleted: a
access rights. ACLs are utilized in many different platforms, including This means that
it is unable to handle an enormous number of subjects and objects.

DAC is designed for databases with multiple users and systems that have only Deleted: For
Deleted: it
a few known users. The person who is granted access and authorization which is
Commented [MW65]: What is it: many users or a few?
established using open policies. The owner of the object can allow any person access
to this object.

Every object is labeled which identifies the sensitivity of the object.

Additionally, every subject has a label which defines the object it has access to [22,23].
For RBAC it is comprised of three primary constituents: subject or user and their role
(collections of rights) and actions (activities carried out on the resources targeted) [24].
The foundation of RBAC is the role and roles, where each job is assigned an access
authorization. Every company has different roles, for example, employee, customer
manager, administrator, and so on. Users can be participants in one or more roles. A
job can require several users [25].

5.2 Dynamic Access Control Models:

The principle that drives these models of dynamic access control is to look at
not just access policy, but also contextual and dynamic elements which are gathered
during an access request to take access decisions which are collected during the process
of making access decisions. This provides more flexibility and allows for a greater
adaptation to different situations and circumstances when making the decision on
access. It is essential to implement methods for controlling access that are dynamic
should be among the top priority to offer a reliable as well as flexible control of access

38
models. But most of the access control methods rely on rigid and static access policies
as well as manual processes.

These methods can’t offer a plan for enhancing automation dramatically. The
lack of automation causes an extensive use in human analysis which is susceptible to
error and diverse types of attacks that are that are based on social engineering. In
addition, traditional methods are not able to resolve threats and risks in real-time,
particularly in the case of a previously undiscovered threat. This is because these
methods based on their access decisions on a set of rules developed by security analysts,
who is not able to solve different access control scenarios in real-time. But they can
deal with problems that are discovered prior [27].

Table 3 : Comparison between traditional and dynamic access control approaches.

5.3 Risk-Based Access Control Model:

Typically, the risk is that of injury or loss. It concerns an incident that could Commented [MW66]: What are you referring to here? It
could be a DDoSA.
occur soon and cause damages. Risk is defined as "the possible damage that may arise
from the existing operation or from some upcoming incident". The risk can be found
throughout our everyday life. From a security point of view, cybersecurity risk can be
defined by impact of a security breach that adversely impacts operations and the
information it contains as well as the process of identifying and reducing the impact of
problems that could result in an infringement of integrity, confidentiality or
accessibility an information system is often referred to as the risk management. [18].

39
 Security risks in the in the context of access control is the threat of leakage
information. The model of access control based on risk uses an assessment of the
security risk to serve as the criteria to determine the appropriate access decision for
every request. The model is based around an estimate of the risk to security related to
each request which is calculated dynamically and then is based on the estimated risk to
decide whether the request is approved should be granted or denied [4]. Mathematically
speaking, the most well-known method to express the risk that can be quantified in its
most basic form is the likelihood that an event is likely to occur. multiplied by its
consequences of that incident [19]. There are many ways to construct an access control
model that is based on risk.

They share certain elements from various methods. The fundamental risk-
access control methods are highlighted in the Fig.14. The model for access control that
is based on risk includes three main modules. It is the risk estimate that's the primary
module, which receives requests for access from users, examines them, gathers the
necessary details about risk factors and determines the security risk for every request.
The risk estimate estimated is then compared with access policy in order to decide on
access to grant or denied access. [20]

Figure 14: Main elements of a risk-based access control model.

40
Chapter 6
RBAC features and supporting policies

Hierarchy of roles as well as protected objects. In order to perform the function Commented [MW67]: Not a complete sentence.
Deleted: `
of an object controlled with RBAC it is required that a user be in a specific role. Before
a person is capable of being active in the role they are in, it is essential to have the user
granted access to the position by a security administrator. RBAC allows administrators
to limit the ability to authorize roles, or the activation of roles as well as the performance
of activities. Constraints can be implemented in different forms. Constraints are often
classified as mutual exclusivity or cardinality rules that can be applied in a manner that
is role-by role. Additionally, limitations are imposed on the authorization of an
operation to fulfill the role and in the execution of operations through objects (i.e. time,
location restrictions, etc.).

The sections below explain RBAC entities as well as provide specific

definitions of a range of scenarios of constraints.
Users, roles, and operations
Inside the framework user is the individuals who can perform many different
job functions and, in addition to an operation. This provides access to a variety of
secured RBAC objects. In Fig. 15 the word "subject" refers to an active user's workflow Commented [MW68]: Why not say work flow then?

by using one Arrow representing a one-to-many connection.

Figure 15: User and subjects.

The kind of operations and objects RBAC regulates are contingent on the type
of system the system in which it is implemented. For example, in the operating system
the operations could comprise read, write and execute. In the database management
system operations could comprise insert append, delete and update. In the framework
of the operation of a transaction management system could be modeled after and display
the features of transactions.

The objects that are included in the RBAC system comprises all objects that are
accessible via RBAC operations. But not all file object systems or system files are

41
required to be covered by any RBAC scheme. This includes as well as temporary items
(e.g. directories and temporary files) are not always managed in the RBAC protected
objects.

A unit is a place of control, which is defined by the roles that are subject to
regulations in the framework. A procedure can be utilized to collect security-related
information or restrictions that are not identified by a straightforward access method
[2]. The details could be related to both the model and the access.

RBAC operation, look at the distinct requirements for access of a teller as well
as an accounting supervisor at banks. An organization defines a teller's job as the ability
to carry out an operation for depositing savings. This requires write and read access to
fields of the file for savings. A company may also establish an accounting supervisor
role which can be entrusted with the responsibility of performing corrections.

These processes require write and read access to the same areas in an account
for savings like the banker. The accounting supervisor is not permitted to make deposits
or withdraws; however, they can only correct the transaction following the event. In the
same way, the teller cannot make, or corrections are made, or corrections are not made
until the model evaluates.

To highlight that granularity is an important aspect in control, think about the

necessity for a pharmacist to have access to the medical record of the patient to search
for interactions between the medications and make observations in the section where
prescriptions are listed. Although these actions are needed, pharmacists shouldn't be
able to alter or review other sections of the medical record of the patient.

Figure 16: Operations and objects.

If a role is authorized to a member of the user an account that is defined, the

user is given the ability to carry out the actions that are related to the role. Each

42
operation is identified by a unique identification number. Conceptualization of
operations and the connections between roles objects and actions as shown in above
Fig. 16. Commented [MW69]: Didn’t really show much.

6.1 Roles and role hierarchies:

Roles could have the potential to share roles and responsibilities which means
that users who belong to different roles might require common tasks. In addition, in
many companies there are many general tasks that are carried out by everyone in the
organization. Therefore, it could be inefficient and time-consuming to define these
operations in every role that is created. In order to increase efficiency and make the
structure that is natural to an organization,

RBAC incorporates the notion of hierarchies for roles. Role hierarchies define
roles with distinct characteristics and constraints which are related to a different
function. Role hierarchy is a natural method of organizing roles to show authority,
accountability, as well as competence. The members of the post Specialist
automatically share the responsibilities, constraints and responsibilities of Intern and
Doctor

In Fig.17 there are no prerequisites for roles to be connected. The roles of

Rheumatologist and Cardiologist aren't hierarchically, they may contain one or all the
roles.

43
 Figure 17: Example of a role hierarchy.

6.2 Role authorization:

The affiliation of a person with the role of a user is dependent on the following:
• The user may be granted only the privilege that is required to
complete his or her job.
• The function for which the user has gained membership is not in
conflict with a different role in that the member already has
membership.
• The numerical limit that is set for membership in a role cannot
be exceeded.

The primary purpose of this property is to guarantee compliance with the

principle of least privilege. It is a principle that Least Privilege demands that a user
receive only the privileges necessary to fulfill the task at hand. In order to ensure least
privilege, you must identify the job duties of the user in order to determine the minimum
rights required to fulfill the job and limiting the user's access to a particular domain that

44
has those privileges, and only that. For non-RBAC implementations, this can be
expensive or difficult to attain.

In a system that is based on capability, a person marked to a particular role

category could be given greater authority than they need due to the inability of systems
based on capability to adjust access according to certain attributes or limitations. Since
a lot of the responsibilities are shared between job categories, having the highest
privileges for each job can result in illegal access. Who are assigned to those roles, and
that their activities and roles are subject to the policies of the organization. When the
activities are interconnected, and roles are overlapping.

It is possible for doctors to have access to the entire patient record as they are
effectively controlled. This may require numerous audits and monitoring that is not
required by the more precise access control system. In RBAC restrictions on access for
doctors, which mean that for example, only the records of certain doctors are available.

6.3 Role activation:

Every subject is the mapping of a user to one or perhaps many roles. A user
initiates an account that is enrolled in a subset of roles in which they have membership.
The authorization of a user's role (which is the result of membership in a role) is an
essential but it's not always a requirement to be authorized an operation. Other
considerations related to organizational policies or restrictions may have to be
considered in granting users permission to conduct tasks.

Role activation is the basis to which the policies of an organization can be

implemented. In this way, RBAC demands that the user must be cleared as active in
their role prior to when they can take any action.
Based on the policies of the organization that is being considered the checks are made
based on the role that is being activated, the action that is requested to execute, or the
object being accessing. This means that a role may be activated if:

• The user has been legally authorized to perform the role

suggested for activation.

45
 • The performance of the role proposed is not mutually exclusive
to the other role(s) that the individual user is playing.
• The operation being proposed is authorized for the function that
is being considered for activation
• The proposed operation is compatible with a required sequence
of operations

6.4 Operational separation of duty:

RBAC can be utilized by system administrators to enforce a rule for Operational
Separation of Duty. Operational Separation of Duties is a useful strategy in preventing
fraud. The reason for this is the notion that fraud could occur when collaboration is
established between different functions that are essential to a job. For instance, the job
of purchasing an item may include the following steps such as authorizing the purchase
making a note of the receipt of the invoice, which records the delivery of the item, and
finalizing the payment. payment is authorized when all the steps are carried out by
different individuals, the possibility of fraud may be decreased. If only one person is
permitted to perform all activities, there is a possibility that fraud could occur.

The Operational Separation of Duty requires that each operation associated with
specific business process, only one individual can carry out all these functions. So, the
inability of one role to function in the manner expected can be detected by the company.
In RBAC terms it is it is possible to enforce the Operations Separation of Duty policy
is implemented to roles that are defined by the individual user and the operation are
assigned specific roles.

Accessing objects:
To ensure that the implementation of policies of the enterprise concerning
RBAC objects. Access of those users of RBAC objects must be controlled. These
functions can be employed to determine object.

Through the Role Authorization and Role Execution properties and the
Operation Access Authorization property defined below will ensure that the person's
ability to gain access to an RBAC object is granted only by authorized actions
performed through active roles that are authorized.

46
Chapter 7
Proposed Model

7.1 Attributed Role Based Access Control Model:

Access control based on role (RBAC) is acknowledged as a result of its security

and easy management of access rights. But it also has flaws, including the complexity
of roles and the lack for dynamic behaviors. ABAC, or attribute-based access control
(ABAC) is an access control system that is dynamic that allows for easy role structure.
The analysis of roles and permissions following the implementation of access control
models and managing it isn't simple to do in ABAC.

A model for access control is designed to combine the advantages that are
present in RBAC and ABAC as well as removing certain weaknesses in these models
as shown in t. The model is designed to implement and utilizes the characteristics of
objects and permissions, roles and users to form the basis. Furthermore, the model
proposed makes use of the capacity to structure the role that is a part of ABAC and the
strict security capability of RBAC.

Controlling access is the technique that allows the system to grant access control
to users denies access to certain data or to carry out any act. The information must be
secured from both internal and from security threats external to the organization. Most
risks originate from the organization internal security. Access control can be regarded
as a security measure to protect against threats to security within the company. Role
Based Access Control (RBAC) is an advancement in the area of control over access
[28]. The basic concept behind RBAC is roles that will be used to the authorizations
will be assigned to the appropriate roles. Users do not have direct access to permissions.
Role acts as an intermediary between permissions and users. Users are assigned roles
in order to benefit from different privileges. RBAC is renowned for its secure and strong
access control system and facilitates management of administrators as well. In addition,
the process of shaping and designing access control system for an individual
organization is a challenging and demanding job RBAC.
ABAC is the fact that it does not grant permissions directly to objects or users
but allows any authorization that is by attributes [30] and attributes and attributes [30].

47
The attribute's value determines whether a user has been licensed to access a specific
item or is not.

A user may be referred to as subject. ABAC is an adaptable model that is much

more user-friendly than RBAC. ABAC allows for easy structuring roles, as well as
flexible and simple design system for controlling access within an organization.
However, the analysis of permissions and altering permissions for users is a challenge
or difficult to accomplish within ABAC. It's no secret that RBAC is easy to manage as
well as analysis and evaluation of the access control systems, but it also faces
complicated design issues with regard to roles and structuring specific to an company.
In the same way, ABAC model is also capable of creating and structuring roles however,
analyzing and managing it is not an easy task [31The model is not easy to manage and
analyze [31. There isn't a model that offers ease of the design of roles, creation within
an organization, and the ability to analyze or altering user permissions.

However, ABAC facilitates the installation of access control systems by using

attributes, but it doesn't allow for a smooth management experience for administrators.
Thus, it is possible to find an approach that allows the security of the system and
management ease for the administrators, and the ease of creating roles that are
dynamically triggered.

48
 Figure 18: Model comparison of RBAC and ABAC Commented [MW70]: Font size in the figure (table?) makes
it hard to read
The above Fig.18. clearly mentions about the strengths and weakness of ABAC and
RBAC.

Figure 19: Feature of RBAC and ABAC Commented [MW71]: The above table appears to be an
object. Was it copied from elsewhere and not referenced? Why
not just create it yourself?

49
 The concept of attributes was utilized to create the models. Permissions may be
assigned to roles and roles assigned to individuals is based on the application of
attributes.

Figure 20: Automatic Permission Creation Commented [MW72]: You can’t just keep adding figures
because they are available. They have to add something to
your report, be referenced if it is other people’s work and
Automated Permission Creation utilizing actions levels and objects container explained in the text.

for objects with the levels of actions which is shown in Fig.20. Permissions can be
granted when the actions and objects are joined. The model has different levels of
security, and each level comes with defined actions. Level 1 in Fig.20 includes edit,
read, or delete action. Level 2 includes edit, read and write actions. Level 3 is a
combination of only write and read actions.

The action levels are created in accordance with the organization structure.
Administrators can design additional action levels as necessary. Additionally, objects
containers have been designed for to store objects. Containers of various sizes can be
designed to store objects. Containers are assigned to objects according to the type of
object. If object is assigned to containers, the container will be applied at the level of
action. This process automatically creates the necessary permissions. In the above
illustration the container 1, which has four objects will be applied up to level 2 of action
and level 2 has three actions. If the container 1 is placed in the action level 2 then seven
permissions are added. Administrators can apply a specific container at the level of
action and keep with regard to the extent of access to these objects in terms of the
accessibility to them.

50
 Figure 21: Attributed Permissions in RBAC Model

The creation of a new object occurs by assigning attributes to objects, such as

the IP address of an object, its time, and owner. These attributes are assigned
permissions in a way that is automatic, and they contain similar attributes that are
present in objects. The permission that was created performs the same purpose as shown
in Fig.21. Once a user has been given this privilege, he they are capable of only
performing an action specific to the object within the defined time frame.

The model is dynamic and provides the convenience of creating permissions

through attributes, as well as the robust and simple management of permission creation
thanks to permission creation using the RBAC model. Above, Fig.21 illustrates the
attributes view using RBAC model and the automated process of creating permissions
thanks to using action level as well as container objects.

Automatic Assignment of Permission to Roles by using Attributes:

This can be a stressful task to the admin. Structure of roles the structure of roles
in RBAC is a difficult task. In this model, the criterion for assigning permissions is
automated which will reduce the burden of the administrator determination to assign
permissions are done through attribute expressions i.e., shown in Fig.22.

51
 Figure 22: Attributed RBAC Model
Each object is unique and comes with its own characteristics like IP address,
name as well as time, hostname, etc. The model discussed here is based upon the
attributes of objects that are specified at the time of creation. The image above provides
an entire image of the attributes RBAC model. After defining what attributes, the object
has at the point of its creation, objects get assigned to objects, and the objects are put in
containers on security levels. Each security level is characterized by various actions as
described in the previous paragraphs. The application of object containers to the
security level automatically grants permissions and objects' attributes will be copied in
order to be compatible with access attributes. If permissions are given automatically, is
done by the match of these attributes. In this case, it is possible to create a role with an
attribute IP that has the value 192.168.1.1 and the permissions that are the same attribute
are automatically assigned to the role as illustrated in the Fig. 23.[44].

52
 Figure 23: Permissions Assignment to Roles
Formulation of the Modified Model regarded as a simple modeling system that
can verify the internal stable that is inherent to RBAC along with other mathematical
properties [16]. The non-conflict model for RBAC has been developed using Alloy
syntax, [17]. Its formal definition is given in the following manner.

Specification

UAS = USERS x ROLES, a many-to-many user to role assignment relationship.

Users assigned to: (r:ROLES) 2-Users The mapping of the role r to users.

Formally:

assigned_users(r) equals (u,r) UA

PA = PRMS = ROLES the mapping of permissions to roles.

Permissions assigned (r:ROLES) 2 PRMS mapping of role R to a set of permissions. Commented [MW73]: This does not explain or add anything
to your report.

53
7.2 Example Study on Learning Management System :

We have looked at the possibilities that an education administration system

(LMS) that is used by the educational sector. Within an LMS teachers can provide
homework online and online tests. They also allow online attendance and studying
materials, like [41].

Teachers are the sole source of authority for students. Teachers can decide on
the authority of the student within an LMS. Teachers can create a variety of files for
students to use, including studies materials like slides pdfs, slideshows, Word
documents, etc.

they'll get access for every student or group of students. They will also decide the level
of authority for the students with access to the files [43].

They can access their study materials from anywhere anytime whenever they
log in using their username. In this case, the marking sheets and study materials will be
saved to an LMS using username attributes to allow students access to the files at any
point in time.

The attendance and quizzes documents are uploaded using dates and times. The
location attribute may be used to identify the IP address since students are only able to
record their attendance when they are at the correct time for class. The exam files are
accessible only for students who log in to the university system, since the university
systems can be identified using their IP addresses.

Use this example from the lower portion of the Model (Object levels). Teacher
uploads course outline files, as well as pdf books as well as power point slides from the
class. The teacher also defines the characteristics in the document. Since the files are
general, they must be accessible to every student who are in class. Students can access
edit, as well as download the file [42].

54
 All the files are included in the same object container and will be implemented
at the action level to automatically assign permissions. Different levels of actions were
formulated by the administrator, in accordance with the Fig.24.

Figure 24: Object Containers and Action Levels Commented [MW74]: See my previous comments.

If container 1 is used in the context of the first action, nine permissions will be
automatically created. The attributes of objects are transferred onto the appropriate
permissions. After that, the container is added to the second level of action. Level 2 of
action consists of three steps: create, read, create and send. When Container 2 is utilized
at stage 2 and six permissions are added. Container 1 contains studies materials, and
they can be downloaded, read and downloaded from any location, however container 2
contains the worksheets and quizzes files. The files can only be accessed via the lab
systems of the university.

The decision of the authority is based by analyzing characteristics, and the

actions are applied to the files. The lab assignment and the online tests are only provided
to teachers as well as to students who are within the labs of the university. This is the
reason why the files are used on the second level of operation. The list of permissions
that automatically apply is listed in the table below [43].

55
 The properties of the objects' attributes are copied to permissions, and then
based on the permission attribute, permissions will be assigned roles based on the table
4. Permissions from P1 to P9 are instantly be assigned to role 1 as their attributes are
similar. Permissions P10 through P15 will be allocated to role 2 and 3, due to their
common attributes. Additionally, Role1 users will allowed access to the system the
system when they sign in with their username within or outside the University. Role2
is only accessible to those who log in using university IP addresses during the
designated time slots. The entire process is automated and dynamic [44].

Figure 25: Permission assignment to Roles and Roles to Users Commented [MW75]: See my previous comments

Automatic permission creation is achieved is accomplished by applying the

objects containers to action levels. Once you have selected an object container as well
as an action level, the administrator will begin the process of creating permissions. The
permissions assigned are automatically created. Administrators can view the newly
granted permissions.

56
Chapter 8
Conclusion:

The main reasons behind RBAC are its ability to define and enforce specific
enterprise security policies as well as simplify the often-time-consuming process of
managing security. As mentioned above, RBAC is a framework with a variety of
policies-rich mechanisms and its configuration depends on the organizational policies.
This makes RBAC to adapt in any structure or ways to conduct business. Additionally,
the policies that are that are implemented by RBAC can change over time as business
and organizational structure and security requirements evolve. RBAC improves
efficiency for security administrators, leading to fewer errors and a higher level in Deleted: less

operational security [45].

The model proposed has reduced administrative burdens since all the tasks like
the creation of permissions, permissions, role assignment, and user assigning roles has
been taken care of with attributes which are automated. The model offers flexibility,
efficiency in management as well as an automated role structuring facility. The model
is secure as the basic principles of the model are like what RBAC does, but the model
is evolving because of the inclusion of attributes. In the future we will be working on
conflicting permissions and incorporate this concept into our model.

57
References: Commented [MW76]: Do you have URLs for any of these
references?

[1] M. Al-Kahtani and R. Sandhu, "A model for attribute-based user-role assignment,"
in 18th Annual Computer Security Applications Conference, 2002, pp. 353-362.
[2] R. Kuhn - V. C. Hu, R. Kuhn, and D. Ferraiolo, "Attributebased access control,"
IEEE Computer Society, pp. 85-88, 2015
[3] Armando, A.; Bezzi, M.; Di Cerbo, F.; Metoui, N. Balancing trust and risk in access
control. In Lecture Notes in Computer Science (Including Subseries Lecture Notes in
Artificial Intelligence and Lecture Notes in Bioinformatics); Springer
Science+Business Media: Berlin, Germany, 2015; Volume 9415, pp. 660–676.
[4] Rahmati, A.; Fernandes, E.; Eykholt, K.; Prakash, A. Tyche: A risk-based
permission model for smart homes. In Proceedings of the 2018 IEEE Cybersecurity
Development Conference, SecDev 2018, Cambridge, MA, USA, 30 September–2
October 2018; pp. 29–36.
[5] Dankar, F.K.; Badji, R. A risk-based framework for biomedical data sharing. J.
Biomed. Inform. 2017, 66, 231–240. [CrossRef]
[6] Atlam, H.F.; Alenezi, A.; Walters, R.J.; Wills, G.B. An overview of risk estimation
techniques in risk-based access control for the internet of things. In Proceedings of the
2nd International Conference on Internet of Things, Big Data and Security, Porto,
Portugal, 24–26 April 2017.
[7] Atlam, H.F.; Alassafi, M.O.; Alenezi, A.; Walters, R.J.; Wills, G.B. XACML for
Building Access Control Policies in Internet of Things. In Proceedings of the 3rd
International Conference on Internet of Things, Big Data and Security (IoTBDS 2018),
Madeira, Portugal, 19–21 May 2018.
[8] Sandhu, R.S., Coyne, E.J., Feinstein, H.L., Youman, C.E.: Role-Based Access
Control Models. IEEE Computer 29(2), 38–47 (1996)
[9] Hu, V. C., Kuhn, D. R., & Ferraiolo, D. F. Attribute-based access control. Computer,
(2), 85–88, IEEE Computer Society, 2015.
[10] Arjumand Fatima, Yumna Ghazi, Muhammad Awais Shibli and Abdul Ghafoor
Abassi,Towards Attribute-Centric Access Control: an ABAC versus RBAC argument,
Security Comm. Networks 2016; 9:3152–3166, 2016 John Wiley & Sons, Ltd.
[11] Elisa Bertino And Piero Andrea Bonatti And Elena Ferrari, “TRBAC: A Temporal
Role- Based Access Control Model”, ACM Transactions on Information and System
Security, Vol. 4, No. 3, August 2001, Pages 191–223.

58
[12] James B D Joshi, Elisa Bertino, Arif Ghafoor, “Temporal Hierarchiesand
Inheritance Semantics for GTRBAC”, in Seventh ACM Symposium on Access Control
Models and Technologies (SACMAT 02), Monterey, California, USA, June 2002.
[13]Muhammad Nabeel Tahir, “C-RBAC: Contextual Role-Based Access Control
Model”, Ubiquitous Computing and Communication Journal, Volume 2, Number 3,
2008.
[14]Kosmas Alexopoulosa, Sotiris Makrisa, Vangelis Xanthakisa, Konstantinos
Sipsasa, Aggelos Liapisb, George Chryssolourisa, Towards a role-centric and context-
aware information distribution system for manufacturing, The International Scientific
Committee of the 8th International Conference on Digital Enterprise Technology - DET
2014 – “Disruptive Innovation in Manufacturing Engineering towards the 4th Industrial
[15] Elisa Bertino And Piero Andrea Bonatti And Elena Ferrari, “TRBAC: A Temporal
Role- Based Access Control Model”, ACM Transactions on Information and System
Security, Vol. 4, No. 3, August 2001, Pages 191–223.
[16] Ouarda Bettaza, Narhimene Boustiab, Aicha Mokhtaric, “Dynamic delegation
based on temporal context”, 20th International Conference on Knowledge Based and
Intelligent Information and Engineering Systems, Procedia Computer Science, 2016
Revolution”, Published by Elsevier B.V.
[17] Dos Santos, D.R.; Westphall, C.M.; Westphall, C.B. A dynamic risk-based access
control architecture for cloud computing. In Proceedings of the IEEE/IFIP NOMS
2014—IEEE/IFIP Network Operation and Managment Symposioum, Krakow, Poland,
5–9 May 2014; pp. 1–9.
[18] Liu, J.K.; Au, M.H.; Huang, X.; Lu, R.; Li, J. Fine-Grained Two-Factor Access
Control for Web-Based Cloud Computing Services. IEEE Trans. Inf. Forensics Secur.
2016, 11, 484–497. [CrossRef]
[19] Suhendra, V. A Survey on Access Control Deployment. In Communications in
Computer and Information
Science; Kim, T., Adeli, H., Fang, W., Villalba, J.G., Arnett, K.P., Khan, M.K., Eds.;
Springer: Berlin/Heidelberg, Germany, 2011; Volume 259, pp. 11–20.
[20] Chen, P.; Pankaj, C.; Karger, P.A.; Wagner, G.M.; Schuett, A. Fuzzy Multi—Level
Security: An Experiment on Quantified Risk—Adaptive Access Control. In
Proceedings of the 2007 IEEE Symposium on Security and Privacy (SP’07), Ouckland,
CA, USA, 20–23 May 2007; pp. 222–227.

59
[21] Metoui, N. Privacy-Aware Risk-Based Access Control Systems. Ph.D. Thesis,
University of Trento, Trento, Italy, May 2018.
[22] 11. Bugiel, S.; Heuser, S.; Sadeghi, A.-R. Flexible and fine-grained mandatory
access control on Android for diverse security and privacy policies. In Proceedings of
the 22nd USENIX Security Symposium,Washington, DC, USA, 14–16 August 2013;
pp. 131–146.
[23] Hulsebosch, R.J.; Salden, A.H.; Bargh, M.S.; Ebben, P.W.G.; Reitsma, J. Context
sensitive access control. In Proceedings of the Tenth ACM Symposium on Access
Control Models and Technologies, Stockholm, Sweden, 1–3 June 2005; pp. 111–119.
[24] Bijon, K.Z.; Krishnan, R.; Sandhu, R. A framework for risk-aware role based
access control. In Proceedings of the IEEE Conference on Communications and
Network Security, National Harbor, MD, USA, 14–16 October 2013; pp. 462–469.
[25] Kumar, A.; Karnik, N.M.; Chafle, G. Context sensitivity in role-based access
control. Oper. Syst. Rev. 2002, 36, 53–66. [CrossRef]
[26]. Wang, Q.; Jin, H. Quantified risk-adaptive access control for patient privacy
protection in health information systems. In Proceedings of the 6th ACM Symposium
on Information, Computer and Communications Security—ASIACCS ’11, Hong Kong,
China, 22–24 March 2011; pp. 406–410.
[27]. Brooks, T.; Caicedo, C.; Park, J.S. Security Vulnerability Analysis in Virtualized
Computing Environments./ Int. J. Intell. Comput. Res. 2012, 3, 263–277. [CrossRef]
[28] A. INCITS, "Incits 359-2004, Role based access control," ed: American National
Standard for Information Technology, 2004
[29] H. Vincent, D. Ferraiolo, R. Kuhn, A. Schnitzer, K./ Sandlin, R. Miller, et al.,
"Guide to Attribute Based Access Control (ABAC) Definition and Considerations,"
NIST Special Publication, vol. 800, p. 162, 2014.
[30] X. Jin, R. Krishnan, and R. Sandhu, "A unified attribute-based access control
model covering DAC, MAC and RBAC," in Data and applications security and privacy,
ed: Springer, 2012, pp. 41-55.
[31] B. Stepien, S. Matwin, and A. Felty, "Advantages of a non-technical XACML
notation in role-based models," in Ninth Annual International Conference on Privacy,
Security and Trust (PST), 2011, pp. 193-200.
[32] M. U. Aftab, A. Nisar, M. Asif, A. Ashraf, and B. Gill, "RBAC Architectural
Design Issues in Institutions Collaborative Environment," International Journal of
Computer Science Issues, vol. 10, pp. 216-221, 2013.

60
[33] A. INCITS, "Incits 359-2004, Role based access control," ed: American National
Standard for Information Technology, 2004.
[34] M. A. Habib and C. Praher, "Object based dynamic separation of duty in RBAC,"
in International Conference for Internet Technology and Secured Transactions 2009,
pp. 1-5.
[35] D. Ferraiolo, R. Kuhn, and R. Chandramouli, Rolebased access control: Artech
House, 2003.
[36] R. Kuhn, E. J. Coyne, and T. R. Weil, "Adding attributes to role-based access
control," Computer, vol. 43, pp. 79-81, 2010.
[37] H. Vincent, D. Ferraiolo, R. Kuhn, A. Schnitzer, K. Sandlin, R. Miller, et al.,
"Guide to Attribute Based Access Control (ABAC) Definition and Considerations,"
NIST Special Publication, vol. 800, p. 162, 2014.
[38] X. Jin, R. Krishnan, and R. Sandhu, "A unified attribute-based access control
model covering DAC, MAC and RBAC," in Data and applications security and privacy,
ed: Springer, 2012, pp. 41-55.
[39] B. Stepien, S. Matwin, and A. Felty, "Advantages of a non-technical XACML
notation in role-based models," in Ninth Annual International Conference on Privacy,
Security and Trust (PST), 2011, pp. 193200.
[40] V. C. Hu, R. Kuhn, and D. Ferraiolo, "Attribute based access control," IEEE
Computer Society, pp. 85-88, 2015.
[41] M. Al-Kahtani and R. Sandhu, "A model for attribute-based user-role assignment,"
in 18th Annual Computer Security Applications Conference, 2002, pp. 353-362.
[42] R. Sandhu, E. Coyne, H. Feinstein, and C. Youman, "Role-based access control
models," IEEE Computer, vol. 29, pp. 38-47, 1996.
[43] J. S. Park, R. Sandhu, and G.-J. Ahn, "Role-based access control on the web,"
ACM Transactions on Information and System Security (TISSEC), vol. 4, pp. 37-71,
2001.
[44] Y. Zong, B. Bhargava, and M. Mahoui, "Trustworthiness based authorization on
WWW," in IEEE Workshop on Security in Distributed Data Warehousing, 2001.
[45] S. Verma, M. Singh, and S. Kumar, "Comparative analysis of Role Base and
Attribute Base Access Control Model in Semantic Web," International Journal of
Computer Applications, vol. 46, 2012.
[46] J. Zao, H. Wee, J. Chu, and D. Jackson, "RBAC schema verification using
lightweight formal model and constraint analysis," Submitted to SACMAT, 2003.

61
[47] A. Schaad and J. D. Moffett, "A lightweight approach to specification and analysis
of role-based access control extensions," in Proceedings of the seventh ACM
symposium on Access control models and technologies, 2002, pp. 13-22.
[48]http://xuctarine.blogspot.com/2016/08/apache-fortress-easiest-way-to-get-
full.html?m=1
[49]https://www.avatier.com/products/identity-management/resources/gartner-iam-
2020-predictions/
[50] Suganthy A and Dr. V Prasanna Venkatesan, Role-Centric RBAC Models – A
Literature Review. International Journal of Computer Engineering and Technology,
9(5), 2018, pp. 201-213.
[51] https://www.ekransystem.com/en/blog/rbac-vs-abac

62