Access control mechanisms for an IoT platform

(1)

Universidade de Aveiro Departamento de Eletrónica,Telecomunicações e Informática 2019

Rui Filipe Dominguez

de Oliveira

Mecanismos de controlo de acesso para uma

plataforma de IoT

(2)

(3)

Universidade de Aveiro Departamento de Eletrónica,Telecomunicações e Informática 2019

Rui Filipe Dominguez

de Oliveira

Mecanismos de controlo de acesso para uma

plataforma de IoT

Access control mechanisms for an IoT platform

Dissertação apresentada à Universidade de Aveiro para cumprimento dos requisitos necessários à obtenção do grau de Mestre em Engenharia de Com-putadores e Telemática, realizada sob a orientação científica do Doutor André Ventura da Cruz Marnoto Zúquete, Professor auxiliar do Departamento de Eletrónica, Telecomunicações e Informática da Universidade de Aveiro.

(4)

(5)

o júri / the jury

presidente / president Prof. Doutor João Paulo Silva Barraca

Professor Auxiliar do Departamento de Eletrónica Telecomunicaões e Informática da Universi-dade de Aveiro

vogais / examiners committee Prof. Doutora Maria Dulce Pedroso Domingos

Professora Auxiliar do Departamento de Informática da Faculdade de Ciências da Universidade de Lisboa

Prof. Doutor André Ventura da Cruz Marnoto Zúquete

Professor Auxiliar do Departamento de Eletrónica Telecomunicaões e Informática da Universi-dade de Aveiro

(6)

(7)

agradecimentos /

acknowledgements Queria aproveitar este momento para agradecer a todos os que me ajudaram,direta ou indiretamente, no meu percurso académico. Em primeiro lugar gostaria de agradecer à minha família, em especial aos meus pais por todo o esforço que fizeram para que esta etapa fosse concluída. À minha irmã por também ela ter acompanhado de perto esta etapa.

Ao meu orientador, Prof. André Zúquete por todo o conhecimento transmitido, disponibilidade e, ainda, pela autonomia que me que me impôs ao longo da realização deste trabalho.

Também tenho que agradecer ao meu grupo de amigos que me acompanhou durante estes cinco anos.

À Universidade de Aveiro, Departamento de Electrónica, Telecomunicações e Informática e à Altice Labs por disponibilizarem tudo o que precisei para concluir este trabalho.

Por último, um obrigado à restante família e amigos que também fizeram parte desta jornada.

(8)

(9)

Palavras Chave Mecanismos de controlo de acesso, autorização, XACML, IoT, controlo de acesso baseado em atributos, avaliação de políticas.

Resumo Os mecanismos de controlo de acesso são utilizados para prevenir que

en-tidades não autorizadas acedam a recursos protegidos. A especificação XACML, para além de ser um dos padrões mais importantes, é também o mais utilizado para definir políticas de controlo de acesso. O XACML foi cri-ado pelo consórcio OASIS e distingue-se por definir uma linguagem de polí-tica de controlo de acesso num formato XML baseado em atributos. Ademais, a especificação também define uma arquitetura de referência e um modelo de avaliação dos pedidos de acesso de acordo com os atributos definidos nas po-líticas de controlo de acesso. A principal desvantagem do XACML surge atra-vés da utilização do XML para descrever políticas de controlo de acesso, uma vez que possui uma sintaxe bastante detalhada e redundante quando com-parado com outras linguagens. Por este motivo, propusemos uma linguagem de descrição de políticas de controlo de acesso baseado em XACML usando a linguagem YAML. Ao contrário do XACML, a linguagem YAML evidencia-se como mais simples, tornando as políticas de controlo de acesso mais fáceis de definir e de interpretar por humanos.

Um dos maiores desafios na construção de um mecanismo de controlo de acesso em IoT diz respeito à eficiência com que o sistema necessita de avaliar os pedidos de acesso, particularmente em sistemas com um grande número de clientes. A implementação da especificação XACML da Sun Microsystems é a solução mais utilizada para definir e avaliar regras de controlo de acesso; porém, não é a mais eficiente, uma vez que avalia as políticas de controlo de acesso através de uma pesquisa por força bruta.

A solução apresentada neste trabalho, baseia-se em duas estruturas de da-dos em árvore, nomeadamente a Árvore de Decisão e a Árvore de Combina-ção. Os atributos definidos nas políticas de controlo de acesso são extraídos e combinados e, posteriormente, organizados na Árvore de Decisão, que é usada para descobrir as regras que se aplicam a um determinado conjunto de atributos definidos num pedido de acesso. Por outro lado, a Árvore de Combi-nação é utilizada para calcular a decisão de autorização final de acordo com os algoritmos de combinação definidos nas políticas de controlo de acesso aplicáveis aos atributos definidos no pedido de acesso. Os resultados mos-tram que a nossa solução é cerca de duas ordens de grandeza mais eficiente que a implementação da Sun Microsystems.

Por último, de forma a melhorar o tempo de avaliação dos pedidos de controlo de acesso, apresentámos duas estratégias de cache que por cada pedido de acesso guardam a sub-árvore usada para calcular a decisão de autorização. Na primeira estratégia, a sub-árvore é criada e guardada por cada pedido que é avaliado pelo sistema de controlo de acesso. No que respeita à segunda estratégia, o cliente pode definir quando é que essa sub-árvore deve ser guar-dada para uso futuro. Os resultados experimentais mostraram que a primeira solução não apresenta melhorias na eficiência do sistema, enquanto que a

(10)

(11)

Keywords Access control mechanisms, authorization, XACML, IoT, attribute-based ac-cess control, policy evaluation.

Abstract Access control mechanisms are used to ensure that privileged information

and resources are not accessed by, or disclosed to, unauthorized entities. The XACML specification, in addition to being one of the most important standards, is also widely used to define access control policies. XACML was proposed by the OASIS consortium and defines an attribute-based access control policy language expressed in an XML format. The standard also defines a reference architecture and a processing model in which are described how access re-quests should be evaluated according to the attributes defined in access con-trol policies.

The main drawback of XACML is the verbosity of its syntax, since it uses XML. To overcome this issue, we defined an access control language in YAML upon the key concepts of XACML. Unlike XACML, the YAML language is simple, which makes access control policies easy to define and interpret by humans. The main challenge of creating an IoT access control system is the perfor-mance of the policy evaluation engine, particularly in systems with a large number of clients. Sun Microsystems’ implementation of the XACML spec-ification is the most widely used solution for defining and evaluating access control rules, but it is not the most efficient, since it performs a brute force search for evaluating the predicates defined in the access request against the access control policies defined in the authorization system. Our solution is based on two tree data structures, the Decision Tree and the Combining Tree. The attributes defined in the access control policies are extracted, combined and then later used to build up the Decision Tree. The Decision Tree is used to find the applicable rules for a given set of attributes defined in an access request. On the other hand, the Combining Tree is used to calculate the fi-nal authorization decision according to the combining algorithms defined in the access control policies applicable to a given access request. The results show that our solution is about two orders of magnitude more efficient than the Sun Microsystems’ implementation.

Finally, we also introduced two caching strategies to improve the performance of our engine. For each access request the engine creates and stores the subset of the Decision Tree that was used to calculate the authorization de-cision for a given request. In the first strategy, the engine creates and stores a Decision Tree subset applicable to each access request that hits the au-thorization system. In the second strategy, the client can define when each subtree should be cached by the engine. The experimental results showed that our first caching solution does not improve the performance of the engine, whereas the second solution improves the overall processing time.

(12)

(13)

5.7.1 Decision Tree . . . 74 5.7.2 Policies Transformations . . . 79 5.7.3 Evaluation algorithm . . . 90 5.8 Cache . . . 91 5.8.1 Guided cache . . . 92 5.8.2 Hash computation . . . 93 5.8.3 Cache revocation . . . 93 6 Prototype implementation 95 6.1 Framework . . . 95 6.2 Authorization API . . . 95 6.3 Hibernate . . . 96 6.4 C3p0 Connection pool . . . 96 6.5 Database . . . 96 6.6 xxHash . . . 97 6.7 Ehcache . . . 98 7 Experimental evaluation 99 7.1 Experimental environment and Datasets . . . 99

7.2 Performance analysis . . . 101

7.2.1 Standard solution . . . 102

7.2.2 Cache solutions . . . 106

7.2.3 Decision validation . . . 116

8 Conclusion and Future work 117 8.1 Conclusion . . . 117

(16)

8.2 Future Work . . . 118

9 References 119

A Comparison of the evaluation time distribution of SunPDP with AcapiPDP -Impact of the number of PolicySets, Policies and Rules 123 B Comparison of the evaluation time distribution of SunPDP with AcapiPDP

-Impact of the number of and and or elements 129

C Evaluation time distribution of the Standard cache solution - Impact of the

number of PolicySets, Policies and Rules 133

D Evaluation time distribution of the Standard cache solution - Impact of the

number of and and or elements 139

E Evaluation time distribution of the Guided cache solution - Impact of the number

of PolicySets, Policies and Rules 143

F Evaluation time distribution of the Guided cache solution - Impact of the number

of and and or elements 149

G Comparison of the evaluation time of the three solution - Impact of the number

of PolicySets, Policies and Rules 153

H Comparison of the evaluation time of the three solutions - Impact of the number

of and and or elements 159

(17)

List of Figures

2.1 An example of access control matrix. . . 7

2.2 ACL represents the columns of the access control list. . . 7

2.3 A capability represents the rows of the access control list. . . 8

2.4 Sample lattice structure. Based on [58]. . . 10

2.5 Bell-LaPadula Lattice generated by two categories - Nuclear and Chemical - and three classification levels - Top Secret, Secret and Classified. Based on [43]. . . 11

2.6 Information flow on Bell-LaPadula and Biba models. Based on [59]. . . 13

2.7 Example of indirect information flows on commercial systems. . . 16

2.8 Main concepts of Team-based access control model. Based on [68]. . . 17

2.9 Relationship among RBAC0, RBAC1, RBAC2 and RBAC3 models. Based on [63]. . 17

2.10 A family of Role-Based access control Models - RBAC0, RBAC1, RBAC2and RBAC3. Arrowed lines indicate mapping - a single arrowhead indicating one and double arrowhead indicating many. Taken from [63]. . . 18

2.11 Example of role hierarchies [24]. . . 19

2.12 The NIST RBAC reference model. Users-Sessions is a one-to-many relationship and the other relations are many-to-many. Based on [24]. . . 21

2.13 Example of SSD constraint on role hierachy. . . 22

2.14 A possible ABAC high-level architecture [38]. . . 24

2.15 XACML policy structure. Based on [25]. . . 26

2.16 XACML architecture [22]. . . 27

4.1 An example of a sequence of range rules taken from [47]. . . 36

4.2 The resulting Decision Diagram from the sequence of range rules illustrated in Figure 4.1. Example taken from [47]. . . 36

4.3 Forwarding tables of the Decision Diagram illustrated in Figure 4.2. Example taken from [47]. . . 37

4.4 An example of a Matching Tree taken from [61]. . . 38

4.5 An example of a Combining Tree taken from [61]. . . 39

(18)

4.7 An example of a X-MIDD taken from [53]. . . 40

5.1 High-level XACML reference architecture based on the architecture presented in Figure 2.16. 45 5.2 Proposed architecture. . . 45

5.3 Relational database schema. . . 69

5.4 Sample policy tree where the blue policies represent the original policy tree and the white subtree represents the clone of Policy 1 and its children nodes. . . 73

5.5 Sample policy in our YAML-based policy description language. . . 76

5.6 Decision Tree that results from the policy tree illustrated in Figure 5.5. . . 77

5.7 Combining Tree resulting from PolicySet 1, Policy 2 and Rule 3. . . 78

5.8 Combining Tree resulting from PolicySet 1, Policy 2 and Rule 4. . . 78

5.9 Combining Tree resulting from the merging of the Combining Trees of Figures 5.7 and 5.8. 78 5.10 Resulting AttributePathList by applying the method parseTarget() to the Target element of the Policy stored in the database and described in Appendix I, Listing I.1. . . 81

5.11 Sample policy in our YAML-based policy description language. . . 84

5.12 Resulting AttributePathList and AttributePath of each PolicySet, Policy and Rule of the policy tree illustrated in Figure 5.11. . . 85

5.13 AttributePathList that results from the intersection of AttributePathList 1, 2, 3 and 4 illustrated in Figure 5.12. . . 86

5.14 AttributePathList that results from the intersection of AttributePathList 1, 5, 6 and 7 illustrated in Figure 5.12. . . 86

5.15 Decision Tree that results from the policy tree illustrated in Figure 5.11. . . 87

5.16 Combining Trees of the Decision Tree illustrated in Figure 5.15. . . 88

5.17 Sample Combining Tree. . . 89

5.18 Sample Combining Tree. . . 89

5.19 Combining Tree resulting from the merge of the Combining Trees illustrated in Figures 5.17 and 5.18. . . 89

5.20 Decision Tree that results from the policy tree illustrated in Figure 5.11. The orange nodes represent the Decision Tree’s nodes that are used to compute the authorization decision for the request illustrated in Figure 5.34. . . 94

7.1 The median of the acess decision evaluation time. The lower and upper whiskers represents the 1st and 3rd quartiles, respectively. . . 102

7.2 The median of the access decision evaluation time for different sizes of the Decision Tree (in terms of number of nodes). The lower and upper whiskers represent the 1st and 3rd quartiles, respectively. . . 103

7.3 The median of the access decision evaluation time. The lower and upper whiskers represent the 1st and 3rd quartiles, respectively. . . 103

(19)

7.4 The median of the Decision Tree and Combining Tree evaluation time, as well as the median time to fetch the pre-computed authorization decision. The lower and upper whiskers represent the 1st and 3rd quartiles, respectively. . . 105 7.5 Number of times the engine merged the Combining Trees to calculate the final authorization

decision and the number of times the system fetched the pre-computed authorization decision.105 7.6 Repeated requests separated by a distance given by a Poisson distribution. . . 107 7.7 The median of the access decision evaluation time for cache hits and cache misses. The

lower and upper whiskers represent the 1st and 3rd quartiles, respectively. . . 108 7.8 The median of the request evaluation time in the cases the request uses the cache (Type 1)

and does not use the cache (Type 2). The lower and upper whiskers represent the 1st and 3rd quartiles, respectively. . . 109 7.9 The median of the access decision evaluation time of the Standard solution, Standard

cache solution and Guided cache solution for datasets 1, 2, 3 and 4. The lower and upper whiskers represent the 1st and 3rd quartiles, respectively. . . 110 7.10 The median of the access decision evaluation time for cache hits and cache misses. The

lower and upper whiskers represent the 1st and 3rd quartiles, respectively. . . 111 7.11 The median of the access decision evaluation time in the cases the requests use the cache

(Type 1) and does not use cache at all (Type 2). The lower and upper whiskers represent the 1st and 3rd quartiles, respectively. . . 112 7.12 The median of the access decision evaluation time of the Standard solution, Standard cache

solution and Guided cache solution for datasets 5, 6 and 7. The lower and upper whiskers represent the 1st and 3rd quartiles, respectively. . . 113 7.13 The median of the access decision evaluation time and the hit ratio for three mean distances

between repeated requests: 10, 20, 30. The lower and upper whiskers represent the 1st and 3rd quartiles, respectively. . . 114 7.14 The median of the processing time to load the access control policies from the database for

datasets 1, 2, 3 and 4 in terms of total number of policies. The lower and upper whiskers represent the 1st and 3rd quartiles, respectively. . . 114 7.15 The median of the processing time to build the Decision Tree for datasets 1, 2, 3 and 4.

The lower and upper whiskers represent the 1st and 3rd quartiles, respectively. . . 115 7.16 The median of the processing time to load the access control policies from the database

for datasets 5, 6 and 7. The lower and upper whiskers represent the 1st and 3rd quartiles, respectively. . . 115 7.17 The median of the processing time to build the Decision Tree for datasets 5, 6 and 7. The

lower and upper whiskers represent the 1st and 3rd quartiles, respectively. . . 116

A.1 Access decision evaluation time distribution of SunPDP and AcapiPDP engines for dataset 1.124 A.2 Access decision evaluation time distribution of SunPDP and AcapiPDP engines for dataset 2.125

(20)

A.3 Access decision evaluation time distribution of SunPDP and AcapiPDP engines for dataset 3.126 A.4 Access decision evaluation time distribution of SunPDP and AcapiPDP engines for dataset 4.127

B.1 Access decision evaluation time distribution of SunPDP and AcapiPDP engines for dataset 5.130 B.2 Access decision evaluation time distribution of SunPDP and AcapiPDP engines for dataset 6.131 B.3 Access decision evaluation time distribution of SunPDP and AcapiPDP engines for dataset 7.132

C.1 Access decision evaluation time distribution of the Standard cache solution for dataset 1. 134 C.2 Access decision evaluation time distribution of the Standard cache solution for dataset 2. 135 C.3 Access decision evaluation time distribution of the Standard cache solution for dataset 3. 136 C.4 Access decision evaluation time distribution of the Standard cache solution for dataset 4. 137

D.1 Access decision evaluation time distribution of the Standard cache solution for dataset 5. 140 D.2 Access decision evaluation time distribution of the Standard cache solution for dataset 6. 141 D.3 Access decision evaluation time distribution of the Standard cache solution for dataset 7. 142

E.1 Access decision evaluation time distribution of the Guided cache solution for dataset 1. . 144 E.2 Access decision evaluation time distribution of the Guided cache solution for dataset 2. . 145 E.3 Access decision evaluation time distribution of the Guided cache solution for dataset 3. . 146 E.4 Access decision evaluation time distribution of the Guided cache solution for dataset 4. . 147

F.1 Access decision evaluation time distribution of the Guided cache solution for dataset 5. . 150 F.2 Access decision evaluation time distribution of the Guided cache solution for dataset 6. . 151 F.3 Access decision evaluation time distribution of the Guided cache solution for dataset 7. . 152

G.1 Comparison of the access decision evaluation time distribution of the three proposed solutions for dataset 1. . . 154 G.2 Comparison of the access decision evaluation time distribution of the three proposed

solutions for dataset 2. . . 155 G.3 Comparison of the access decision evaluation time distribution of the three proposed

solutions for dataset 3. . . 156 G.4 Comparison of the access decision evaluation time distribution of the three proposed

solutions for dataset 4. . . 157

H.1 Comparison of the access decision evaluation time distribution of the three proposed solutions for dataset 5. . . 160 H.2 Comparison of the access decision evaluation time distribution of the three proposed

solutions for dataset 6. . . 161 H.3 Comparison of the access decision evaluation time distribution of the three proposed

(21)

List of Tables

3.1 SmartIoT Account ACL. . . 32

3.2 SmartIoT Device ACL. . . 32

5.1 Numerical Matching functions supported by our description language. . . 59

5.2 Date and Time Matching functions supported by our description language. . . 59

5.3 Inclusion Matching functions supported by our description language. . . 60

6.1 Operations supported by the Authorization API. . . 95

7.1 Sample datasets. . . 100

(22)

(23)

Glossary

ABAC Attribute-based Access Control ACID Atomicity, Consistency, Isolation,

Durability

ACL Access Control List ACS Access Control Server

API Application Programming Interface ASF Asynchronous Framework

AWS Amazon Web Service

CDI Constrained Data Items

CRUD Create, Read, Update and Delete DAC Discretionary Access Control DSD Dynamic Separation of Duty HQL Hibernate Query Language IAM Identity and Access Management IBAC Identity-based Access Control IoT Internet Of Things

IVP Integrity Verification Procedure JBDC Java Database Connectivity JPA Java Persistence API JSON JavaScript Object Notation JVM Java Virtual Machine LBAC Lattice-based Access Control MAC Mandatory Access Control MIDD Multi-data-type Interval Decision

Diagrams

NIST National Institute of Standards and Technology

OASIS Organization for the Advancement of Structured Information Standards ORM Object-Relational Mapping

OS Object Server

PA Permission Assignment

PAP Policy Administration Point PDP Policy Decision Point PEP Policy Enforcement Point PIP Policy Information Point RBAC Role-based Access Control SQL Structured Query Language SSD Static Separation of Duty TMAC Team-Based Access Control TP Transformation procedure

UA User Assignment

UDI Unconstrained Data Items UTC Coordinated Universal Time W3C World Wide Web Consortium XACML eXtensible Access Control Markup

Language

XML eXtensible Markup Language YAML YAML Ain’t Markup Language

(24)

(25)

Chapter 1

Introduction

1.1 Motivation and Purpose

With the increasing number of information systems, services, and devices that are inter-connected with each other, it becomes necessary to ensure that privileged information and resources are not accessed by, or disclosed to, unauthorized entities.

Several enterprise solutions are being developed to regulate the access of legitimate users to sensitive information. However, protecting information from potentially malicious parties becomes a challenge due to the wide diversity of requirements that each one of the systems requires, as well as the dynamic environments in which those systems are located.

Altice Labs has two different access control platforms: the SmartIoT and the IAM (Identity and Access Management). SmartIoT is a platform used to regulate access to IoT-related resources where the subjects’ access rights to resources are defined through ACLs. On the other hand, IAM is intended to regulate the access in enterprise environments where subjects gains permissions over resources based on the Roles that they have associated with them.

The main drawback of SmartIoT is that ACLs do not offer great flexibility to express fine-grained and complex access control rules, as well as dynamic attributes (e.g. environmental conditions). To overcome this issue, our first effort was to use IAM to extend the functionalities of the SmartIoT platform. After analysing the IAM access control model, we came to the conclusion that it would not be feasible to adapt the SmartIoT platform to use cases requiring a fine-grained access control. The downsides of role-based access control include the fact that fine-grained access control leads to role explosion and, thus, role managing and reviewing tasks would be more difficult to perform.

For the reasons mentioned above, the main purpose of this thesis was to develop an access control mechanism capable to express real-world access control needs of IoT environments.

(26)

1.2 Contribution

After investigating the most relevant access control models in the literature, we concluded that the access control model that best fits the requirements we intended to achieve is the attribute-based access control (ABAC). In fact, ABAC is distinct from the traditional access control models because it describes complex and rich access control policies by including the attributes of Subjects, Objects, Operations and Environmental Conditions without specifying a formal relationship between Subject-Object entities. ABAC regulates the access of Subjects to Objects by evaluating the access control policies against the attributes defined in the access request. Environmental Conditions characterize the environment and, thus, dictate in which environmental conditions an access request can be accepted; current time and user/object location are examples of environmental conditions.

The OASIS XACML [20, 21, 22] is a platform-independent standard that defines an authorization policy language in an XML format for an attribute-based access control model. This standard also provides a reference architecture and defines a processing model in which are described how access requests should be evaluated according to the attributes and conditions defined in access control policies. XACML allows to organize access control policies in a complex tree structure, composed by PolicySets, Policies and Rules.

The main advantage of developing access control systems based on the principles of the XACML is that since it is based on ABAC, it offers great flexibility and expressiveness to deal with authorization issues. Furthermore, since XACML is a standard, the language is transversal to the access control systems developed by different companies. As a consequence of that, XACML policy language is applicable to several areas, such as grids, cloud, IoT, big data, enterprise organizations and networking.

Although the aforementioned advantages of the XACML, the standard has some limitations and drawbacks. In fact, defining and managing XACML policies in a large system can be a complex task and the evaluation performance of XACML-based authorization systems may be less than adequate for real-time systems.

The main drawback of XACML is the verbosity of the syntax of its policy language, since it uses XML. Due to the difficulty of directly describing policies in XML, systems that implement the XACML standard need to provide a graphical user interface to simplify the tasks of creating and managing access control policies. Motivated by the need of a less verbose and redundat description language, we proposed an attribute-based language in YAML, following the key concepts of XACML. Hence, security managers can define authorization rules directly in YAML without the use of a dedicated policy editing tool.

Moreover, the OASIS XACML specification does not specify how access control policies should be stored in the authorization system. Some XACML implementations store XACML policies as text files. However, in our opinion, it would be quite inefficient to read and store all access control policies on a large, distributed system while maintaining data consistency. Bearing this in mind, we take advantage of the PostgreSQL’s JSON profile to store the complex authorization logic defined in PolicySets, Policies and Rules into a database. The

(27)

YAML-based policies defined by security managers are, thus, converted to a JSON format and then stored in the database.

One of the main challenges of creating an IoT access control system is the performance of the evaluation engine, particularly in systems with a large number of clients. Therefore, besides defining a policy description that is rich enough to capture the requirements of complex and dynamic systems, it is essential to ensure an efficient evaluation of access control policies. Motivated by the need of a high-performance engine, the mechanism proposed in this thesis pre-processes the attributes defined in the PolicySets, Policies, and Rules, into a Decision Tree. The algorithm transforms the complex policy hierarchy into a simple tree structure in which each node represents an attribute and the associated operation. This approach improves the decision evaluation time by eliminating some steps from the decision process to a pre-processing step. The performance advantage of this solution over a traditional brute force analysis is that the evaluation time will vary according to the attributes defined in the acccess control policies rather than with the number of PolicySets, Policies and Rules defined in the authorization system.

It is worth mentioning that this thesis was based on the prior work on decision diagrams and policy optimization techniques of Liu et al. [47, 48], Pina Ros et al. [61], Ngo et al. [54] and Ngo et al. [53].

Finally, we also introduced two caching strategies to improve the performance of our engine. For each access request, the engine creates and stores the subset of the tree that was used to calculate the authorization decision for that request. In the first strategy, the engine creates and stores the substree that is applicable to each access request that hits the authorization system. In the second strategy, the client can define when the subtree should be cached by the engine.

1.3 Document structure

Chapter 2 starts by describing an overview of the main concepts and nomenclature used when designing access control systems. It also presents the most important access control models in the literature, as well as an overall analysis of their features. An overview of the XACML standard is also presented in this chapter.

Chapter 3 introduces the Altice Labs’ access management tools and its main advantages and drawbacks.

Chapter 4 reviews the related work on access control policies description languages and policy evaluation performance optimizations.

Chapter 5 revisits the XACML logic and presents the XACML features used in this thesis. In this chapter it is also presented the design choices, the proposed architecture and the security policies’ language based on the XACML standard. Based on that, it is presented our approach to transform the complex policies’ hierarchy into a simple data structure for efficient policy evaluation.

(28)

In this chapter it is also described the caching strategies used to improve the policy evaluation time.

Chapter 6 presents the technologies used to build the authorization API, namely database, framework and cache.

Chapter 7 analyses and validates our solution through performance time measurements. Finally, Chapter 8 presents the conclusions of our solution and states future work improve-ments.

(29)

Chapter 2

Context

In this chapter is presented a review on the literature related to access control systems. This chapter starts by presenting a definition of access control in Section 2.1. In Section 2.2 is presented the most import concepts that should be considered when designing access control systems: access control model, policy and mechanism. In Section 2.3 is presented the XACML standard, along with its main advantages and limitations.

2.1 Access Control Overview

Access control can be defined as a mechanism to protect sensitive data from unauthorized subjects by mediating how access to a resource is granted or denied according to specific criteria.

Access control decisions should be enforced by security policies that describe under which conditions a subject can perform a set of operations on a resource.

2.1.1 Access control entities

Access control systems design is based on four entities - subject, object or resource, action and the reference monitor:

• Subject: Entity that intends to perform an operation in a Resource; • Object/Resource: Entity to which the access must be regulated; • Action: Operation that a Subject intends to perform on a Resource;

• Reference monitor: Entity that regulates how Subjects can access Objects by enforc-ing authorization rules described in access control policies.

2.1.2 Policies, Models, and Mechanisms

According to [37], three concepts should be considered when planning and designing access control systems - access control policy, model and mechanism.

Access control policies are high-level requirements that specify under what criteria subjects may access sensitive resources. The security mechanism describes how the rules defined in

(30)

security policies are enforced for each access request and, finally, the access control model describes the security properties of an access control mechanism, as well as its limitations.

2.2 Access Control Models

In this section is presented a succinct description of some of the most important access control models in the literature.

2.2.1 Discretionary Access Control (DAC)

DAC is a type of access control purposed by the United States Government Department [46] that leaves to the discretion of the resource owner, or anyone else that is authorized to control the access to a resource, the ability to grant permissions to any other subject.

In DAC, since access permissions are not granted by a reference monitor according to the security requirements defined in access control policies, sensitive information can be transmitted to unathorized subjects. For example, if Jonh grants read access to his privates files to Alice, nothing prevents Alice from reading the information of those files and copy their information to other files which are owned by her and are shared with other users. Therefore, the information sets out of John’s control and thus, it can be disclosed to unauthorized entities.

The access control matrix, access control list and capability-based access control (see Sections 2.2.2, 2.2.3 and 2.2.4 respectively) are examples of discretionary access control.

2.2.2 Access control Matrix

Access control matrix is a discretionary access control introduced by Butler W. Lampson [45] that defines the set of access rights of each subject to every object within an operating system. Graham and Denning [17] [34] refined it and later Harrison, Ruzzo and Ullmann [36] proposed the HRU model.

The HRU model is a extension of the Graham-Denning model, which defines a set of commands made of primitive operations to modify the access matrix given a subject and an object.

As illustrated in Figure 2.1, the access control matrix is a table where columns correspond to objects and rows corresponds to subjects. Each cell in the table contains the list of privileges that a particular subject holds for a particular object.

According to P. Samarati and S. de Capitani di Vimercati [62], the access matrix, although representing a feasible authorization conceptualization, is difficult to implement in large systems with many subjects and objects. In that case, the access matrix will be enormous in size, mostly sparse and complex to manipulate.

Access Control List and Capability-based access control (see Section 2.2.3 and 2.2.4 respectively) are examples of traditional access control mechanisms based on the access control matrix.

(31)

2.2.3 Access control List

Access control list (ACL) is a resource-oriented access control and the most common imple-mentation of DAC policies. As illustrated in Figure 2.2, an access control list corresponds to a column of the access control matrix. Therefore, each column represents a list of subjects and their access rights for a particular object. Each entry in the list is a tuple (subject, set of rights).

In ACL-based systems it is easy to grant or deny access for a particular user or a set of users, as well as to determine which users have access to a particular object. On the other hand, ACLs does not easily provide a review of all privileges associated with a user in a computer system, since it is necessary to search all access control lists. As a consequence of that, ACLs are not suitable for large and dynamic systems with a large number of subjects and objects where a complex policy description is required.

Figure 2.1: An example of access control matrix.

(32)

Figure 2.3: A capability represents the rows of the access control list.

2.2.4 Capability-based access control

Capability-based access control is based on the concept of capability as a token, ticket, or key

that gives the possessor permission to access an entity or object in a computer system [18]. In

capability systems, a user is only allowed to access an object if it possesses a capability that confers access rights for that object.

Capacity-based access control and ACL, although based on the access control matrix (ACM), may be considered different representations of it. In fact, while in the ACL approach, each matrix column represents a list of subjects and their access rights for a particular object, a capability represents the access control matrix rows as lists of access rights for specific objects, in which each entry in the capability list is a tuple formed by object and set of access rights (see Figure 2.3). Thus, the capability is the inverse of an ACL. In fact, while ACLs are attached to objects and specify which subjects may access that object, a capability is attached to subjects and describes which objects a given subject may have access to.

Capability-based access control are well-suited to distributed systems since they easily review all privileges that a subject holds on a particular object. Contrary to ACLs, in capability-based systems, it is difficult to review the subjects that can access a particular object because the system would need to check every subject’s capability list.

According to L. Going [32], capability propagation is one of the main drawbacks of capability-based systems due to the absence of an entity that regulates the capability propa-gation. In fact, without a reference monitor or a regulatory authority, nothing prevents those possessing a capacity from transmitting it to unauthorized entities. Going also points out privilege revocation as a disadvantage of capability-based access control due to the difficulty in revoking privileges over a particular object in many subjects.

2.2.5 Identity-based access control (IBAC)

The IBAC model was introduced by L. Gong [32] to solve the main problems of traditional capability-based access control in distributed systems - revocation and transmission of capa-bilities. Contrary to traditional access control models, IBAC includes the subject’s identity in the capability. Furthermore, to solve the revocation and transmission of capabilities, L. Gong includes various servers for monitoring, mediating and recording capabilities propagation, as well as for managing capability revocation.

(33)

The IBAC architecture is composed by two different servers - The Access Control Server (ACS) and the Object Server (OS). The ACS, in addition to store the access control policies that will be used to verify that a capability can be propagated, also stores a propagation tree to record how they were propagated in the system. On the other hand, the OS stores all valid and revoked capabilities to check whether a capability presented by an object matches a capability previously stored.

A particularity that IBAC introduces over traditional capability-based systems is that capabilities are verified against security policies whenever they are propagated in the system rather than at access time. Furthermore, the exception list allows rapid revocation, solving the problem of traditional capability systems where capabilities are disseminated on the system. Despite the many advantages of the model, authors do not clearly specify how conditions to regulate the access to resources or capability propagation are defined in security policies while, at the same time, they do not clarify who creates security policies.

2.2.6 Mandatory Access Control

Mandatory Access Control is a security policy in which access control decisions are made by a central authority which regulates the usage of resources [38]. Unlike DAC, the owners of the objects are not able to make access control decisions, neither to change access rights to a particular object.

2.2.7 Multi-level security

In multi-level security systems, both subjects and objects are assigned with security classi-fications in order to define their security level in the system. A subject is only allowed to access an object if its security level has a given relation (equal to, greater or lower than) to the security level of the object.

2.2.7.1 Lattice-based access control (LBAC)

Lattice-based access control was proposed by Denning [16] in 1976 to deal with information flows in military systems. In this model, Objects and Subjects form a lattice that defines their security level in the system. A lattice is a mathematical structure of elements organized by a partial order relation among them by a relational operator ≤ [58]. The relationship between elements is called partial ordering if the following criteria is met:

• Transitive: if a ≤ b and b ≤ c, then a ≤ c; • Antisymetric: if a ≤ b and b ≤ a, then a = b.

As per the lattice on Figure 2.4, we can see that every pair of elements have an upper bound - elements 4 and 6 have upper bound 12 - and also a lower bound - element 2. The relational operation ≤ is also called dominance relation. Thus, the elements at the top of the lattice dominate the elements at the base of the lattice.

(34)

Figure 2.4: Sample lattice structure. Based on [58].

The lattice representation is widely adopted by the military model of Bell and LaPadula (see Section 2.2.7.2); and also by the commercial model proposed by Clark and Wilson (see

Section 2.2.8).

2.2.7.2 Bell-LaPadula model

The Bell-LaPadula model is a mandatory access control policy proposed by Bell and La-Padula [10] to deal with information flows within military and governmental computer systems. This model is based on the concept of a finite state machine in which the system always moves from one safe state to another. The authors define the various elements of the finite state machine, the conditions for a given state to be secure, as well as the set of allowed transitions.

The Bell-LaPadula model consists of a set of Subjects, Objects, access attributes, and

security levels. Objects are associated with security classifications and Subjects are

associated with security clearances.

A security level is typically defined as a pair:

(classification level, set of categories). An example might be:

(CONFIDENTIAL, {NUCLEAR, NATO})

The main concept of Bell-LaPadula model is the dominate operator. The security level (C, CS) dominates (C’, CS’) if and only if C ≥ C’ and CS’ ⊆ CS .

(35)

Bell-LaPadula model defines both discretionary and mandatory access control to enforce information flow and data confidentiality based on tree properties [10]:

• Simple security property: A subject S can only read an object O if S dominates O and S has discretionary access to O. This property ensures that a subject at a given security level cannot read an object with a higher security level. This property is also known as no read-up;

• Star-property or confinement property: A subject S can write to an object O if O dominates S and S has discretionary access to O. This property ensures that a subject at a given security level cannot write data to any subject with a lower security level. This property is also known as no write-down;

• Discretionary security property: It is used a matrix to define a set of privileges that subjects hold for objects. A subject S has discretionary access to O if the access attribute is contained in the entry (S, O). Contrary to the first two properties, the discretionary property allows to grant or revoke permissions;

In the Bell-LaPadula model, the security level is ordered by a relation ≤. Therefore, they can form a lattice (see Figure 2.5). According to the aforementioned properties, the basic premisse of Bell-LaPadula model is that information can only flow upward in terms of security classification.

Figure 2.5: Bell-LaPadula Lattice generated by two categories - Nuclear and Chemical - and three classification levels - Top Secret, Secret and Classified. Based on [43].

Bell and LaPadula have introduced in their model the principle of tranquility. This principle states that the classification of a subject or object never changes while it is being referenced. In practice, the tranquility problem has two forms:

• Principle of strong tranquility states that clearances of subjects and the classifica-tions of objects do not change during the lifetime of the security system;

(36)

• Principle of weak tranquility states that security levels may change but only if do not violate the simple security property. The principle of weak tranquility follows the

principle of least privilege.

The main drawback of this model is that, since it only protects information confidentiality, there is no enforcement of its integrity. In fact, subjects are still able to enforce improper indirect modification to objects they cannot write. For example, the integrity of a system would be compromised if a Trojan Horse implanted by a low-class subject improperly modifies data.

2.2.7.3 Biba model

The Biba model was published in 1977 by Kenneth J. Biba [11] and is the first formal integrity model. This model is a lattice-based access control in which each object and subject is assigned with a security level, or the so-called integrity level.

The main motivation for developing this model is the inadequacy of the Bell-LaPadula model to deal with information flows relatively to integrity control. Therefore, this model intends to guarantee that unauthorized entities do not improperly modify sensitive data.

To ensure data integrity protection, three properties define the secure information flow of the Biba model:

• Simple integrity property: This property states that a subject at a given level of integrity must not read data at a lower integrity level. This property is also known as no read-down;

• Star-property or integrity confinement property: This property states that a subject at a given level of integrity must not write data at a higher level of integrity. This property is also known as no write-up;

• Invocation property: This property states that a subject from a given integrity level cannot request access to objects from a higher integrity level.

The simple integrity and star properties are the dual of the first two principles of the Bell-LaPadula model but are concerned with data integrity. These properties ensure that once lower subjects read information of data items at a lower level they are prevented from contaminating high-level data items. As a consequence of that, using the Biba integrity model, threats like the Trojan Horse will not cause any improper data modification.

A system that satisfies the aforementioned properties ensures information integrity by preventing subjects to indirectly modify information they cannot write.

R. Sandhu considers that Biba and LaPadula are similar models since both are concerned with information flows based on lattice levels, whereby information flows are only allowed in one direction in the lattice [65]. As illustrated in Figure 2.6 in the Bell-LaPadula model information flows upward whereas, in the Biba model, information flows downward.

(37)

Figure 2.6: Information flow on Bell-LaPadula and Biba models. Based on [59].

2.2.8 Clark-Wilson model

The Clark-Wilson integrity model was proposed to address information integrity control in commercial systems rather than military applications. For that purpose, the Clark-Wilson model provides a framework for evaluating commercial security policies based on the concept of well-formed transactions and separation of duties to enforce commercial security policies:

• Well-formed transactions: A well-formed transaction is a set of operations that moves the system from one consistent state to another consistent state;

• Separation of duties: The separation of duties principle shall be enforced to guarantee the integrity of the transactions themselves. For example, a user who creates or certifies a well-formed transaction cannot perform it.

In the Clark-Wilson model, the access control policy is expressed in terms of integrity constraints imposed to data items and procedures to manipulate data. The main entities of the model are as follows:

• Constrained data items (CDIs): Data items that integrity must be ensured; • Unconstrained data items (UDIs): Data items that integrity cannot be protected; • Integrity verification procedures (IVPs): Procedure used to check that CDIs are

in a valid state at the time the IVPs are run;

• Transformation procedures (TPs): Procedure used to change data items state from one valid state to another; that is, transform all UDIs in valid CDIs or even create new CDIs.

The CDIs and UDIs are the two different integrity levels of the Clark-Wilson model. The higher level of integrity is represented by CDIs, whereas UDIs are the lower level data integrity

(38)

items. IVPs and TPs are intended to guarantee the integrity of the system and to ensure that the system always moves from one consistent state to another.

The relationship between CDIs and TP can be represented on the form of access triples:

< user, TP, CDIset >

where an authenticated user is authorized to perform a transaction procedure (TP) on a given set of constrained data items (CDIs).

In the Clark-Wilson model, integrity constraints are enforced through certification and enforcement rules. Certification rules define integrity constraints on the behavior of procedures, whereas enforcement rules are security mechanisms intended to enforce certification rules.

The certification (c) and enforcement (e) rules defined in the Clark-Wilson model are as follows:

• C1: Whenever a IVP is executed it must properly ensure that all CDIs are in a valid state;

• C2: A TP must transform CDIs from one valid state to another thereby maintaining data integrity of a system. The relation of TPs with CDI is in the form of (TP, (Set of CDIs)), where the list of CDIs define a set of arguments for which the TP has been certified;

• E1: The system must maintain a list of certified TPs allowed to manipulate CDIs specified on certification rule C1. It also states that CDIs can only be manipulated by TP;

• E2: The relations between Users, CDIs and TPs are represented in the form of (UserId, TP, (Set of CDIs)). That means, a User must only access a constrained set of CDIs by means of a specific TP for which they are authorized;

• C3: The relationship between CDIs, TPs and Users should only be allowed if it satisfies the requirements of separation of duties;

• E3: The user who is attempting to execute a TP must be authenticated by the system; • C4: TPs must log all useful information necessary to permit operations be reconstructed; • C5: Only valid TPs can be executed on UDIs and must transform UDIs in valid CDIs,

or otherwise reject the UDIs.

To provide a clear understanding of exactly what this means, the example taken from [58] will be used:

1. A Purchasing clerk creates an order for a supply, sending copies of the order to the supplier and the receiving department;

2. The supplier ships the goods, which arrive at the receiving department. A receiving clerk checks the delivery, ensures that the correct quantity of the right item has been received and signs a delivery form. The delivery form and the original go to the accounting department;

3. The supplier sends an invoice to the accounting department. An accounting clerk compares the invoice with the original order and the delivery form and issues a check to the supplier.

(39)

After analyzing the example described above, and according to the Clark and Wilson model, we can conclude that:

1. There are four Users - purchasing clerk, receiving clerk, supplier and accounting clerk; 2. There are some TPs such as create order, send order, create delivery form and so on; 3. There are some IVPs such as checks the deliver and compares the invoice with original

order ;

4. There are some CDIs such as order, deliver form, invoice and check.

It is importat to note that, to ensure information integrity by means of well-formed transactions and separation of duties only these steps must be performed, and in order. Moreover, to execute these steps the users must be authorized and authenticated.

2.2.9 Chinese Wall

The Chinese Wall [13] was proposed by Brewer and Nash to prevent information flows that could lead to conflicts of interest in consulting activities for the financial sector. Unlike Bell-LaPadula and Clark-Wilson models, the Chinese Wall intends to address both confidentiality and integrity. This model contains three types of entities that are defined in a hierarchical structure:

1. Objects: The separate items of information related to a company;

2. Company dataset: Is the set of information items related to a single company; 3. Conflict of interest class: Is the set of companies’ datasets in which conflicts can

occur.

In order to guarantee that there is no information flow that can cause conflict of interest, Brewer and Nash define two properties - simple rule and star property:

Simple security rule - A subject can read an object only if:

1. The object is in the same company dataset as the objects already accessed by that subject;

2. The object belongs to a conflict of interest class from which the subject has not previously consulted any information.

Star property - A subject can write an object only if:

1. The subject can read an object according to the simple security rule;

2. All objects that the subject can read are in the same company dataset as the object. The simple rule defines that a subject cannot access information that may result in conflict with any information that it has previously consulted. A simple real-world example of conflict of interest at organizational level may exist when a person, let’s say Hugo, leaves a company to work for a rival company. Even though he is not working in both companies at the same time, he may know sensitive information of his past company which may be useful in his current company.

On the other hand, the second property is aimed to prevent indirect information leaks. Suppose Paul and Teresa work in the same airline company. Paul also has access to Bank A and Teresa has access to Bank B as illustrated in Figure 2.7. Individually Paul and Teresa are in compliance with the Chinese Wall policy, however, if Paul writes confidential information

(40)

of Bank A into the airline company, Teresa, since she has read access to airline company’s objects, will have access to Bank A information when, in fact, she should not have.

Figure 2.7: Example of indirect information flows on commercial systems.

Ravi Sandhu [64] claims that the star property is useful to prevent information leakage by Trojan Horse attacks, however, can be restrictive and lead to the following problems:

• A subject that reads multiple company datasets cannot write at all;

• A subject that only reads objects from exactly one company dataset can only write to that dataset.

Sandhu considers these drawbacks are not inherent to the Chinese Wall policy [64] but they are a consequence of the Brewer-Nash model that do not properly distinguish rules applied to users from rules applied to subjects. In his work, he advocates that every user is able to write and read more than one company dataset, however, a user on behalf of a subject should not be allowed to perform both actions using the same subject.

Brewer and Nash, to overcome the write restriction also consider the concept of sanitized data. Sanitized data is derived from corporate data and prevents the corporation identity from being discovered. Since the corporation’s identity is not disclosed, the two aforementioned properties do not need to be enforced.

2.2.10 Team-Based Access control (TMAC)

Team-Based Access Control model introduced the concept of team in a collaborative environ-ment by applying some key-concepts of the RBAC model. A team is defined as a group of users in various roles that aims to accomplish specific tasks or goals under a collaborative context [68]. The collaborative context is composed by the users that form a team at any given moment (user context) and the objects required by the team to accomplish a particular task or activity (object context). Figure 2.8 illustrates how these concepts are interconnected.

The authors of [68] claim that traditional access control models such as ACLs, ACM and LBAC (see Sections 2.2.3, 2.2.2 and 2.2.7.1 respectively), contrarily to TMAC, are passive

(41)

security models, since they do not distinguish either permission assignment or activation. As a consequence of that, in the TMAC model, the permissions assigned to a user are determined by the team role to which he was assigned and can be activated or deactivated at run-time according to the progression of the task. Extensions to this model were proposed in [30] and [3].

Figure 2.8: Main concepts of Team-based access control model. Based on [68].

2.2.11 Role-based Access control

Role-based access control is a security model that regulates how the users may access resources based on their role as part of an organization rather than individual privileges [63]. In RBAC, the access rights granted to users depend on the roles that users have in the system and also the privileges and permissions associated with those roles.

Sandhu et al. [63] proposed an RBAC model constituted by a family of four distinct

conceptual models, as shown in Figure 2.9: RBAC₀, RBAC₁, RBAC₂ and RBAC₃.

Figure 2.9: Relationship among RBAC₀, RBAC₁, RBAC₂ and RBAC₃ models. Based

(42)

The RBAC0 model is the base of the RBAC model and consist of four main entities -roles, users, permissions and sessions.

The user is the entity that intends to access objects; permissions are used to define the mode of access to objects and roles can be considered a job function that contains a set of access rights that specifies the permissions available to users on objects.

Permissions are associated with roles, which in turn are assigned to users - see relation PA (Permission Assignment) and UA (User Assignment), respectively in Figure 2.10. As a consequence of that, users will acquire as many permissions as those associated with roles.

Figure 2.10: A family of Role-Based access control Models - RBAC0, RBAC1, RBAC2

and RBAC₃. Arrowed lines indicate mapping - a single arrowhead indicating one and double

arrowhead indicating many. Taken from [63].

The concept of sessions was introduced to link users to one or more roles. During a session, a user can activate, simultaneously, a set of roles and therefore, the permissions available to a user in a session corresponds to the union of permissions associated with the current active roles.

In RBAC, users may have multiple sessions open at the same time with a different combination of active roles according to the task they need to perform. Hence, RBAC supports the least privilege principle because users only have the permissions required to perform a particular task or job.

The RBAC₁ model, besides including all functionalities of RBAC₀, it also introduces

the concept of role hierarchy to organize roles into a hierarchical structure. A role, besides owning its own permissions, it also inherits the permissions of roles that are connected to it in a lower position on the hierarchy (subordinate roles). For example, as illustrated in Figure 2.11a, Director role inherits all the permissions of Project Lead 1 and Project Lead 2 roles. Furthermore, two different roles may inherit permissions of the same subordinate role -Production engineer 1 and Quality engineer 1 inherits the access rights of Engineer 1 role.

(43)

(a) Lattice role hierarchy.

(b) Inverted tree role hierarchy.

(c) Tree role hierarchy.

Figure 2.11: Example of role hierarchies [24].

The RBAC2 includes all the functionalities of RBAC0 and adds constraints to roles to

regulate user and permissions assignment. Constraints are important to prevent the same user be assigned to roles that can be conflicting. For example, in a company, the manager that regulates the payments should not audit transactions.

(44)

The RBAC2 constraints can be of four types: mutually exclusive roles, mutual

exclusive permissions, cardinality and prerequisite roles.

The mutual exclusive roles constraint must ensure that a user, to complete a sensitive task, can only be assigned to only one role considering a mutually exclusive set of roles. On the other hand, the mutual exclusive permissions constraint must ensure that a permission can only be assigned to only one role in a mutual exclusive set. The mutual exclusion in terms of user and permission assignment makes the model suitable for systems that require support to the separation of duties.

Cardinality constraints can be applied to roles, sessions, and permissions. This type of cardinality may constraint the number of members that a role can have or limit the number of roles that a user can have active per session. Cardinality constraints may additionally impose a limit of sessions that a user can have active at the same time or the number of roles to which permissions can be assigned. Prerequisite roles dictates that a user can only be assigned to a particular role if it is already assigned to certain role(s).

RBAC3model combines RBAC1model with RBAC2to apply constraints to roles hierarchy.

For instance, in RBAC3, is possible to define that two or more roles cannot have a common

senior role or limit the number of parent or child roles that a specific role may have. The concept of prerequisite roles bound to the concept of hierarchical roles may dictate that a user can only be assigned to a high-level role if is already assigned to a low-level role in the hierarchy. As per the Figure 2.11c, a user can only be assigned to the role Director if it is already assigned to the subordinate Project Lead 1 role.

David F. Ferraiolo et al. [24] proposed a unified model for RBAC - The NIST RBAC model - based on Sandhu et al.’ framework [63] and prior RBAC models [28], [27], [31] and [56].

The main purpose of this model is to provide a standard that includes all the relevant features of the prior works in terms of RBAC Reference Model and RBAC Functional Specification. The reference model is aimed to define a common and consistent terminology, as well as set the scope of features and requirements of an RBAC system. The functional specification intends to define a set of requirements in terms of administrative operations and review functions, as well as a set of system-level functionalities in order to manage roles, user sessions, and access control decisions.

The NIST RBAC reference model is divided in a familiy of three reference models: Core RBAC, Hierarchical RBAC and Constrained RBAC.

Core RBAC is the base of RBAC model and includes a set of five entities - users, roles, objects, operations and permissions (see Figure 2.12). Objects are recognized by NIST in order to define the entities that users want to perform operation(s) on. Similar to prior works, user-role and permission-role relations is a many-to-many relation. Core RBAC supports reviewing the membership between users and roles (user-role assignment review), the permissions assigned to roles (permission-role assignment review), the roles activated in a session (session-role assignment review) and, finally, the sessions that are associated with a user (session-user assignment review).

(45)

Core RBAC also includes the concept of users’ sessions, which allow roles’ activation or deactivation at users’ discretion. Finally, this model also allows users to use permission of several roles simultaneously.

Figure 2.12: The NIST RBAC reference model. Users-Sessions is a one-to-many relationship and the other relations are many-to-many. Based on [24].

The Hierarchical RBAC recognizes role hierarchies according to the prior work of [27], [63], [50] and [55]. A hierarchy is a partial ordered set that defines a relation among roles, thereby a high-level role inherits all permissions of low-level roles that are connected to it, and low-level roles acquire the users assigned to their high-level roles.

The NIST model defines two types of role hierarchies:

• General Hierarchical RBAC: Allows an arbitrary partial order of role hierarchy. General role hierarchies support the concept of multiple inheritance, whereby a role may inherit permissions from two or more roles connected to it in a low-level position and a low-level role may inherit the users assigned to their high-level roles. An example of General Hierarchie is illustrated in Figure 2.11a.

• Limited Hierarchical RBAC: Impose restrictions on the tree structure of the role hierarchy such as tree (a role may have one or more roles connected to it in a high-level position but is restricted to only one role connected to it in a low-level position) or inverted tree. Example of tree and inverted tree are illustrated in Figure 2.11c and Figure 2.11b, respectively.

The Constrained RBAC model adds separation of duty relations to the RBAC model to enforce conflict of interest policies that prevents users from exceeding their authority in a computer system. The constraints are in the form of static and dynamic separations of duties.

• Static Separation of Duty (SSD) relations: In a role-based access control, conflict of interest may occur when users gain access to permissions associated with conflicting roles. In order to prevent such security violation, SSD relations intend to enforce