IN DEGREE PROJECT INFORMATION AND COMMUNICATION TECHNOLOGY,SECOND CYCLE, 30 CREDITS

, STOCKHOLM SWEDEN 2017

Mathematical Modelling of Delegation in Role Based Access Control

HARENDRA SUBEDI

KTH ROYAL INSTITUTE OF TECHNOLOGYSCHOOL OF INFORMATION AND COMMUNICATION TECHNOLOGY

Abstract

One of the most widespread access control model that assigns permissions to a user is Role Based Access Control (RBAC). The basic idea is to limit the access to resources by using the indirection of roles, which are associated both to users and permissions. There has been research conducted with respect to clarifying RBAC and its components, as well as in creating mathematical models describing different aspects of its administrative issues in RBAC. But, till date no work has been done in terms of formalization (Mathematical Modelling) of delegation and revocation of roles in RBAC. Which provides most important extensions of the policy and provides flexibility in the user to user delegation of roles, especially in the environment where roles are organized in a hierarchy. The process allows a user with a role that is higher in the hierarchy to assign a part of the role to someone who is lower in the hierarchy or at the same level. This can be done for a limited time or permanently. The reverse process is called revocation and it consists of ending different types of delegations. This thesis has found the answer to the following research question i.e. how different mathematical Modelling for delegation and revocation of Roles in RBAC can be performed? This thesis presents different types of delegation and techniques for revocation with a comprehensive mathematical Modelling of both processes. As this can be clearly visible that this thesis objective is to derive a mathematical models for delegation and revocation of roles in RBAC policy, for deriving mathematical models formal method is applied. The mathematical models developed include grant and transfer delegation with and without role hierarchy, time based revocation, user based revocation and cascading revocation. The case scenario of an organization using RBAC is used to illustrate and clarify the mathematical models. The mathematical models presented here can serve as a starting point for developing, implementations of delegation and revocation on top of existing authorization modules based on the RBAC model. Keywords Delegation; RBAC; Role; Revocation; Role Hierarchy; Formal Methods

i

Table of Contents

1 Introduction ................................................................................................................. 1 1.1 Background ..................................................................................................................... 1 1.2 Problem............................................................................................................................. 2 1.3 Research Questions ...................................................................................................... 3 1.4 Purpose ............................................................................................................................. 3 1.5 Goal ..................................................................................................................................... 3

1.5.1 Benefits, Ethics and Sustainability .................................................................................. 4 1.6 Methodology / Methods .............................................................................................. 4 1.7 Limitations ....................................................................................................................... 5 1.8 Structure of Thesis ........................................................................................................ 5

2 Extended Background and Related Concepts .................................................. 6 2.1 Security Policy ................................................................................................................ 6 2.2 Access Control................................................................................................................. 6 2.3 Role Based Access Control ......................................................................................... 8

2.3.1 Concept ....................................................................................................................................... 8 2.3.2 Example of RBAC Implementation .................................................................................. 8 2.3.3 Flat RBAC ................................................................................................................................... 8 2.3.4 Role Hierarchy ......................................................................................................................... 9 2.3.5 Hierarchical RABC ................................................................................................................10

2.4 Delegation ...................................................................................................................... 11 2.4.1 Concept .....................................................................................................................................11 2.4.2 Temporary Delegation .......................................................................................................12 2.4.3 Permanent delegation ........................................................................................................12 2.4.4 Delegation at the Same Level ...........................................................................................12 2.4.5 Risk with Delegation ...........................................................................................................12 2.4.6 The State of RBAC System with Delegation ...............................................................13

2.5 Revocation ..................................................................................................................... 13 2.5.1 Concept .....................................................................................................................................13 2.5.2 Revocation Techniques ......................................................................................................14

2.6 RBAC96 Model .............................................................................................................. 14 2.7 Previous studies on RBAC ........................................................................................ 15

3 Method ........................................................................................................................ 17 3.1 Method used for the research ................................................................................. 17 3.2 Methodology .................................................................................................................. 17

3.2.1 Literature Review .................................................................................................................17 3.2.2 Implementation of Formal Method ...............................................................................18

3.3 Alternative Methods ................................................................................................... 19

4 Mathematical Modelling of RBAC with Delegation and Revocation ...... 20 4.1 Introduction .................................................................................................................. 20

4.1.1 Definition of RBAC Policy ..................................................................................................20 4.1.2 Properties of RBAC Policy .................................................................................................20

4.2 Example Scenario /Case ............................................................................................ 21 4.3 Definition of delegation ............................................................................................ 23 4.4 Modelling of Grant/Temporary Delegation ....................................................... 25

4.4.1 Modelling of One Step Grant Delegation in Flat Role (RBAC0) ..........................25 4.4.2 Modelling of One Step Grant Delegation in Role Hierarchy (RBAC1) ..............26 4.4.3 Modelling of Two Step Grant Delegation in Role Hierarchy ...............................26

ii

4.4.4 Modelling of K Steps Delegation in the Role Hierarchy ........................................27 4.5 Modelling of Transfer/Permanent Delegation ................................................. 28

4.5.1 Transfer Delegation in RBAC0 or RBAC1 .....................................................................28 4.6 Definition of Revocation ........................................................................................... 29

4.6.1 Time Based Revocation ......................................................................................................30 4.6.2 K steps Delegation and Revocation with Time .........................................................31 4.6.3 User Based Revocation .......................................................................................................31 4.6.4 Cascading Revocation .........................................................................................................32 4.6.5 Modelling of Revocation of Permanent Delegation ................................................36

4.7 Implementation ........................................................................................................... 36 4.7.1 Introduction ............................................................................................................................36 4.7.2 User to permission ...............................................................................................................37

4.8 Which user can delegate what role? ..................................................................... 37 4.8.1 Is the user allowed to receive delegation? .................................................................38 4.8.2 How delegation is performed? ........................................................................................38

5 Conclusions and Future work ............................................................................. 40 5.1 Discussion ...................................................................................................................... 41 5.2 Future work ................................................................................................................... 42

References .......................................................................................................................... 43

Appendix 1 ......................................................................................................................... 45 Definition of the Terms ........................................................................................................... 45

Appendix 2 ......................................................................................................................... 46 Notation and Symbols .............................................................................................................. 46

Appendix 3 ......................................................................................................................... 47 List of Abbreviations ................................................................................................................ 47

1

1 Introduction

1.1 Background

In today's competitive world the, appropriate use of Information and Communication Technology (ICT) by enterprises has become a major advantage against their rivals. Every business ranging from very small company to gigantic enterprises depends on the ICT infrastructure and the way it is used. Most of the research conducted by different business groups and independent researchers shows that businesses that adapt to new technological changes quickly gain huge benefits. However, this could be a hard task for organizations due to the growing complexity of the technology and the extensive number of persons who use it. Various kinds of vulnerabilities in the technical structure could create loopholes for unauthorized people to access the system easily and expose sensitive information to the public. Hence, it is necessary to protect resources from unauthorized use. Access control is concerned with determining the allowed activity for each of the legitimate users with respect to every resource in the system. Usually, the administration defines which persons can access what resources at particular time and enforces the policies through control mechanisms of the system in place. For system administrators in big organizations with large network infrastructure and number of employees applying access control has become a problem. Consequently, there is ongoing research with respect to better understanding and easier management of access control.

An access control system comprises of access control policies, models and mechanisms. The policies determine how access is allocated, or who is granted the right to a particular resource (information) at a certain time. Policies may span multiple computing platforms and applications and are usually based on the authority, competence of the person or other organizational issues. One of the often used policies is the Role Based Access Control (RBAC), where the access to users is granted based on the role or the activities performed.

Access control policies are enforced through access control mechanisms provided by the system associated with the resource. Security models are often written to describe security properties of an access control system. Mathematical models are actually formal presentations of the security policy enforced. For example if a policy states that A and B can access some computer system C. Then, the security model is authentication (If A, B then C), and the mechanism could be a built in password system that checks whether the user has entered a password for A or B.

The basic idea behind implementing the access control is to limit the use of resources to the users by granting or denying them the access. In recent years, intense research has been conducted to shed light in the field of RBAC and its component such as implementation, revising the definition, etc. In, addition, techniques for formal specification using mathematical tools have been developed for the role based access policies.

Delegation can be defined as temporary or permanent assignment of power, authority, and responsibility to the user having junior role in order to perform

2

certain task on behalf of the user having senior role (Ferraiolo & Kuhn, 1992) (Barka & Sandhu, 2000). Delegation is done by the user having senior role so as to make the user having junior role equally responsible and powerful as the user having the senior role for certain tasks and it also allows for distributing tasks uniformly. Delegation comes in two flavour and they are permanent and temporary delegation. The process of taking away the privileges and the power of user is known as revocation (Barka & Sandhu, 2000). Once the privilege has been revoked, then the user is no longer associated with the role (Barka & Sandhu, 2000) (Barka & Sandhu, 2004) and holds no responsibility towards that role. Revocation is the process of removing the delegation obtained by the user (Barka, 2002) (Barka & Sandhu, 2004). Revocation can be performed by the user who has delegated the roles or the senior user to that role who has delegated the roles or the security manager. The nature of the revocation depends upon the nature of the delegation.

A mathematical model is a model that describes beliefs about the system or functions or describe the system using mathematical language or mathematical concept. In other word It can also be defined as formulating ideas and identify underlying assumptions in terms of mathematical language. Mathematical modelling is the process of developing mathematical models (Marion, 2008).

Models are of interest to administrators for easier management and to vendors for satisfying users’ needs. They are placed between the policy and the mechanism. Hence, often the same name is used for the policy and the model.

1.2 Problem

In the field of information and communication system security, a lot of research has been conducted in the last few years to augment the security. In particular, a lot of effort has been put in protecting the system resources from unauthorized users. The main problem was to find a mechanism for giving the right person access to the right resources at the right time. Several researchers have come up with the idea of implementing an access control mechanism, such as MAC (Mandatory Access Control), DAC (Discretionary Access Control), RBAC (Role Based Access Control), (Kuhn, et al., 2010) (Ferraiolo, et al., 1995) (Sandhu, et al., 1996) (Department of Defense, 1985), with a belief it will indeed solve the problem. The basic idea behind implementing the access control is to limit the use of resources to the user by granting or denying them the access.

Administrative RBAC (ARBAC), which deals with the administration aspect of RBAC, is well defined and formalized (Alberti, et al., 2011) (Armando & Ranise, 2011) (Armando & Ranise, 2010). ARBAC take cares of the entire administrative task in the RBAC, whereas, there has been very less work done for user to user delegation in RBAC and this is not addressed by ARBAC as well. In recent years, there has been some work done in the field of RBAC and its component such as implementation, revising the definition, etc.

The major ingredients of RBAC are its Role, User, Permission and Role hierarchy. A user is assigned a role and each role is associated with certain permissions. In RBAC, there exist two relations one associating users to roles and the other associating roles to permissions. By joining these two relations,

3

the relation associating user to permissions can be derived. One of the most important extensions for flexibility to RBAC consists of adding a delegation and revocation mechanism of its roles. The delegation may come into different forms such as machine to machine delegation, human to machine, human to human and even machine to human delegation (Barka & Sandhu, 2000) (Barka, 2002). This thesis considers only the human to human delegation in computer systems. In (Barka, 2002), E. Barka has proposed a delegation model for human to human delegation based on RBAC and the basic framework of this thesis is also based on his work. It is always desirable to have a mathematical model for monitoring / enforcing the delegation and revocation of roles in RBAC which are necessary to maintain some desired securing property so as to make a system secure. There is a formal mathematical modelling for RBAC, which unfortunately does not accounts for delegation in RBAC between the users and the lacking in the formal mathematical modelling of RBAC is that it does not cover all the possibilities such as delegation and revocation of the role. In other words we can say that there is no comprehensive formal modelling of delegation and revocation in RBAC.

1.3 Research Questions

On the basis of the above mentioned problems, the following research question will be addressed by this thesis:-

1. How different mathematical modelling for delegation and revocation of Roles in RBAC can be performed?

1.4 Purpose

The main purpose of this thesis is to find appropriate ways of monitoring and enforcement of delegation and revocation of roles in RBAC policies. At first, we will conduct literature studies and try to find the suitable method and framework for RBAC. Once it is done then, we will perform the mathematical modelling of delegation and revocation of roles in RBAC. This thesis involves a detailed design of mathematical modelling of RBAC particularly focusing on Enforcement and monitoring of delegation and revocation of roles in RBAC policy. The final product of this thesis will be different equations for different models of delegation and revocation. Hence, main objective of this thesis is to define a proper formal mathematical model for human to human delegation in RBAC. In this thesis, the meaning of delegation is referred as user to user delegation, unless specify otherwise.

1.5 Goal

The goal of the thesis is to develop formal mathematical Modelling for different types of delegation and revocation of the roles in RBAC policies particularly focusing on human to human delegation which has been described in (Barka, 2002). E. Barka in (Barka, 2002) has provided framework for two role based delegation models to illustrate some practical access control policies but this framework does not account mathematical modelling. Similarly he also has defined can-delegate function in his framework which describes what type of role a user can delegate. But unfortunately, he has not provided any condition

4

for receiving a delegation by the user. So we have introduced a special function namely precondition, which a user must satisfy in order to receive the delegation.

The final product of this thesis should be mathematical equations that model different types of delegation and revocation of roles in RBAC.

1.5.1 Benefits, Ethics and Sustainability

The result of this thesis will benefits IT managers, network administrators, security managers, IT students, and anyone who is interested in models for access control policies. Special target groups are those who are willing to get in-depth knowledge of access control policies in RBAC and want to integrate the concept of delegation and revocation of roles of RBAC in their software. The researchers should consider ethical issues while conducting research of any magnitude which involves respecting the rights and dignity of participants of the research project, avoiding any harm to the participants arising from their involvement in the research, and operating with honesty and integrity. Two ethical issues any researchers must consider are consent and confidentiality of the participant. This research is based on using the documents only that is research papers and thesis, without humans or animals being involved and harmed hence from that perspective the ethical issues are of no concern. However, using documents might arise the plagiarism problem and violation in intellectual property right. So, to overcome these problem we have used proper referencing while refereeing to the Authors original work.

1.6 Methodology / Methods

Referring to the thesis description provided by ST (Security and Trust) unit of FBK (Fondazione Bruno Kessler), this research can be roughly categorized as follows:

1. At first author tries to investigate the problem area in depth and describe different concerns within the framework of RBAC,RBAC96, Delegation and Revocation of roles in RBAC

2. Similarly, second section focuses on analysis of different approaches to tackle the problems facing in the area. The discussion has been done based on the authors’ knowledge and materials reviewed.

3. Eventually, third section purely provides an evolution of mathematical models on given framework of RBAC and discussions which are fundamentally given according to previous sections.

Literature Review, Formal method are methods which are used to conduct the whole thesis. A mix of inductive and deductive approaches was taken to facilitate this research. First, the goal was to qualitatively analyse the current state-of-the-art solutions to identify what they lacked. Based on this inductive analysis several missing characteristics were determined. An implementation of some models was carried out afterwards in order to validate and verify the

5

ideas put forward in the mathematical model along with a discussion of possible alternatives of implementation.

1.7 Limitations

Delegation of the roles in RBAC can be done in different ways. It is possible to delegate roles from machine to machine, human to machine, human to human and even machine to human (Barka & Sandhu, 2000) (Barka, 2002). One of the major limitations of this thesis is that it only focuses on human to human delegation in the computer system and hence, the remaining delegation models are not mentioned. In human to human delegation, the entity who delegates the role(s) and the entity who receive the role(s) by delegation are both humans (the delegator and the delegate are both humans).

1.8 Structure of Thesis

The rest of this thesis is organized as follows. In chapter 2 we discuss the background and the related concepts, such as access control, RBAC, delegation, and revocation, etc. A short synopsis about the method that is used to conduct this research is presented in Chapter 3. In chapter 4 mathematical modelling of RBAC policies is presented. It includes mathematical modelling of delegation and revocation of roles in RBAC in detail. Finally, chapter 5 deals with the conclusion, and future work that can be carried out in this field.

6

2 Extended Background and Related Concepts

2.1 Security Policy

A security policy is considered as a “living document” of an organization which states how an organization protects its IT (Information Technology) infrastructure against unauthorized access. It is considered as a “living document”, in the sense that security policy is always added with new features as per organizational requirements and it is an ongoing process. A security policy also defines, what should and what should not be allowed to the user and how much power should be given to the user to perform certain tasks (Schneider, 2000). A security policy can be considered as the sets of rules that an organization follows, in order to protect its resources from being abused. Resources can be information, computer system, hardware’s, software’s etc. It may also include an “acceptable use policy”, which defines the plan about how the system user can be trained for protecting the system resources. The main aim of enforcing the security policy is to safeguard the resources of an organization.

The security policy of an organization can either be in mathematical or non-mathematical form. While creating a security policy, the system administrator or the security manager has to consider all aspects of confidentiality, integrity and availability of the resources. Confidentiality policy deals with the protection of confidentiality whereas, integrity policy focus on the integrity of resources (Bishop, 2003). Security policies for different organizations might not be similar. This is because, a security policy considered for making ICT system secure for one organization might not cover all the possible aspects for the other. For example, a security policy of a hospital might be different than that of the bank. While making the security policy of an organization, the policy maker should not make the security policy very complex to understand, too restrictive and unrealistic. It is considered as good and successful, if it is consistent, enforceable and flexible. Generally, while writing it, following sections such as the use of firewalls and their configuration, user account policy, virus detection and prevention mechanism, access controls, physical security of the system, disaster recovery policy, storage of logs, non-discloser policy, encryption and decryption policy, email policy, internet policy, etc are taken into consideration. On the basis of security policy, an access control policy for an organization is created and is enforced.

2.2 Access Control

Access control is one of the most important ingredients of the security policy, which grants or denies users access to resources. Access control helps to protect the assets of an enterprise to some extent. It allows the administrator to specify the users’ rights on the resources, such as which user can access what resources and the sets of operations that they can perform on them. The administrator can define an individual security policy for each user in such a way that the users can perform the assigned task with no difficulties. At the same time they are not allowed to access the resources which are not assigned to them. In other words,

7

with access control that is properly implemented, it is ensured that the right person is reaching the right resources at the right time.

Managing the access control of the system is one of the most difficult tasks for the system administrator in an organization. The system administrator has to be very careful while determining the level of access for each user. While defining the access level, the system administrator should not grant less or more rights to users. If the system administrator assigns reduced rights to the user then he/she might not finish his/her work on time, whereas assigning more rights to the user might put the system at risk. The user with more rights than necessary might abuse the system by accessing the information that he/she is not supposed to access. So the system administrator should always give an exact level of access or grant the necessary rights. Only the required permissions to the user for him/her to finish the assigned work are to be allocated (principle of least privileged). Principle of least privileged defines what should and what shouldn’t be allowed to the user and how much power should be given to the user so as to perform a certain task (Schneider, 2000). Principle of least privileged is also known as least privileged or principle of minimal privilege.

A simple example of access control is the lock on the door of the house and its key; only the person having the proper key for that lock can open the door lock and enter the house and use its resources. As another example, consider the situation in which Mr. Mike has been allocated 10MB of disk space on a server. This means he can use only up to 10 MB of disk space, no more than that.

An access control model can be defined as a set of criteria, by which the security manager or the system administrator of an organization can assign the appropriate permission to its resources on the basis of security policy. There are different types of access control models such as Mandatory Access Control (MAC), Discretionary Access Control (DAC), and RBAC etc. A short description of MAC and DAC is provided below.

If the access control policy is enforced by the system and the user cannot alter that policy then such kind of access control is referred as MAC. MAC is also referred as Rule-Based Access control. Generally in MAC, the operating system enforces the security policy over an object but, the user associated to that object cannot determine that the access has been granted to an object (Bishop, 2003) (Zhang, 2005). Usually MAC is used in Military system, where one way information flow is enforced (Bishop, 2003) (Zhang, 2005) (Department of Defense, 1985). On the other hand DAC, also known as Identity-Based Access Control (IBAC), is an access control model where an individual user can set an access control policy for granting and denying the access to an object based on user's identity (Bishop, 2003). Everything in the DAC is taken care of by the individual user, who is responsible for the object and is also considered as the owner of the object.

8

2.3 Role Based Access Control

2.3.1 Concept

RBAC is a relatively new concept with respect to other access control model such as MAC or DAC. RBAC is considered to be more scalable and reliable, which provides advanced and better flexibility than that of MAC and DAC (Sandhu, et al., 1996). RBAC is an access control policy where the access control policy is enforced by the system rather than by the owner or the administrator of the resources (Kuhn, et al., 2010) (Ferraiolo, et al., 1995). It is a collection of permissions, where access of an object is controlled by roles (Ferraiolo, et al., 1995) (Finin, et al., n.d.). In RBAC, a role can be defined as a function with some associated semantics related to the responsibility and authority of the users. A role also defines which user can perform what acts and actions on the information i.e. a role can also be seen as a set of permissions (Ferraiolo & Kuhn, 1992). A user is assigned with at least one role (but they can be granted more than one role) and each role is associated with certain permissions. In RBAC, there exist two relations, one associating users to roles and the other associating roles to permissions. By joining these two relations, the relation associating user to permissions can be derived.

2.3.2 Example of RBAC Implementation

Let us consider a RBAC implementation in a real life scenario, namely a university where each person entering the university can access the network with pre-defined roles (Such as Head of Department, Researcher, Student-assistant, Administrator, Student, etc.). In this case, someone having the role of the Administrator can only access the network and other resources allocated to administrators. However he/she cannot access the resources allocated to researchers unless he/she has been associated to the role Researcher. If the head of the department is also a researcher then, he/she can access both resources, those allocated to researchers and the head of the department, but not others. This means that any user associated with a particular role has the right to use a particular resource that has been pre-defined for that role.

2.3.3 Flat RBAC

The simplest RBAC model is flat RBAC also known as RBAC0 where there is no hierarchy among the roles which can be defined as: let R be the set1 of roles, P the set of permissions, and U the set of users. Then, user-role assignment relation is a Cartesian product of U and R and permission-role assignment is a Cartesian product of R and P. Both of them define many-to-many relations between the elements of the sets. Hence formally flat RBAC is defined as, UA ⊆

1 The definition of the mathematical terms used in this thesis are given in Appendix 1 and the meaning of the different symbols are given in Appendix 2

9

U × R and PA ⊆ R × P. Figure 1 shows the relation of user, role and permission in flat RBAC.

2.3.4 Role Hierarchy

The hierarchy in an organization describes its organizational structure. It also gives a clear picture about the authority and responsibility of an individual towards the organization. The hierarchy can be represented in a tree-like diagram where the nodes closer to the root(node at the top of the tree) are considered to be senior roles and the node that are at the bottom of the tree are considered to be junior roles. The role hierarchy is the systematic arrangement of the roles in an organization, where the senior role inherits the property of the junior roles. The Most senior roles are the most powerful roles, hence they are shown at the top of role hierarchy diagram whereas junior roles are the least powerful roles and they are shown at the bottom of role a hierarchy diagram (Sandhu, et al., 1996) (Joshi & Bertino, n.d.) (Barka & Sandhu, 2004).

Figure 2 illustrates the role hierarchy of an organization pictorially. If we consider the figure 2, we can state that role R1 is the most senior role whereas the role R6, role R7 and role R8 are the most junior roles. Most senior role(s) has more responsibility towards the organization than that of the junior role(s).

User Assignment

Permission Assignment

Figure 1 :- Flat RBAC (Sandhu, et al., n.d.) (Barka & Sandhu, 2000).

Permission

“P”

User

“U”

Role

“R”

UA PA

Role Hierarchy

Most junior Roles R6, R7 and R8

Most Senior Role

R1

R2 R3

R4 R5

R7 R8 R6

Figure 2 :- Role hierarchy and delegation of roles (Sandhu, et al., 1996) (Joshi & Bertino, n.d.) (Barka & Sandhu, 2004)

10

Permission inheritance in the role hierarchy is reflexive and transitive. It is reflexive since a role inherits its own permission and it is transitive because it allows the senior roles to inherit the permission of the junior role (Barka, 2002). We can consider the example in figure 2 for further clarification. Role R2 and role R3 can inherit the permission of R6. Since, R2 is directly connected to the R6 so there is no such problem in inheriting the permission but in case of R3 it is not directly connected to R6, but it still inherits the permission of R6 from R4, or R5. If we define hierarchies mathematically, then it is considered as a Partial Order. It is considered as partial order because of following relations, reflexive, transitive, and anti-symmetric (Barka, 2002) (Zhang, 2005). It is reflexive because of inheritance, a role inherits its own permissions, and it is anti-symmetry because it rules out that the redundancy of the roles that is inherited.

2.3.5 Hierarchical RABC

Hierarchical RABC also known as RBAC1 has as a key ingredient the hierarchy among the roles. The role hierarchy defines an inheritance relation as follows: the senior role(s) inherit the property of the junior role(s) (Jansen, n.d.). Figure 3 shows the relation between users, roles, permissions and role hierarchy in hierarchical RBAC. If we eliminate the RH from the figure 3 we will get the flat RBAC or RBAC0 which can be seen in figure 1 of this thesis.

Formally, Hierarchical RBAC is defined as, UA ⊆ U × R, PA ⊆ R × P and RH⊆ R × R. Where, RH can be defined as a partial order on R. The relation R is partial order in the sense that the relation is reflexive (each role is either on the same level in the hierarchy with another one, or above another one), asymmetric (the roles cannot exchange their levels) and transitive (if one role is above another and that one is above another one, than the first is also above the last one). Role Hierarchy and it is also be represented by ≥. If r1 and r2 are two different roles in the hierarchy (r1, r2 ∈ R), then r1 ≥ r2 means that r1 is more senior or higher in the hierarchy than r2. A user u is an explicit member of role r when (u,r) ∈ UA while u is an implicit member of r if there exists r′ ∈ R such that r′ ≥ r and (u,r′) ∈ UA. Given UA and PA, a user u has permission p if there exists a role r ∈ R such that (p, r) ∈ PA and u is a member of r, either explicit or implicit.

RH

Role Hierarchy

User Assignment

Permission Assignment

Figure 3 :- Hierarchical RABC (Sandhu, et al., n.d.)

Permission

“P”

User

“U” Role

“R”

UA PA

11

2.4 Delegation

2.4.1 Concept

Administration of RBAC will be problematic if a small number of security officers take care of all the associations between users with roles and roles with permissions (Li & Tripunitara, 2006). This scenario is indeed realistic in big organizations such as multinational banks, big research labs, and universities. When administrators have to take care of all administrative duties the probability of not finishing important task on time becomes higher. Hence, RABC offers opportunities for users to perform some of the administrative tasks.

Very often there are situations when a single user U1 in an organization carries out a huge responsibility and has too many tasks to do. As a consequence his role, R1, is assigned a lot of permissions. If user U1 continues to work in that fashion, he/she might postpone his/her task for the future, but he/she cannot skip the responsibility. In this case, U1 with a senior role can assign some of his tasks and responsibilities to the user U2 which has a junior role with respect to that of U1. Now, U2 gets full authority to act as role R1 and while performing R1, U2 is constantly supervised and monitored by U1. The assignment of the tasks by U1 (with a senior role) to U2 (with a junior role) is known as delegation.

For example, let us consider the role hierarchy presented on figure 2.We can assume that user U1 is associated with role R1, user U2 is associated with role R2 and role R3, User U4 is associated with role R4, User U5 with role R5, user U6 with role R6, user U7 with R7 and user U8 with R8 respectively. U2 who is associated to two roles, i.e. R2 and R3, is facing a lot of difficulties for doing his/her tasks. User U2 decides to delegate part of role R2 to U6 who is member of role R6, some part of R3 to U4, and some part to U5. In all these cases, U2 has the senior role than that of the receiver of the delegation. Upon receiving the delegation, the users associated to the junior role get the required permission allowing them to finish the delegated tasks. The user belonging to the senior role or the delegator (who delegates the role) holds the full responsibility and is still accountable if any of the users with the junior roles who received delegation (delegatee) misbehaves.

Delegation can be defined as temporary or permanent assignment of power, authority, and responsibility to the user having junior role in order to perform certain task on behalf of the user having senior role (Ferraiolo & Kuhn, 1992) (Barka & Sandhu, 2000). Delegation is done by the user having senior role so as to make the user having junior role equally responsible and powerful as the user having the senior role for certain tasks and it also allows for distributing tasks uniformly. The user having junior role may be constantly monitored by the user having senior role, by reviewing its activity. If user having senior role finds any deviation, corrective measures are taken so as to keep the user having junior role on track (Ferraiolo & Kuhn, 1992). Delegation to the right role ensures survivability and on the other hand, delegation to the wrong role may lead to failure (Tyson, n.d.). In RBAC, a role can be delegated only once or for certain number of times depending on the nature of the delegation that is used.

12

2.4.2 Temporary Delegation

Temporary Delegation also known as grant delegation in RBAC means to assign the responsibility of the user having senior role to the user of the junior role for a certain time or to perform a certain task that is time dependent. The user who *is associated to the role that is being delegated or the user who is associated with the senior role then the role that is being delegated can delegate the role for certain period of time to the user having junior role. In the temporary delegation, the user of the junior role is constantly monitored by the user of the senior role. The user performing the delegation will still be responsible for the role which he/she has delegated and he/she will still be the original member of the delegated role. At any point of time the delegated role can be taken back from the user receiving the delegation (Barka, 2002). While modelling temporary delegation in this thesis, we will refer it as grant delegation unless specified otherwise.

2.4.3 Permanent delegation

Permanent delegation also known as transfer delegation in RBAC refers to the delegation where the user having a role assigning his role to the user associated to another role for unlimited time duration. Once a permanent delegation is performed, the user who delegates the role will no longer be associated with that role and bares no responsibility on that role. Thus the user who receives the delegation becomes the original member of the role and will be accountable and holds full responsibility for that particular role. In this type of delegation, if once the user delegates his role, then he can no longer take it back (Barka, 2002). While modelling permanent delegation in this thesis, we will refer it as transfer delegation unless specified otherwise.

2.4.4 Delegation at the Same Level

Sometimes in delegation, the delegation of role does not follow the role hierarchy which means delegation occurs at the same level depending upon the nature of the work. This implies that the delegation occurs within the same level between the users of two non-comparable roles. The non-comparable roles are those roles which cannot be compared with each other with respect to the role hierarchy. For example, on Figure 2, the user associated to role R2 can delegate some of its authority to the user associated to role R3 and vice versa, this kind of delegation is called same level delegation. In this scenario role R2 and role R3 are considered as non-comparable roles with respect to the role hierarchy. Delegation is generally directed downwards, but in some cases the delegation can go upwards. Upwards delegation is not considered feasible in the RBAC policy because the senior role always inherits the permission of the junior role (Barka, 2002).

2.4.5 Risk with Delegation

Organizations might have employees that work for them temporarily (for example internship positions). They can have their own roles and be delegated some of the existing roles. For example roles R1, R2, and R3can be delegated to a new temporary employee. Delegating extra roles will increase his/her workload and responsibility. He/she has to work for his/her role as well as for

13

a new role that has been delegated to him/her. This might lead to processing delay and malfunctioning.

When delegating new roles to the users the system administrator always has to consider the current workload of the user. If delegation is done without considering these factors, then it will lead to security loophole, which might be of high risk for the IT infrastructure. It might lead to a big accident and as a result to huge financial losses. Hence, proper delegation is necessary.

If the system administrator delegates roles properly, then the probability of appearance of any problem related to security is reduced. However, the system administrator is a human so there is always a possibility for mistakes. In case the role which is delegated by mistake is a very confidential role there is a danger that the system might be misused. Delegating authority manually could always create security loopholes in the IT infrastructure.

2.4.6 The State of RBAC System with Delegation

Delegation changes the state of RBAC system through allowing the associated users to delegate their roles or the junior roles according to the role hierarchy. In this way the user assignment relation is associating user to the roles dynamic. Every time the user performs a delegation, the user assignment relation changes. Analysing delegation is much more complex and tricky than analysing RBAC, because, if the user does not delegate the roles properly, then an unauthorized user might get access to important resources and can execute some action(s) which is not supposed to execute (Ferraiolo, et al., 1995) (Ferraiolo & Kuhn, 1992) (Finin, et al., n.d.).

2.5 Revocation

2.5.1 Concept

The process of taking away the privileges and the power of user is known as revocation (Barka & Sandhu, 2000). Once the privilege has been revoked, then the user is no longer associated with the role (Barka & Sandhu, 2000) (Barka & Sandhu, 2004) and holds no responsibility towards that role. Revocation is the process of removing the delegation obtained by the user (Barka, 2002) (Barka & Sandhu, 2004). Revocation can be performed by the user who has delegated the roles or the senior user to that role who has delegated the roles or the security manager. The nature of the revocation depends upon the nature of the delegation. As said above, there are two flavours of delegation; they are i) permanent and ii) temporary delegation. In the case of the permanent delegation, only the security manager or the system administrator can perform revocation. In the case of temporary delegation, the revocation of the role can be performed by the users who has delegated the role, or by the users who is the owner of the role, or by the user who has the senior role than the role which is delegated.

If the user u delegates his role to the user u1 temporary means that the revocation can be done by the user u, or the user u` who is a member of the senior role than the user u or even by the security administrator. However, in some of the cases, the delegations may be chained; in such case the revocation

14

might be tricky and complex. In these cases a revocation might produce side-effects.

2.5.2 Revocation Techniques

There are different techniques for revocation, such as time based revocation, revocation by the user, and cascading revocation (Barka, 2002).

In time based revocation method (revocation by time): the delegated role is automatically revoked from the delegatee (the user to whom the role has been delegated) when the time of the delegation expires. This can be considered as an automatic process, and hence, the delegator has no longer to think about the revocation. Time based revocation is only possible if the delegation is temporary.

In some of the cases, the revocation needs to be done before the expiration of the time, so we need some other approaches which can revoke the permission from delegatee before the time expires. This can be done by the approach called “Revocation by the user". In this approach any user who has senior role to the delegating roles user or the users delegating the role or the user belonging to equivalent role, can revoke the roles from the delegated user. Revocation by user comes into effect when delegate user tries to misuse the delegation. In this case any original member of the role can revoke the delegation before delegated user misuse the system. It will reduce the likely damage that might occur due to misbehaving of the delegated users.

Sometimes, only these two revocations might not be enough to revoke the role from a user which has been delegated for a few steps forward. For example, considering hierarchy in Figure 2, we can assume that the user U1 is associated to the role R1, U2 to R2, U3 to R3, U4 to R4, U5 to R5, U6 to R6, and U7 to R7. From the definition of revocation, users associated to the senior role can revoke the delegation from the user associated with the junior role. Revocation can also be performed by the user who has delegated its role to another user. Let us assume that the user U1 has delegated the role R3 to the user U4 and after receiving the delegation from U1, the user U4 further delegates R3 to the user U7. After a few days, the user U1 realizes that the user U4 is not up to the task and the entire set of user delegated by him cannot be trusted. In this case the user U1 needs to revoke the entire delegation performed by him to user U4 and as well as the delegation performed by user U4. In this scenario, user U1 can perform revocation by revoking the membership of user U4 from the role R3. After performing this revocation, all the users that have received role R3 as delegation from user U4 are also revoked. On other hand if the user U4 loses the membership in his original role (in this case R4) then he will also lose the membership in the delegated role (Barka, 2002) (Barka & Sandhu, 2000) (Barka & Sandhu, 2004) . This kind of revocation is known as cascading revocation.

2.6 RBAC96 Model

The RBAC96 model developed by R. Sandhu (Sandhu, 1996) is the framework model for our thesis. In RBAC96 family, there are four different sub-models, which are RBAC0, RBAC1, RBAC2, and RBAC3. RBAC0 (also called the flat

15

model) is a generic model for RBAC and it features four entities the countable set U as users, the countable set of R as roles, the countable set P as permission and the countable set S as session. RBAC1 (also called as Hierarchical RBAC) is the extension of RBAC0 which is achieved by adding a Role Hierarchies (RH) as its fifth component and allows permission inheritance among the roles (Sandhu, et al., 1996). RBAC2 and RBAC3 do not have any significance in our work and hence are not described in this thesis.

The RBAC96 model of RBAC has the following components:-

1. The set of Users, roles, permission and session are countable and are

defined by U, R, P, and S respectively.

2. PA⊆ P × R, is a many to many relation assigning permissions to roles

3. UA⊆ R × U, is a many to many User assignment relation which assigns

roles to users.

4. RH⊆ R × R, is a partial order on R called Role Hierarchy and it is also be

represented by ≥.

There is also a session in RBAC96 model, in addition to role, permission and user. A session in RBAC96 is under control of an individual users and it is used for mapping a user to different roles at a given time. A session in the RBAC is established by the user U by activating some subset of the roles for which he/she is authorized and in which he/she is a member of. Each session is associated with a single user and each user is associated with one or more sessions. A user may have multiple sessions opened at the same time, and each session may have a different combination of active roles (Sandhu, et al., 1996) (Sandhu, 1996). In this thesis we have considered that a user can only open one session at a given time. For us, the session does not play a vital role, since we are interested in dynamics of UA relation and UD (user delegated) relation rather than opening a session. Hence, we have decided to eliminate session for the RBAC96 model and, it is not discussed anymore in this thesis.

2.7 Previous studies on RBAC

A relatively new concept with respect to other access control model such as MAC or DAC was defined in early nineties and coined as RBAC by Ferraiolo and Kuhn (Ferraiolo & Kuhn, 1992). This access control is considered to be more scalable and reliable, which provides advanced and better flexibility than that of MAC and DAC (Sandhu, et al., 1996). RBAC is the access control policy where the user can access the resources on the basis of its role rather than its identity and this access control policy is enforced by the system rather than by the owner or the administrator of the resources (Kuhn, et al., 2010) (Ferraiolo, et al., 1995). In 1996 R. Sandhu developed RBAC96 model which consists of four different sub-models, RBAC0, RBAC1, RBAC2, and RBAC3. (Sandhu, 1996).

On the basis of RBAC96 model which was developed by R. Sandhu, E. Barka in (Barka, 2002) has provided framework for two (RBAC0 and RBAC1) role based delegation and revocation models to illustrate some practical access control policies but It does not cover mathematical modelling of RBAC. Similarly he

16

also has defined can-delegate function in his framework which describes what type of role a user can delegate. But unfortunately, he has not mentioned any condition which a user must satisfy in order to receive the delegation.

Administrative RBAC (ARBAC), which deals with the administration aspect of RBAC, is well defined and formalized (Alberti, et al., 2011) (Armando & Ranise, 2011) (Armando & Ranise, 2010). ARBAC take cares of the entire administrative task in the RBAC, whereas, there has been very less work done for user to user delegation in RBAC and this is not addressed by ARBAC as well. In recent years, there has been some work done in the field of RBAC and its component such as implementation, revising the definition, etc. (Barka, 2002).

In (Barka, 2002) E. Barka has developed a basic framework for Role based delegation and revocation models based on RBAC96 which was developed by R. Sandhu (Sandhu, 1996). This thesis is based on the framework developed by E. Barka on RBAC96 and the mathematical modelling has been performed on RBAC96's two main components RBAC0 and RBAC1 in this thesis.

17

3 Method

This chapter presents the research methods that has been used to carry out this study within material collection, analysis, experimentation and evaluation.

3.1 Method used for the research

A set of approaches to solve problems into the area of information security, usually referred to as formal, include models written in the formal notation. Their use can improve the precision with which the security issues are addressed. Any technique or method that is based partially or in total on rigorous mathematics is considered being a formal method. Formal methods imply the use of formal notation and language for specifying mathematical modelling. A formal method is a method in which formal notation can be formally justified (Butler, 2001) (Formal Methods Group, CS Department, University of Toronto, 2004). Formal methods are system design techniques that use specified mathematical models to build systems. This methods are techniques used to model complex systems as mathematical entities (Butler, 2001).

One of the central security paradigms is the one that deals with granting users rights to use in different ways the assets of the information system being protected. The main objectives in this thesis are related to access control policy, RABC in particular. The research extends already existing mathematical models for ARBAC to the process of delegation and revocation of roles in RBAC. Hence, the formal method is applied for performing mathematical Modelling for delegation and revocation of roles in RBAC.

3.2 Methodology

Preliminarily, we will conduct literature study of different access control policy to get adequate knowledge about access control. Subsequently, we will perform detail study about the RBAC and its family to find appropriate frame work for our research. After acquiring adequate knowledge on RBAC, we will start getting in-depth knowledge about set theory, since our entire mathematical modelling is based on it. Next step will be getting used to the set theory and applying it to the framework of RBAC which is selected to extract formal mathematical modelling of delegation or roles in RBAC. In-Depth Study of RBAC will be performed while performing mathematical modelling. The final product of this thesis will be different equations for different models of delegation and revocation of roles in RBAC.

The following sub-sections present the two parts of the process in carrying out this research, the literature review and the implementation of the formal method.

3.2.1 Literature Review

Literature Review is the starting and essential point for any research. It provides the in-depth knowledge of the related work that has been conducted till date. Based on literature review, we can get comprehensive knowledge about

18

the subject matter and we can identify the related problem. On the basis of related problem, we can identify the major research question for the research. While conducting the literature review, we tried to get adequate knowledge about role base access control policies and the framework for delegation and revocation model. The main literature used for conducting this research was provided by my supervisor at FBK. Other related literature was collected through digital libraries of FBK and UNITTN (University of Trento). While conducting literature review we followed desktop research approach. Desktop research also referred as documentary research or library researcher, is secondary research based on exploring other people's research which is based on published or unpublished papers. Source useful information from the libraries and the Internet was collected for reviewing of the state of the art of delegation and revocation in Role base access control policies and Trust Management which is considered as the starting point for this research.

3.2.2 Implementation of Formal Method

Implementation of the formal method for mathematical modelling of delegation and revocation of roles with respect to RBAC was implemented following the previous work performed by the Security and Trust unit at FBK. Mathematical equations are developed to show the policy behind different modes of delegation and revocation of roles. This is illustrated with examples to help the reader understand the notions presented. Two annexes are attached to the thesis to provide users without solid mathematical background with the meaning of the mathematical notation and definition of basic mathematical terminology used throughout the thesis. Main objective of this thesis is to develop a clear cut and easy to understand mathematical models for delegation and revocation of role in RBAC framework developed by E. Barka (Barka, 2002). In order to develop mathematical models formal method is only the option available, so choice become obvious (Formal Methods Group, CS Department, University of Toronto, 2004). According to M. Collins in (Collins, 1998) formal design can be classified as a three step process which are formal specification, verifications and implementation. Formal specification refers to derivation of mathematical models from well-defined theory. Modelling languages have fixed syntax which allow users to model complex structures to predefined types. This process of formal specification is similar to the process of converting a theoretical problem into algebraic notation or set notation (Collins, 1998) (Butler, 2001). Verification is a difficult process, because even the simplest system has several theorems, each of which has to be proven. Almost all formal systems use tools namely automated theorem proving tool. These tools can prove simple theorems, verify the semantics of theorems, and provide assistance for verifying more complicated proofs. Once the model has been specified and verified, it is implemented by converting the specification into code (Collins, 1998). Since we did not had an automated theorem proving tools for verifying the mathematical models, so we decided to directly implement it in standard SQL (Structured Query Language) language. It was assumed that if we could implement our models in SQL, this means that our model is verified.

19

3.3 Alternative Methods

This section describes the possible alternative methods that could have been used in this thesis. Alternatively, quantitative research method or mixed approach or qualitative research method could have been used. The quantitative research is associated with the positivist/ post positivist paradigm. In addition, quantitative methods are most suitable for large population, and focuses specific case (Creswell, 2003) (Booth, et al., 2003) (Denscombe, 2007). Qualitative research is associated with the socially constructed nature of reality. It deals with the human behaviour and experience. It includes collecting and converting data into numerical form so that statistical calculations can be made and conclusions can be drawn. This method uses sophisticated tools and statistical methods like, regression, t-test, chi-square and numerically answers the research question (Leech & Onwuegbuzie, 2006. ) (Booth, et al., 2003) (Creswell, 2003). Pragmatic approach to research (mixed methods) involves using the method which appears best suited to the research problem. This method gives the freedom to use any methods, techniques and procedures typically associated with quantitative or qualitative research. (Booth, et al., 2003) (Creswell, 2003) (Denscombe, 2007) (Leech & Onwuegbuzie, 2006. ).

20

4 Mathematical Modelling of RBAC with Delegation and Revocation

4.1 Introduction

4.1.1 Definition of RBAC Policy

RBAC is the access control policy where the user can access the resources on the basis of its role rather than its identity. Let us consider U as the set of users, R as the set of roles, P as the set of permissions, UA as the set of user assignments, PA as the set of permission assignments, and ≥ as the role hierarchy. We can define UA (User Assignment) relation as the subset of U × R (User × Role), PA (Permission Assignment) relation as the subset of R × P (Role × Permission) and ≥ (Role hierarchy) as the subset of R × R (Role × Role) which is also a partial order. In RBAC, by joining the relations UA and PA, it is possible to derive the relation associating user(s) to permission(s). Formally from (Alberti, et al., 2011) (Sandhu, et al., 1996) (Sandhu, 1996) (Armando & Ranise, 2011), roles in a set R associate permissions in a set P to users in a set U by using the following two relations: UA ⊆ U × R and PA ⊆ R × P. Roles are structured hierarchically so as to permit permission inheritance. A role hierarchy is a partial order ≥ on R, where r1 ≥ r means that r1 is more senior than r2 for r1, r2 ∈ R. A user u is an explicit member of role r in UA when (u,r) ∈ UA while u is an implicit member of r in UA if there exists r′ ∈ R such that r′ ≥ r and (u,r′) ∈ UA. Given UA and PA, a user u has permission p if there exists a role r ∈ R such that (p, r) ∈ PA and u is a member of r. Now, we can consider the tuple < U, R, P, PA, ≥, UA> as an RBAC policy, and this tuple will be extended when more complex delegation models will be considered. Figure 4 shows the different components of the RBAC policy.

4.1.2 Properties of RBAC Policy

The number of relations defining the RBAC system for big organizations can be very large. When day-to-day tasks change within the organization, modification of too many relations might be required at the same time. This can make the management and administrating of RBAC to be cumbersome and problematic. In order to make the administration / handling of RBAC policy simple, it is desirable to allow for the user assignment relationship to be dynamic and leave the rest of the relations static. This can be done because the set of users, the set of roles, set of permissions, the permission assignment relation, and the role hierarchy of an organization does not change frequently.

Figure 4 :- Different Components of the RBAC Policy

U, R, P UA ⊆ U × R

PA ⊆ R × P

≥ ⊆ R × R

21

If there is a huge change in the organizational structure then only these relations are likely to be changed, so it is recommended to keep them static once the security manager or the system administrator has defined them. The only relation that changes during daily operation is user assignment relation. If a new 3user comes to the organization then, he/she can be assigned a role in UA. Once the new user is associated to the role, then he/she will get the permissions associated to that role which is defined in the permission assignment relation PA.

It is very unlikely for new roles to be created in an organization frequently or the role hierarchy of an organization to change very often. New roles in an organization are created, if there is a change in role hierarchy or if there is a change in the organizational structure or if there is a massive reorganization within the organization. Thus, it is reasonable to assume that the only relation, that is likely to change frequently, is UA whereas the other relations are static and they do not change frequently.

While describing the evolution of RBAC systems, one can consider the UA relation as the RBAC policy since all the other relations are static. As a consequence, questions such as if the user u has the permission p can be rephrased in terms of roles only, i.e. “Does the user u can have role r?” From now on, we consider the problem of establishing whether a user u can become a member of role r rather than if u can get permission p.

There are two types of user actions that can be performed by the user which change the state of the RBAC system: assigning a role to a user (delegation) and revoking the role from a user (revocation). If the user can perform these actions without any constraint, it would be difficult to foresee all the implications of the concurrent execution of several delegations by many users. For this reason, rules are specified in order to constrain delegation and revocation to make it possible to understand the implications of a sequence of delegations and revocations.

4.2 Example Scenario /Case

Throughout this thesis, we will use the following scenario to illustrate our ideas. The presented scenario is totally imaginary and we believe that this scenario is not only simple to understand but also will cover all the possible cases of delegation and revocation of roles in RBAC.

In an organization there are lots of people working in different departments. Each department has its own functionalities. Each person working in the department is associated with certain role(s). If we consider the organizational structure of Research lab as an example, we can see that there are lots of departments for specific tasks, and each department of the research lab has its own role hierarchy. There might be different roles in the Research lab, such as board of director, chief executive officer, managing director, director, head of departments (HOD) etc. There is also the possibility of having various departments such as administration, IT, finance etc. It will be difficult to describe all organization structure and its role hierarchy. Therefore, we decided to pick one department called Digital forensics, in order to simplify our task of

22

explaining the relationship between the roles in the role hierarchy. We will try to use the example of this department in the entire text that follows to explain different mathematical models. Figure 5.1 shows the role hierarchy and Figure 5.2 shows the user and its role membership in the role hierarchy of the digital forensics department. DIT (Director of IT) is the role which is considered as the highest senior role in the IT department and its associated user is Haru. Haru is accountable for entire IT department of the research lab and he is liable to control all the other departments. However, in our case we are only focusing on Digital forensics department. In this department, we have different roles, such as HOD, Prof. (P), Researcher (R), Assistant (A) and Student Assistant (SA). In the digital forensic department, Lee is associated with the role of HOD, Alex with the role Prof., Eric with the role Researcher, Man with the role Assistant and Ben with the role Student Assistant. If we only consider the role hierarchy of the digital forensic department, then we can conclude that HOD is the highest senior role and the student assistant is the lowest junior role. The role HOD inherits the role and permission of its junior role(s).

Any user, who has a role, can delegate its role or a junior role to another user within or outside of role hierarchy, temporarily or permanently. For example Lee can delegate HOD to Alex, Man, Eric etc., or Lee can delegate his HOD to another member Jen from different role hierarchy very easily. Revocation of the temporary assigned role can be done by the user who has delegated it or by the user that has senior role than that of delegated role, and on the other hand, revocation of permanent delegation is done by the security manager. The nature of revocation totally depends upon the nature of the delegation.

Figure 5 :- Role Hierarchy and Its user of a Digital forensic department

Director IT (DIT)

Haru

HOD

Lee

Assistant (A)

Man

Student Assistant (SA)

Ben

Prof. (P)

Alex

Researcher (R)

Eric

Figure 5.2:- Role Hierarchy of user with role membership Figure 5.1:- Role Hierarchy

HOD

Student Assistant

Assistant

Researcher Prof.

Director IT

23

4.3 Definition of delegation

Administrative delegation in RBAC enables administrators to delegate the role and associated permissions to another user on behalf of the owner of the role. In user to user delegation, the user associated to the particular role can delegate its role or some junior roles to another user. Sometimes the delegation of the role does not follow the role hierarchy in the RBAC1 which means that, the delegation occurs within the same level between the users of two non-comparable roles. The non-comparable roles are those roles which cannot be compared with each other with respect to the role hierarchy.

In ARBAC (Alberti, et al., 2011) (Armando & Ranise, 2010), there is an administrator, who takes care of delegation and revocation of roles on behalf of the users. Instead for user to user delegation, the delegating user of the role acts as an administrator for that particular delegation. In this way additional human intervention such as the effort of administrators to delegate or to revoke the role on behalf of a user is not required. However, for some form of revocation, (see section modelling of Revocation of Permanent Delegation) some administrative effort is needed.

A user must follow certain rules to delegate or to receive delegation. The basic rule is that a user can delegate its role or some junior roles if the user to whom he is willing to delegate satisfies certain conditions. The effect of performing a delegation is an update of the UA relationship whereby the new association between the delegated role and the user to which the delegation has been given is added to UA. Formally, we can see UA as UA= UA0 ∪ UD (Formally, UD relation can also be defined as UD ⊆ U × R.) where UA0 is static (where user role assignments are given by the system) and UD is dynamic (where user role assignments are established via delegations among users).

Formally, the rules to perform a delegation are specified as tuples of the relation can_delegate such that can_delegate ⊆ R × pre, where pre is the set of preconditions (to be defined below). Can_delegate is used to constrain the freedom of users to delegate roles in order to avoid security problems. Pre is the set of preconditions, which is used to identify candidate users to receive the delegation. This can be made precise in the following way: - Pre (Precondition) can be defined as a set of signed roles, i.e. ±r where r ∈ R. The meaning of signed roles is that the role can be represented either by +r or -r and is used for checking the precondion. If the signed role is +r means that the user u is a member of role r in UA and if it is -r means, that user u is a not a member of role r in UA. The precondition acts as the condition that has to be satisfied by the user in order to receive the delegation. Preconditions can be very complex. Example of complex preconditions can be considered as if the user u2 is a member of the role r1, r2, r3, and if the user u2 is not a member of the role r4, r5, r6 etc., and then only the user u2 can delegate the role to another user say u3. This kind of complex preconditions can be constructed by a conjunction of signed roles such as being an explicit or implicit member of certain roles and not being an implicit or explicit member of certain roles. The precondition

24

described in this thesis can be very sophisticated, but for reason of simplicity in our examples, we use a single signed role.

The intuition underlying (r, pre) ∈ can_delegate is that a user u` should be a member of role r to be able to delegate it or some junior roles of r to a user u satisfying the precondition pre.

Formally, it is possible to define once and for all; the notion of a user u satisfies a precondition

pre= {[exp1, exp2,…, expn]} with respect to UA0 as follows

for each expression exp

of the form +r, we have User u is a member of role r in UA0

of the form –r, we have User u is not a member of role r in UA0

It is clear that “being a member of” encapsulates both the case where a role hierarchy is used and where it is not. In this way, the preconditions for RBAC0 do not consider the role hierarchy whereas those for RBAC1 do so.

The formalization of the effect of the execution of the delegation on the state of the RBAC system (that can be thought of the dynamic relation UD) depends on the type of delegation and revocation that one considers and will be the main subject of the rest of the thesis.

In particular, we will provide mathematical framework (based on simple set theory) to specify the various types of delegation and revocation of roles in RBAC considered in E. Barka’s PhD Thesis (Barka, 2002).

Meaning of the above precondition is that the user u` who is delegating the role r` should be either implicit or explicit member of r` such that the users receiving the delegation will either have non-comparable roles to r` or have junior role than r` with respect to the role hierarchy. In (Barka, 2002), it is required that a role r that is being delegated to a user u should be non-comparable or senior (with respect to the role hierarchy) to the role of u. Thus, in the rest of this thesis, we assume that this check is preformed every time a delegation is going to be performed and if the condition is violated, then the delegation is considered not to be enabled. Formally, this is expressed as follows:

Given (r, pre) ∈ can_delegate, a user u satisfies pre is defined as before with the additional condition: if (u , ru) ∈ UA then ( neither ru ≥ r nor r ≥ ru) this mean ru and r are not comparable with respect to role hierarchy or (ru ≥ r and ru ≠ r) this means that ru is more senior that r with respect to the role hierarchy

25

4.4 Modelling of Grant/Temporary Delegation

In grant delegation (also known as temporary delegation), roles are delegated to other users according to some rules but the delegator maintains his membership in the delegated role. The delegator holds full responsibility for the role that has been delegated (Barka & Sandhu, 2004). The delegation can either be total or partial. The term total and partial in delegation defines how many permissions associated to the role have been delegated. To be precise, total delegation means that all the permissions that are associated to the role have been delegated, whereas partial delegation means that only the subset of the permissions which is associated to the role has been delegated. The receiver of the delegation is constantly monitored by the user who has delegated the role. The delegator of the role bears the full responsibility on behalf of the receiver; this means that the delegator will be responsible and accountable for the role that it has delegated even if the receiver does something wrong. Grant delegation in RBAC96 comes in two flavours: delegation within flat roles (RBAC0) and delegation within role hierarchy (RBAC1) (Barka, 2002) (Barka & Sandhu, 2000) (Barka & Sandhu, 2004). The following sections deal with the different models of grant delegation in RBAC0 and RBAC1.

4.4.1 Modelling of One Step Grant Delegation in Flat Role (RBAC0)

This subsection deals with one-step grant delegation in RBAC0, i.e. the roles that have been delegated once cannot be delegated further. In other words the delegatee cannot further delegate the role that he has received by delegation from another user. Delegation in this model is total, which means that, while delegating, the delegator either delegates all the permissions that are associated with the role or does not delegate any of them. Delegation between the users of the same role is also not allowed (Barka, 2002), since it is obviously useless. The following example can be taken into consideration from the scenario which is described in previous chapter of this thesis. Let us assume that Lee is associated to HOD role in Digital forensic department and is a very busy person, and most of the time he is out for conferences and seminars. Now for two weeks, Lee is going for a conference which is to be held in Sydney, but he has few tasks pending and they are supposed to be due within three weeks. It is likely that Lee will not finish his tasks within the stipulated period of time. So, before going to Sydney, Lee decides to delegate his tasks to Maddy who is associated to a role researcher in the criminology department. In this model, there is no presence of role hierarchy, so any user having the role can delegate its role to any other user within an organization.

Formally the Modelling of grant delegation in flat RBAC (RBAC0) can be defined as follows

1. Define the UA relation as UA= UA0 ∪ UD1 where UA0 is static and UD1

is dynamic.

2. The tuples in can_delegate allows us to define a transition relation over

UD1 Modelling the effect of delegation on UA as follows:-

a. If (r, pre) ∈ can_delegate and u` is a member of r and u satisfies

pre (with respect to UA0)

26

b. Then UD1`=UD1 ∪ {(u, r)}

3. We say that user u` delegates the role r` to the user u (who satisfies

pre) and write UD1UD1` to denote the transition induced by the

delegating action.

4.4.2 Modelling of One Step Grant Delegation in Role Hierarchy (RBAC1)

In this subsection we will discuss about the one step delegation in the role hierarchy or the one step delegation in RBAC1. This delegation model is almost the same as the one step delegation for flat model (RBAC0). The main difference is that the delegation is performed in the presence of a role hierarchy. The basic idea behind this delegation is that the user associated to the role can delegate its role or some junior role to the user who is associated with the role which is junior to the role that is being delegated or to the user who satisfies a certain precondition. This delegation takes place within the role hierarchy and the delegation can be either downwards or across (Barka, 2002). The roles that have been delegated in one step delegation cannot be further delegated. The nature of the delegation can either be partial or full depending upon the fact that the role itself or some junior roles is delegated. Now, let us consider the following example to illustrate the one step delegation in role hierarchy. Alex, Prof. by the role, is going to be father for the first time; he is very excited and is thinking of taking few days off from the office so as to be with his wife for their first child. Alex has lots of work to finish, and he has also not finished his courses, and it will take seven more lectures to finish his course and it is very unlikely that he will finish the course after becoming father. So Alex decides to delegate part of prof. role (teaching) to Eric who has the role R (Researcher). The roles of Alex and Eric are non-comparable since they are at the same level in the role hierarchy. The type of delegation that occurred in this case is one step cross delegation. In one step delegation, Eric cannot further delegate the role that he has received from Alex.

Following is the mathematical Modelling of one step grant delegation in Role Hierarchy (RBAC1)

1. Define UA relation as UA= UA0 ∪ UD1 where UA0 is static and UD1 is

dynamic.

2. The tuples in can_delegate allows us to define a transition relation over

UD1 Modelling the effect of delegation on UA as follows:-

a. If (r, pre) ∈ can_delegate and u` is a member of r and u satisfies

pre (with respect to UA0)

b. Then UD1`=UD1 ∪ {(u, r`)} for some r` which is junior or equal

to r with respect to role hierarchy.

3. We say that user u` delegates the role r` to the user u (who satisfies the

pre) and we write UD1UD1` to denote the transition induced by the

delegating action.

4.4.3 Modelling of Two Step Grant Delegation in Role Hierarchy

This model is an extension of the one step delegation model in the role hierarchy, with more flexibility in that the role received from a delegation can

27

be further delegated to another user, but the user receiving the second delegation cannot delegate that role further. So, this means that a role can be delegated twice within the role hierarchy but it cannot be delegated more than twice. This type of delegation can be partial or full and the delegation should take place either between two non-comparable roles or downwards in the role hierarchy. For example, let us continue the example considered for one step delegation with role hierarchy. We assume that the first delegation is as explained above. After few days, Eric realizes that he is not able to work properly due to extra work load, so he decides to further delegate his role prof. (teaching) obtained from Alex to Man who has role A and which is one step below in the role hierarchy with respect to Alex and Eric’s roles. This kind of delegation is an example of the two step delegation. In the following Modelling we can see that the first part of this model is identical to the one step delegation with the only difference in the second part of the delegation. More precisely, in place of checking in if a user satisfies a precondition with respect to UA, the user delegating the role does so with respect to in UD1 (User Delegation 1) to delegate the role. After performing the delegation, the user delegating the role will make necessary update in UD2 (User Delegation 2) by adding the new user to role assign to UD2. Let us consider the above example once more. When Eric wants to perform the delegation of the role (teaching) to MAN which he has received from Alex, he checks the UD1 relationship at first. Upon performing the delegation, by Eric to Man, Eric will update the UD2 relation.

In the following you can find the mathematical Modelling of two step delegation within the Role Hierarchy.

1. We can define the UA relation as UA= UA0 ∪ UD1 ∪ UD2 where UA0

relation is the static part of UA and UD1 and UD2 relation are the

dynamic parts.

2. The tuples in can_delegate allow us to define a transition relation as

follows:-

a. If (r, pre) ∈ can_delegate and u` is a member of role r and u

satisfies pre (with respect to UA0)

b. Then UD1`=UD1 ∪ {(u, r`)} and UD2`= UD2 for some r` which is

junior or equal to r with respect to the role hierarchy.

c. If (r, pre) ∈ can_delegate and u` is a member of role in UD1 and

user u satisfies pre (with respect to UD1)

d. Then UD2`=UD2 ∪ {(u, r`)} and UD1`= UD1 for some r` which is

junior or equal to r with respect to the role hierarchy.

3. We write (UD1, UD2) (UD1`, UD2`) to denote the transition induced by

the two step delegation action.

4.4.4 Modelling of K Steps Delegation in the Role Hierarchy

This model is a further generalization of the previous delegation model, which enables users to delegate the role for K steps. In the above mentioned model, a user can delegate its associated role to another user either once or twice. In this model, we allow for K step delegation of a role where K is a natural number

28

greater than or equal to 1. Following, you can find the Modelling of Kth step delegation in the role hierarchy

1. Let K ∈ ℕ some fixed value

2. Let UA= ⋃𝐾𝑗=0 UD0 where UD0= UA0 is the static relation and UD1,

UD2,…,UDK, are the dynamic relation.

3. If (r, pre) ∈ can_delegate For some i ∈ {1, 2,…, K-1} we have User u` is a member of role r in UDi

User u satisfies pre with respect to UDi-1 Then UDj`=UDj for j=1, 2,…, k-1 and j≠ i UDi`=UDi ∪ {(u, r`)} for some r` which is junior or equal to r with respect to role hierarchy.

4. We write (UD0,…,UDi, …,UDk) ( UD0`,…,UDi`,…, UDk`) to denote the

transition induced by a k-step delegation

4.5 Modelling of Transfer/Permanent Delegation

If the delegator of a role loses his membership in the delegated role, then this kind of the delegation is considered as transfer delegation or permanent delegation. In the transfer delegation, both party involved in delegation, that is the delegator and the receiver of the delegation should agree on it. After performing the transfer delegation, the delegator has no right and holds no responsibility with respect to the role that has been delegated. It means that, after performing transfer delegation, the delegator will lose its membership and ownership in that particular role. After receiving the delegation, the receiver will get the membership and act as an original member of that role. Transfer delegation should be total, which means that, the delegator should delegate the whole set of permissions associated to a role. Transfer delegation in RBAC comes in two flavors, they are delegation within the flat roles (RBAC0) and delegation in role hierarchy (RBAC1) (Barka, 2002) (Barka & Sandhu, 2000) (Barka & Sandhu, 2004). Most importantly, delegation between users of the same role is not allowed and also considered as useless (Barka, 2002). The following subsection deals with Modelling transfer delegation of roles in RBAC0 and RBAC1.

4.5.1 Transfer Delegation in RBAC0 or RBAC1

The basic idea behind transfer delegation in RBAC0 or RBAC1 is that any user associated with the role can transfer its role to any user provided some preconditions are satisfied. This type of permanent delegation should be total in nature i.e. delegator either delegates all of the permission associated with a role to the new member or it does not delegate any of them (Barka, 2002). Let us consider the following example to illustrate the transfer delegation. Lee is associated with the role HOD in Digital forensic department and he is also associated with Advisor role in the Criminology department. For some reason Lee was not able to work properly as an Advisor in the criminology department. Lee thinks that, Sunil who has the advisor role in Digital forensic department is more suitable for the task then himself. So he decides to transfer the

29

responsibility of his advisor role to Sunil. Upon transferring the advisor role to Sunil, Lee will lose all of his permissions and rights on the advisory role and Sunil will become an original member of the advisor role. After transferring the role to Sunil, Lee will no more have any responsibility in the advisor role. Furthermore, in this model, a user can further transfer the received role to another user since the receiver of the transfer delegation becomes the original member of the role. A user delegating the role is responsible for updating the delegation in the UA relation. A user, who performs the transfer delegation will add the membership of new user and delete its membership from the role.

Following is the mathematical Modelling of Permanent delegation in RBAC0 or RBAC1

1. The UA relation is dynamic.

2. The tuples in can_delegate allow us to define a transition relation over

UA Modelling the effect of delegation as follows:-

a. If (r, pre) ∈ can_delegate and u` is an explicit member of r and

u satisfies pre (with respect to UA0)

b. Then UA`= UA ∪ { (u , r)}\ {(u` , r)}

3. We say that user u` has transferred the role r to the user u (who

satisfies pre) and we write UAUA` to denote the transition induced

by the delegating action.

When considering RBAC0, the above definition does not use any role hierarchy when checking if the user u satisfies the preconditions pre. This means that the user u is checked to be an explicit member of a role r when +r is in the precondition pre (or not to be an explicit member of r when -r is in pre). Instead, when considering RBAC1, the above definition does use the role hierarchy. So, the user u is checked to be (not to be) a member (either implicit or explicit) of role r when +r (-r, respectively) belong to pre.

4.6 Definition of Revocation

Revocation is the process of taking away the rights and privileges of a user to whom the role has been delegated. Revocation in RBAC can be performed by the user who has delegated the role or by the user who has a more senior role than the role that has been delegated. Once the role has been revoked from a user, then the user is no longer associated with that particular role and holds no responsibility on that role (Barka & Sandhu, 2000) (Barka & Sandhu, 2004). In this thesis we will present mathematical Modelling of different techniques for revocation of grant delegation, such as revocation by timeout, revocation by user or voluntary revocation and cascading revocation. We have assumed that the transfer delegation cannot be revoked by the user who delegate the role or by any user who has the senior role than the delegated role. Even though, we have tried to reduce additional human intervention by administrators or security managers while modelling delegation of RBAC. In the case of revocation of permanent delegation, we think it is more realistic that the revocation can only be performed by the system administrator or the security

30

manager of an organization. The following sections deals with different types of revocation.

4.6.1 Time Based Revocation

In this model we have attached a clock to take into consideration time so as to model expiration of delegation. This model is an extension of delegation model which adds duration to the component of a policy. In this model, each user role assigned is associated to a period of time for which the role can be delegated to the user. When the assigned time interval has elapsed, the delegation expires automatically (Barka, 2002), and the associated role is revoked from the user to which it has been delegated. This type of revocation can be considered as automatic revocation, since it is the system that monitors the flow of time and automatically performs the necessary revocation. Thus, the users delegating the role need not to worry about the revocation. In this model tuple grows by adding durations which are defined by a mapping U × R ⇀Time (where Time is either ℕ or ℝ depending on whether the flow of time is discrete or continuous). The duration function of this model is responsible for keeping track of the time durations that have been assigned to every delegation.

Now, lets us consider the following example to illustrate the time based revocation in role hierarchy. It is an extension of the example mentioned in one step delegation for role hierarchy. Alex, Prof. by the role, is going to be father for the first time; he is very excited and is thinking of taking few days off from the office so as to be with his wife for their first child. Alex has lots of work to finish, and he has also not finished his courses, and it will take seven more lectures to finish his course and it is very unlikely that he will finish the course after becoming the father. So Alex decides to delegate his part of prof. role (teaching) to Eric who has the role Researcher for one month starting from 00:00 Hrs of 1st of August 2011 to 23:59.59 Hrs of 31st of August 2011this is the period during which his seven lectures are scheduled. When the system time is 00:00 Hrs of 1st of August, the delegation starts, i.e. Eric gets the permission to access the part of Alex role and Eric works on behalf of Alex. When the system time is 23:59.59 Hrs of 31st of August 2011, can_revoke action automatically revokes the part of the role from Eric which he has received from Alex as delegation.

Following is the mathematical Modelling of Time based revocation.

1. Let duration be a total function from U × R to Time where Time can

either be ℕ or ℝ according to the fact that we assume a discrete or a

continuous flow of time.

2. The state of the system is a pair (t ,UD) where t ∈ Time is the current

time and UD ⊆ U × R × Time is the dynamic part of the User

assignment relation

3. If (r, pre) ∈ can_delegate, u is a member of role r and u satisfies pre Then (t, UD) (t, UD ∪ {(u, r, ti)})

4. If duration (u, r) =0 then the role r cannot be delegated to the user u

31

5. If duration (u, r) = + ∞ then the role r can be delegated to the user u

but it cannot be revoked by the time based revocation (but it can be

revoked by some user, see next section i.e. user based revocation)

6. If duration (u, r) = d ∈ Time and (r, pre) ∈ can_delegate, there exists

∈ Time s.t.

For every (u,r,ti) ∈ UD we have t + -ti < d

(t,UD) ( t+, UD)

Otherwise there exists (u, r, ti) ∈ UD, We have t+-ti=d

(t,UD) ( t+, UD\{(u,r,ti)})

4.6.2 K steps Delegation and Revocation with Time

This model is the generalization of the above model, which enables K step delegation and revocation with time. Following is the mathematical Modelling -of time based revocation for K-step delegation.

1. Let K ∈ ℕ some fixed value

2. U, R, UA, PA,≥, duration UD ⊆ U × R × Time: (rd, pre) ∈ can_delegate

3. Let duration be a total function from U × R to Time which can either be

ℕ or ℝ according to the fact that we assume a discrete or a continuous

flow of time.

4. The state of the system is a tuple (t, UD0,…,UDK) where t ∈ Time is the

current time and UD0, …,UDK are relations over user, role and time

5. If (r, pre) ∈ can_delegate, u is a member of role r and u satisfies pre Then (t, UDK) (t, UDK-1 ∪ {(u, r, ti)})

6. If duration (u, r) =0 then the role r cannot be delegated to the user u

7. If duration (u, r) = + ∞ then the role r can be delegated to the user u

but it cannot be revoked by time based revocation

8. If duration (u, r) = d ∈ Time and (r, pre) ∈ can_delegate, there exists

∈ Time s.t. For each j = {0, 1,… , K-1)

For every (u, r, ti) ∈ UDj we have t+ –ti<d

( t, UD0,…,UDK)(t+, UD0,… ,UDK)

Otherwise there exists j ∈ {0,…,K-1} and (u,r,ti) ∈ UDj We have t+- ti=d

(t, UD0,…, UDj,…,UDK) (t+, UD0,…,UDj\{(u,r,ti)},…,UDK)

4.6.3 User Based Revocation

The main disadvantage of the time based revocation or the automatic revocation is that it does not ensure security in some particular situations (Barka, 2002). For example, if the delegated member misused the permissions associated to the role received by delegation before the expiration of time, then there is no mechanism to revoke the role from the receiver before the whole time interval specified by the duration has elapsed. To overcome this problem, we can use the so-called revocation by the user. Any user associated to the role which is delegated or any user who has a senior role than the delegated role can revoke the role from the receiver, if they believe that the receiver is misusing

32

the delegated role. This method of revocation makes the original member of the role more powerful and it also enables the original member to protect the role and the system resources from being misused by the delegated user. This type of revocation is also known as human revocation. In this approach the system keeps track of the delegator also when performing the delegation.

For illustrating the revocation by the user in the role hierarchy, we can recall the example mentioned in time based revocation, where Alex decides to delegate part of his prof. role (teaching) to Eric who has the role Researcher for one month starting from 00:00 Hrs of 1st of August 2011 to 23:59.59 Hrs of 31st of August 2011. When the system time is reached to 00:00 Hrs of 1st of August, the delegation starts, i.e. Eric gets the permission to access the part of Alex role and Eric works on behalf of Alex. Theoretically the delegation expires on 23:59.59 Hrs of 31st of August 2011. But due to some reason, Alex came to work before the delegation expires and want his role back. In the case of voluntary revocation, the user associated to the role can revoke the role before the time expires. So Alex performs the voluntary revocation or revocation by user so as to get the role back from Eric before the expiration of the time interval during which he had foreseen to delegate his role.

Following is the mathematical Modelling of user-based revocation.

1. We use same formalization used for Modelling the time-based

revocation for one step delegation. So we have function duration and

the state of the system is a pair (t, UD) where t ∈ Time is the current

time and UD is the dynamic part of the user-role assignment relation.

However in this model, UD is added a fourth component to keep track

of the user who delegated the role. Formally, UD ⊆ U × R × Time × U

where (u, r, ti, u`) ∈ UD means that u has been delegated the role r at

the time instant ti by the user u`.

2. If (r, pre) ∈ can_delegate, u` is a member of role r and u satisfies pre Then (t, UD) (t, UD ∪ {(u, r, t, u`)})

3. If duration (u, r) =0 (see previous model, Time Based Revocation)

4. If duration (u, r) = + ∞ (see previous model, Time Based Revocation)

5. If duration (u, r) = d ∈ Time and (r, pre) ∈ can_delegate, there exists

∈ Time such that

For every (u, r, ti, u`) ∈ UD we have t + + ti < d

(t, UD) (t+, UD)

Otherwise, there exists (u, r, ti, u`) ∈ UD we have t+-ti=d

(t,UD) (t+, UD\{(u ,r, ti ,u`)})

6. User-based Revocation (t, UD ∪{(u, r, ti, u`)})(t, UD) if there exist user u``, roles r` and r`` such that. r` ≥ r and (u`, r`) ∈ UA and r`` ≥ r` and (u``, r``) ∈ UA

4.6.4 Cascading Revocation

The models considered so far do not allow us to revoke a role which has been delegated several times. For revoking such roles which has been delegated several times, we introduce the notion of cascading revocation. Cascading

33

revocation, also known as indirect revocation (Barka, 2002), is justified by the following observations.

1. If the user receiving the delegation loses its original membership on its

role then all the delegations received by this user is also revoked.

2. If the sponsoring user’s (a user which receive the delegation and forward

it to another user) sponsoring role is revoked, or if the sponsoring user

loses its original membership on its role then, all the delegation done by

the sponsoring users are also revoked.

3. If the user delegating the role loses its original membership on its role

then all the delegation done by this user is also revoked. It is because,

when the user delegating a role loses its original membership on its role,

then the delegation done by that user is not valid and hence the role that

has been delegated by the user is revoked (Barka, 2002).

4. Thus, cascading revocation can be defined as a way of indirectly or

automatically revoking the delegated roles from the users, if the

original member of the role or the sponsoring user or the delegation

receiving user of the role loses its membership to its role or to its

sponsoring role.

Figure 6 represents the delegation tree and figure 7 represents the data structure of RBAC for cascading revocation. The data structure of a node consist of the following elements: IDf represents the unique identifier of the node, uf is

Figure 6 :- Delegation Chain

Id1:

u1, r1,

t1

Id3:

u3, r3,

t3 Id2:

u2, r2,

t2

Id4:

u4, r4,

t4

Id6:

u6, r6,

t6 Id5:

u5, r5,

t6

Id7:

u7, r7,

t7

Id8:

u8, r8,

t8

Id9:

u9, r9,

t9

34

the user having the role rf, tf represents the time at which the delegation has been initiated and IDn represents the ID of the next node in the delegation chain. The root of the delegation tree is also called the head node. Node which has null in the IDn field is regarded as the last node in the delegation chain and is the leaves of the delegation tree.

When a new node is added to the delegation tree, a new ID for uniquely identifying it is created. In the uf field the user receiving the delegation is mentioned, in the rf field the role that has been delegated is mentioned, in the tf field the instant at which the delegation starts is indicated and in the IDn field null is mentioned. A user delegating a role will add new node as its son in the delegation tree. Let us consider the example from the figure 6, and assume that the user u3 wants delegate role r6 to user u6. At first user u3 creates a node with unique ID say ID6 and then u3 delegates the role r6 to it from time t6. On the IDn field of ID6 node null will be mentioned by u3 which indicates that it is the end of the delegation chain. Finally, user u3 will add to its IDn the new identifier ID6.

When deleting the node from the delegation chain (revocation), the user deleting the node will update its IDn field to null which indicates that it is the end of the delegation chain. Let us consider the example from figure 6, let us assume that the user u3 wants to delete the node ID6. In this case, user u3 will update its IDn node as Null and the node identified ID6 will be deleted.

While delegating the role by the user who is associated with the senior role, it is necessary to check if the receiving user is already associated with that role that is going to be delegated or not. If the case is that the receiver of the role has been already associated with that particular role then the delegator will not delegate it. Delegator will only delegate its role to the users associating the junior role if he does not see any mapping between the role that is going to be delegated and the user. Let us consider the example from the figure 6, lets us assume that u5 wants to delegate r0 to u8. Before delegation r0 to u8, u5 will check if u8 is already associated to the role r0 or not. User u5 will only delegate the role r0 to user u8 if user u8 is not associated to r0 yet.

Figure 7 :- Data Structure of a Node

IDf uf rf tf IDn

Haru, DIT, T0

Alex, Prof., T2 Eric, Researcher, T3

Lee, HOD, T1

Man, Assistant, T4

Figure 8 :- Delegation Chain with user, role and time

35

Now from figure 8, lets us consider the following example to illustrate the cascading revocation. Haru DIT (Director of IT) by his role wants to develop an application which keeps tracks of the employee using social networks during Office hours. For developing that application he delegates its development to Lee who is HOD (Head of Department) by role. After analyzing the problem, Lee delegates part of the project to Alex who is Prof. and Eric who is Researcher respectively. After analyzing the task, Eric delegates part of the project to Man who is Assistant. Before delegating the part of the project to Man, Eric will check if Man has already received the delegation for that project or not. Eric will only delegate the project to Man if he has not yet received the project as delegation.

In the case of Cascading Revocation (from figure 8) the following conditions are valid:

1. If Lee loses his membership in HOD, then the delegation done by Lee

won’t be valid so, Alex, Eric and the Man will loses their membership

on the project.

2. If Eric loses his membership in Researcher role, then Eric will lose his

membership on the project and Man will also lose his membership on

project.

3. If Lee loses his membership on the project, then the Eric, Alex, Man

will also lose the membership on the project.

4. If Man loses his membership in Assistant role then he will also lose his

membership on project.

5. If Haru loses his membership in DIT role then all the delegation done

by the Haru will be invalid, hence all the receiver of the delegation done

by Haru will lose the membership on the role delegated by Haru.

The following is the mathematical Modelling of cascading revocation.

1. In this model, UA is added two components to build a delegation tree

that keep track of who performed the delegation. Formally, UA ⊆ Id ×

U × R × Time × Id

2. Tuples (id, u, r, ti, id`) ∈ UA are written as id: (u, r, ti)id` where Id is

an infinite set of identifiers for the nodes in the delegation tree and are

called nodes of UA

3. If (r, pre) ∈ can_delegate There exists id`: (u`, r`, ti`) id`` such that, u` is a member of role r and u satisfies pre then, (t, UA)(t, UA U{id: (u, r``, t)null, id`: (u`, r`, ti)id}) for some r`` which is junior or equal to r and id ∈ Id is distinct from all the id’s in UA

4. If duration (u, r) =0 (see previous model, Time Based Revocation)

5. If duration (u, r) = + ∞ (see previous model, Time Based Revocation)

6. If duration (u, r) = d ∈ Time and there exists ∈ Time such that

36

For every id: (u, r, ti) id` we have t + - ti < d

(t, UA) (t+, UA)

Otherwise, there exists id: (u, r, ti) id` we have t + - ti =d (t, UA)(t, UA`) where UA` has been obtained from UA by deleting all the tuples which are reachable from the node idf: (uf, rf, tf)id and the latter is replaced with the node idf:(uf,rf,tf,)Null where Null indicates that the chain of delegation is finished.

7. User based revocation There exists a node id: (u, r, t) id`, user u` and role r` such that u` is a member of role r` which is more senior or equal to r, we have (t,UA) (t, UA`) where UA` has been obtained from UA by deleting all the tuples which are reachable from the node idf: (uf, rf, tf)id and the latter is replaced with the node idf: (uf, rf, tf,)Null where Null indicates that the chain of delegation is finished.

4.6.5 Modelling of Revocation of Permanent Delegation

We have tried to reduce additional human intervention such as that of administrators or security managers while modelling delegation of RBAC. But in the case of revocation of permanent delegation we have decided to resort to an administrator or a security manager for the revocation of the role. This is so because, once the role is permanently delegated, the user who receives the delegation becomes the permanent member of the role and gets all the permissions as an original member of the role. The original member, who performs the permanent delegation, will lose all of his rights and control over the particular role that has been delegated. Hence, there will be no user in the role hierarchy to revoke this kind of delegation; this is the reason why we have decided to resort to the system administrator or the security manager to perform revocation. This kind of revocation can be seen as an administrative action of the ARBAC model (Alberti, et al., 2011) (Armando & Ranise, 2010) and it is outside the scope of this thesis.

4.7 Implementation

4.7.1 Introduction

We have implemented one of our models for delegation of roles so as to make a framework for upcoming research. We decided to use standard SQL (structured Query Language) database software MySQL (Since it is open source database and easy to use.). Each relation of RBAC can be considered as a table in SQL which was the main motivation behind choosing it. For example, User assignment relation (UA ⊆ U × R), can be considered as UA table (its member field are users and role), Permission assignment relation (PA ⊆ R × P) as PA table (its member fields are Role and Permission), Role Hierarchy (RH ⊆ R × R) as RH table (member fields are Srole and Jrole), User Delegated relation (UD ⊆ U × R) as UD table (member fields are user, role) and can_delegate relation (can_delegate ⊆ R ×pre) as CD table (member fields are sign, role, rd.).

37

4.7.2 User to permission

While validating our model, we will consider the same example of the case which is defined above in this chapter. After mapping the relation with table we will get following tables for UA (Table 1), PA (Table 2). UserToPermission table shows “which user has what permission?” and is obtained by joining the UA table and PA table.

4.8 Which user can delegate what role?

In this subsection we will identify which user can delegate what role. RH table which can be seen in Table 4 shows the relation between SRole (senior role) and JRole (junior role). Since the RH is reflexive means that every role is related to itself. So as to make RH table reflexive we mentioned it explicitly. For example, we can see DIT in Srole field and DIT in Jrole field.

UA Users Role Haru DIT Lee HOD Alex Prof Eric Res Man Ast Ben SA

Table 1 : UA Table

PA Role Permission DIT P1 HOD P2 Prof P3 Res P4 Ast P5 SA P6

Table 2 : PA Table

RH SRole JRole DIT HOD HOD Prof HOD Res DIT Prof DIT Res Prof Ast Res Ast HOD Ast DIT Ast Ast SA Prof SA Res SA HOD SA DIT SA DIT DIT HOD HOD Prof Prof Res Res Ast Ast SA SA

Table 4 : RH Table

UCD User Role Haru DIT Haru HOD Haru Prof Haru Res Haru Ast Haru SA Lee HOD Lee Prof Lee Res Lee Ast Lee SA Alex Prof Alex Ast Alex SA Eric Res Eric Ast Eric SA Man Ast Man SA Ben SA

Table 5 : View UCD

UserToPermission User Permission Haru P1 Lee P2 Alex P3 Eric P4 Man P5 Ben P6

Table 3 : User to Permission Table

38

After defining RH, We are interested in the investigation role delegation by the particular user. This was done by joining UA table, PA table and RH Table. The results obtained from joining these tables were stored as a view in SQL for future use. Table 5 shows the view UCD, which state that which user can delegate what role. The users in the user field of UCD table are the user who can delegate the corresponding roles shown in role field.

4.8.1 Is the user allowed to receive delegation?

This sub section deals with finding if the candidate user is authorized to receive any delegation. As stated in the previous sections of this chapter, in order for a user to receive a delegation user must satisfy the pre conditions. Pre condition is set of signed role but for purpose of simplicity to verify the model we use a single signed role (only +) i.e. we only check candidate user if it is a member of role in UA. Table 6 shows Can_delegate table.

Roled field in can_delegate refers to the role that is going to be delegated and Role field (pre condition) refers to the role of a user to whom delegation is going to be performed. Now we have to find out if there is any user having the role Res on UA table. In this case we can find out that Eric is the user associated to the role Res in UA, so we can conclude that the user Eric is a candidate user for receiving the delegation.

4.8.2 How delegation is performed?

After finding out the eligible candidate user to receive the delegation and the user performing delegation, the query such as, “Can Haru delegate HOD role to Eric?” can be done as

1. Checking the view CD (table 5) if Haru can perform delegation of the HOD role or not. In this case it can be clearly seen that he can (It can be seen in table 5).

2. Identifying if Eric is the candidate user for receiving the delegation. In above section we have already found that the Eric is the candidate user for receiving delegation on the basis of can_delegate table (table6).

3. Now both condition are satisfied, so Haru will delegate the role HOD to Eric and update the UD table. After updating UD table it will look like table 7.

Can_delegate Roled Role HOD Res

Table 1 : Can_delegate Table

UD User Role Eric HOD

Table 2 : UD Table

39

Hence, by following the above mention steps we have implemented one of our models for delegation (one step grant delegation model in RBAC1). Similarly, remaining models can be implemented by extending this technique.

40

5 Conclusions and Future work

One of the most important extensions for flexibility to RBAC consists of adding a delegation and revocation mechanism for the roles. The contribution with this work is the abstract mathematical framework (based on set theory) to specify the various types of delegation and revocation considered in E. Barka’s PhD thesis (Barka, 2002). On the basis of the framework presented by E. Barka, we have presented a mathematical model for specifying the delegation and revocation of roles in RBAC which are necessary to maintain some desired security property. We have generalized E. Barka’s approach by introducing a precondition to make delegation more flexible. While modelling, we have introduced some rules known as precondition, which a user must satisfy to be identified as a candidate user to receive the delegation. Any user satisfying the precondition is eligible to receive either the grant delegation or the transfer delegation.

In grant delegation, roles are delegated to another user according to some rules, and the delegator maintains his membership in the delegated role. Grant delegation comes in two flavours i.e. with or without role hierarchy. Grant Delegation proposed in this thesis for RBAC0 does not account the role hierarchy and the roles that have been delegated once cannot be delegated further. Whereas, grant delegation in RBAC1 account role hierarchy. We have presented three sub models for grant delegation in role hierarchy, they are:-

1. One step delegation where roles are delegated within role hierarchy for one time and the roles that have been delegated once cannot be delegated further

2. Two-step delegation where the role received from a delegation can be further delegated to another user, but the user receiving the second delegation cannot delegate that role further.

3. K step delegation is the generalization of the previous delegation model, which enables users to delegate the role for K steps.

In, transfer delegation the user associated with the role can transfer its role to any user provided that he satisfies some preconditions. In case of transfer delegation, the delegator loses his membership in the delegated role. Transfer delegation also comes in two flavours i.e. in RBAC0 and RBAC1. Transfer delegation in RBAC0, the user is checked to be an explicit member or not to be an explicit member of the role. Instead in RBAC1, the user is checked to be (not to be) a member (either implicit or explicit) of the role.

Revocation of grant delegation proposed in this thesis can be done by

1. Time based revocation: - In this model each user associated to the role is assigned to a certain period of time for which the role can be delegated to the user. When the assigned time interval has elapsed, the delegation expires automatically.

41

2. User based revocation: - In this model, we assume that any user associated to the role which is delegated or any user who has a senior role than the delegated role can revoke the role from the receiver, if they believe that the receiver is misusing the delegated role.

3. Cascading revocation: - Cascading revocation also known as indirect revocation revokes the role automatically from the users, if the original member of the role or the sponsoring user or the delegation receiving user of the role loses its membership to its role or to its sponsoring role.

Finally, for the revocation of the roles done by transfer delegation, we have decided to resort to an administrator or a security manager.

We have achieved the main goal of this thesis which was to clarify the situation to provide a clean and simple mathematical model of various flavours of delegation and revocation of roles on RBAC framework introduced by E. Barka (Barka, 2002). In this way, the consequences of delegating one role from a user to another user are more easily foreseen.

5.1 Discussion

On the basis of RBAC96 model which was developed by R. Sandhu, E. Barka in (Barka, 2002) has provided framework for two (RBAC0 and RBAC1) role based delegation and revocation models to illustrate some practical access control policies. But it does not cover mathematical Modelling of delegation and revocation of roles in RBAC. This thesis has come up with the mathematical Modelling of grant and transfer delegation with two flavours of RBAC (RBAC0 and RBAC1), time based revocation, user-based revocation and cascading revocation are also modelled. This mathematical Modelling for delegation and revocation of roles in RBAC96 helps an authorized user to delegate or revoke his role or some junior roles to another user in efficient and secure manner.

Similarly E. Barka in (Barka, 2002) has defined can-delegate function in his framework which describes what type of role a user can delegate. But unfortunately, he has not mentioned any condition which a user must satisfy in order to receive the delegation, for this problem we have defined a precondition. Preconditions, which is used to identify candidate users to receive the delegation. It means that a receiver of a delegation must satisfy a precondition in order to receive various types of delegation role.

In 2000 G.J. Ahn and R. Sandhu in (Ahn & Sandhu, 2000) has defined Role-Based Authorization Constraints Specification and also introduce an intuitive formal language for specifying role-based authorization constraints named RCL 2000 including its basic elements, syntax, and semantics. Their model is more towards authorization rather than delegation and revocation of roles.

Mathematical Modelling of ARBAC, which deals with the administration aspect of RBAC, which is well defined and fully formalized (Armando & Ranise, 2010) (Alberti, et al., 2011) and unfortunately, does not deals with delegation and revocation of roles of RBAC.

42

5.2 Future work

There are several important and interesting aspects of this thesis that can be investigated in the future. Some of them are enumerated below.

1. On the basis of the mathematical model proposed in this thesis, developing and implementations of delegation and revocation of roles in RBAC can be done using standard SQL.

2. The mathematical models proposed by us can be extended by taking session variable into consideration.

3. Further extension of this mathematical model can be done by integrating the mathematical model purposed by us with RBAC2 and RBAC3.

4. A user-friendly front-end to the language can be developed so that it can be realistically used by security policy designers.

43

References

Ahn, G. & Sandhu, R., 2000. Role-Based Authorization Constraints Specification. ACM

Transactions on Information and System Security, 3(4), p. 207–226. Alberti, F., Armando, A. & Ranise, S., 2011. Efficient Symbolic Automated Analysis of

Administrative Role Based Access Control Policies. Hong Kong, s.n.

Armando, A. & Ranise, S., 2010. Automated Symbolic Analysis of ARBAC Policies. Athens,

s.n.

Armando, A. & Ranise, S., 2011. Automated Analysis of Infinite State Workflows with Access

Control Policies. Copnhagen, s.n.

Barka, E., 2002. Framework for Role-Based Delegation Models, Virginia: s.n.

Barka, E. & Sandhu, R., 2000. Framework for Role-Based Delegation Model. s.l., s.n.

Barka, E. & Sandhu, R., 2004. Role-Based Delegation Model / Hierarchical Roles (RMDM1).

s.l., s.n., pp. 396-404.

Bishop, M., 2003. Computer Security: Art and Science. s.l.:Addison Wesley Professional.

Booth, W., Colomb, G. & Williams, J., 2003. The Craft of Research. 2nd ed. Chicago: The

University of Chicago Press.

Butler, R. W., 2001. What is Formal Methods?. [Online]

Available at: http://shemesh.larc.nasa.gov/fm/fm-what.html

[Accessed 1 Dec 2011].

Collins, M., 1998. Formal Methods. [Online]

Available at: https://users.ece.cmu.edu/~koopman/des_s99/formal_methods/

[Accessed 5 November 2016].

Creswell, J., 2003. Research Design: Qualitative, Quantitative, and Mixed Methods

approaches.. s.l.:s.n.

Denscombe, M., 2007. The Good Research Guide for small-scale social research projects..

3rd ed. s.l.:Berkshire: Open University Press..

Department of Defense, 1985. Trusted computer system Evaluation Criteria (TCSEC), s.l.:

s.n.

Ferraiolo, D. F., Cugini, J. A. & Kuhn, D. R., 1995. Role-Based Access Control (RBAC):

Features and Motivations. 11th Annual Computer Security Applications Proceedings.

Ferraiolo, D. F. & Kuhn, D. R., 1992. Role-Based Access Controls. s.l., s.n., pp. 554-563.

Finin, T. et al., n.d. ROWLBAC - Representing Role Based Access Control in OWL. [Online]

Available at: http://aisl.umbc.edu/resources/391.pdf

[Accessed 29 Nov 2011].

Formal Methods Group, CS Department, University of Toronto, 2004. Formal Methods.

[Online]

Available at: http://www.cs.utoronto.ca/fm/

[Accessed 2 Dec 2011].

Jansen, W., n.d. Inheritance Properties of Role Hierarchies. [Online]

Available at: http://csrc.nist.gov/groups/SNS/rbac/documents/design_implementation/pp-

rbac-fin.pdf

[Accessed 29 Nov 2011].

Joshi, J. D. B. & Bertino, E., n.d. Fine-grained Role-based Delegation in Presence of the

Hybird Role Hierarchy. [Online]

Available at: http://delivery.acm.org/10.1145/1140000/1133071/p81-

joshi.pdf?key1=1133071&key2=9683991031&coll=DL&dl=ACM&ip=193.205.206.25&CFI

D=15051949&CFTOKEN=87314875

[Accessed 29 Nov 2011].

Kuhn, D. R., Coyne, E. J. & Weil, T. R., 2010. Adding Attributes to Role-Based Access

control.

44

Leech, N. & Onwuegbuzie, A., 2006. . A typology of mixed methods research designs., s.l.:

Springer.

Li, N. & Tripunitara, M. V., 2006. Security analysis in role-based access control. s.l., s.n.

Marion, G., 2008. An Introduction to Mathematical Modelling, s.l.: Bioinformatics and

Statistics, Scotland.

Sandhu, R., 1996. Rationale for the RBAC96 Family of Access Control Models. s.l., s.n.

Sandhu, R., Bhamidipati, V. & Q., M., 1998. The ARBAC97 Model for Role-Based

Administration of Roles, s.l.: s.n.

Sandhu, R., Coyne, E. J., Feinstein, H. L. & Youman, C. E., 1996. Role-Based Access

Control Models. IEEE Computer, Volume 29, pp. 38-47.

Sandhu, R., Ferraiolo, D. & Kuhn, R., n.d. The Nist Model for Role-Based Access Control:

Towards a Unified Standard.. [Online]

Available at: http://csrc.nist.gov/rbac/sandhu-ferraiolo-kuhn-00.pdf

[Accessed 29 Nov 2011].

Schneider, F. B., 2000. Enforceable Security Policies. ACM Transactions on Information and

System Security, 3(1), pp. 30-50.

Tyson, B., n.d. Example of Effective Delegation. [Online]

Available at: http://www.brighthub.com/office/project-management/articles/85926.aspx

[Accessed 29 Nov 2011].

Zhang, L., 2005. Role-Based Delegation: Models and Mechanisms, Charlotte: s.n.

45

Appendix 1

Definition of the Terms

Term Meaning

Anti-symmetric Relation

:-

An anti-symmetric relation in mathematics is defined as a binary relation R on a set S for which, if for all a and b in S, if R (a, b) and R (b, a) then it implies that a=b. Or, Equivalently, if R (a, b) where a ≠b, then (b, a) must not hold. Simple example of anti-symmetric is the relation of “x as even and y as odd" between a pair (x, y) of integers.

Binary relation

:-

A binary relation can be defined as the subset of the cartesian product. For example, A binary relation R is sub set of R × R.

Cartesian product

:-

Cartesian product also known as product set or cross product is the product of two sets. It is denoted by × and is written as U × R (where U and R are two sets).

Partial order :-

A partial order relation in mathematics is defined as a binary relation ≥ on a set S for which is reflexive, anti-symmetric and transitive. For example, for all a, b, c in S following property must hold.

Reflexive: a ≥ a, for all a ∈ S.

Anti-symmetry: a ≥ b and b ≥ a then it implies a = b.

Transitivity: a ≥ b and b ≥ c then it implies a ≥ c.

Reflexive Relation

:-

A reflexive relation in mathematics is defined as a binary relation R on a set S for which, every element of the set S is related to itself. Equality, is senior than or equal to, is junior than or equal to etc. are the example of a reflexive relation. Following example can be taken into consideration to clarify reflexive relation, Suppose we have a set S and a relation R on S. A relation R on a set S is called reflexive if and only if for every element a in S, (a ,a) is in R.

Set :-

In Mathematics, A set can be defined as the collection of finite or infinite object. Set are represented by capital letters, for example Set A, and Set B are represented as A and B respectively.

Subset :-

A subset can be defined as the portion of a set. If every element of the set A is contained in set B then, we say that the set A is the subset of set B. It is denoted by ⊆ and written as A ⊆ B

Transitive Relation

:-

A transitive relation in mathematics is defined as a binary relation R on a set S for which, if an element a is related with an element b and an element b is related with an element c, then we can say that an element a is related to an element c. Smaller then, smaller than or equal to, greater then, greater than or equal to, relations are transitive. We can take following example to illustrate transitive relation. If the value of A is less than the value of B and if the value of B is less then value of C, then the value of A will be less than the value of C. A relation R on a set S is called transitive if ordered pairs (a, b) and (b, c) is in R, then (a, c) in is R.

46

Appendix 2

Notation and Symbols

Sign Meaning

× :- Cartesian product

≽ :- Is More Senior Than or equal to

⊆ :- Is Subset of

∈ :- Is In or Belongs to or is the member of

= :- Is equal to

∪ :- Union

± :- Plus minus

≠ :- Is not equal to

∞ :- Infinite

ℕ :- Natural Number

ℝ :- Real Number

:- Time

< :- Less than

{ } :- Set

∉ :- Does not Belongs to or is not a member of

r :- Role

r` :- Role senior than role r

u :- User

u` :- User having the senior role than user u

∃ :- There exists

∄ :- There does not exists

∀ :- For all

rn :- Nth Role.

un :- Nth user

:- Implies

\ :- Difference

47

Appendix 3

List of Abbreviations

AC - Access Control

ARBAC - Administrative RBAC

DAC - Discretionary Access Control

DIT - Director of Information Technology

FBK - Fondazione Bruno Kessler

HOD - Head of Department

IBAC - Identity-Based Access Control

ICT - Information Communication Technology

IT - Information Technology

MAC - Mandatory Access Control

PA - Permission Assignment

Pre - Precondition

RBAC - Role Base Access Control

RH - Role Hierarchy

SQL - Structured Query Language

ST - Security and Trust

TCSEC - Trusted Computer System Evaluation Criteria

UA - User Assignment

UD - User Delegated

TRITA TRITA-ICT-EX-2017:133

www.kth.se