ACCESS CONTROL IN IAAS MULTI-CLOUD HETEROGENEOUS
ENVIRONMENTS
Federal University of Pernambuco posgraduacao@cin.ufpe.br www.cin.ufpe.br/~posgraduacao
RECIFE 2016
ACCESS CONTROL IN IAAS MULTI-CLOUD HETEROGENEOUS
ENVIRONMENTS
A Ph.D. Thesis presented to the Centre for Informatics of Federal University of Pernambuco in partial fulfillment of the requirements for the degree of Philosophy Doctor in Computer Science.
Advisor: Carlos André Guimarães Ferraz Co-Advisor: David Walter Chadwick
RECIFE 2016
Catalogação na fonte
Bibliotecária Monick Raquel Silvestre da S. Portes, CRB4-1217
S495a Sette, Ioram Schechtman
Access control in IaaS multi-cloud heterogeneous environments / Ioram Schechtman Sette. – 2016.
258 f.: il., fig., tab.
Orientador: Carlos André Guimarães Ferraz.
Tese (Doutorado) – Universidade Federal de Pernambuco. CIn, Ciência da Computação, Recife, 2016.
Inclui referências e apêndices.
1. Ciência da computação. 2. Computação em nuvem. I. Ferraz, Carlos André Guimarães (orientador). II. Título.
004 CDD (23. ed.) UFPE- MEI 2017-33
Access Control in IaaS Multi-Cloud Heterogeneous Environments
Tese apresentada ao programa de Pós-Graduação em Ciência da Computação da Universidade Federal de Pernambuco, como requisito parcial para a obtenção do título de Doutor em Ciência da Computação.
Aprovado em: 11/08/2016.
Prof. Carlos André Guimarães Ferraz Orientador do Trabalho de Tese
BANCA EXAMINADORA
Prof. Dr. Nelson Souto Rosa Centro de Informática / UFPE
Prof. Dr. Kelvin Lopes Dias Centro de Informática / UFPE
Prof. Dr. Vinicius Cardoso Garcia Centro de Informática / UFPE
Prof. Dr. Joni da Silva Fraga
Departamento de Automação e Sistemas/UFSC
Prof. Dr. Antonio Tadeu Gomes
my parents Sergio and Sonia, and to my wife Gabriela. All of them are always a source of inspiration and motivation to me in my personal, educational and academic life.
This PhD research would not be possible without the collaboration of these people and organisations, so I would like to acknowledge and highlight the importance of each of them.
Initially, I thank my supervisor Carlinhos for accepting me as a PhD student, giving valuable advises and contributions to this work and, more than that, offering his friendship.
I sincerely thank my co-supervisor David, who contributed with valuable advises and discussions, and also opened the doors of England to me and my family, being part of it during our stay there.
I’d also like to thank my examiners Nélson, Vinícius, Kelvin, Joni, and Tadeu for their comments and suggestions that enriched this thesis. Special thanks to Tadeu, for inspiring me in my research question.
An special acknowledgement to Carlos Eduardo da Silva, who introduced me to David and recommended me as a visitor PhD student at Kent University.
Thanks to my colleagues and friends Andreza Leite, Bruno Cartaxo, Deni Cavalcanti, Helaine Lins, Rivaldo Lira, and Thiago Vieira, who helped me to start an unfinished systematic mapping, but that helped a lot to immerse in the security aspects of cloud computing.
Many thanks to my wife Gabriela and my children Ilan and Iossef, for all their love, patience and comprehension when I could not be present, and also for sharing the special moments in England and being present when I needed them. Thanks to my parents Sergio and Sonia for always being an example to me and encouraging my studies. Thanks to my parents in law Jose and Lindinalva for supporting and taking care of us. Thanks to my brother Sergio, my sister Iara, and my nephews Noam and Ben for also being part of my family.
Thanks to Recife Center for Advanced Studies and Systems (CESAR) for allowing and encouraging employees to study while they work. Thanks to National Counsel of Technological and Scientific Development (CNPq), to the Science without Borders programme, and to Brazil government for funding my stay at the University of Kent at Canterbury (UKC) for a sandwich PhD. Thanks to Brazilian National Research and Educational Network (RNP) and National Institute of Science and Technology for Software Engineering (INES) for funding researches during my PhD time.
Thanks to all professors and colleagues of the Informatics Centre at Federal University of Pernambuco (UFPE) that helped me during this process.
And thanks to all not listed here but that also directly or indirectly contributed with this work.
fora da boniteza e da alegria. —PAULO FREIRE
Multiple Cloud Service Providers (CSPs) coexist nowadays offering their services competitively. To avoid vendor lock-in, users hire many services from an outsourced heterogeneous multi-cloud environ-ment. This way, data and system security usually depend on isolated mechanism existing in each provider. Access Control (AC) mechanisms are responsible for the authentication, identification and authorisation of users to resources. In the case of a multi-cloud environment, users often need to authenticate multiple times and also to define security policies for each CSP, which can possibly result in inconsistencies.
The objective of this thesis is to provide a homogeneous access experience for users of het-erogeneous multi-cloud services. Identity federations allow the Single Sign-On (SSO), i.e. users are identified and authenticated once by Identity Providers (IdPs) and gain access to trusted federated services. Nevertheless, authorisation federations or AC federations are not usual. Each cloud service uses to have its own AC mechanism, with their own policy definition languages.
This work defines a solution that provides homogeneous authentication and authorisation to multiple heterogeneous Infrastructure as a Service (IaaS) platforms. This is possible through Identity Federations and Authorisation Policy Federations (APFs). In this solution, security policies are centrally stored in a “Disjunctive Normal Form (DNF)” and are semantically defined in terms of an Ontology. Therefore, cloud tenants can create APFs and bind their different accounts to them. Thus, global authorisation rules, defined and managed by the APF, can be enforced on all federated member accounts, providing a homogeneous access experience.
A system prototype, composed of a central Policy Administration Point (PAP), called Federated Authorisation Policy Management Service (FAPManS), policy adaptors (translators) and a policy synchro-nisation mechanism, was implemented for OpenStack and Amazon Web Services (AWS) cloud platforms. An ontology was also created based on their access control technologies.
The “Level of Semantic Equivalence (LSE)” was defined as a metric that gives the percentage of policy rules that could be translated to the ontology terms. In the validation of this solution, authorisation policies based on examples publicly provided by OpenStack and AWS were converted to ontology-based global rules and vice-versa with LSE above 80%.
Keywords: Access Control. Authorisation Federation. Cloud Computing. Identity Federation. Infrastructure as a Service. Multi-Cloud Environments. Security Policies.
Múltiplos provedores de computação em nuvem convivem hoje ofertando seus serviços de forma competitiva. Para evitar dependência (o chamado vendor lock-in), usuários utilizam muitos serviços em ambiente terceirizado e heterogêneo multi-nuvens. Desta forma, a segurança de dados e sistemas depende normalmente de mecanismos existentes isoladamente em cada um dos provedores. Mecanismos de controle de acesso são responsáveis pela autenticação, identificação e autorização dos usuários aos recursos. No caso de ambiente multi-nuvens, usuários geralmente precisam se autenticar diversas vezes e definir políticas de segurança para cada um dos serviços, que possivelmente podem apresentar inconsistências.
O objetivo desta tese é proporcionar aos usuários de sistemas heterogêneos multi-nuvens uma experiência de acesso homogênea a estes serviços. Federações de identidade proporcionam o Single Sign-On (SSO), ou seja, os usuários são identificados e autenticados por provedores de identidade (IdPs) uma única vez e, através de protocolos como OpenID Connect, SAML ou ABFAB, recebem acesso a serviços federados com os quais possuem relação de confiança. No entanto, federações de autorização ou de políticas de controle de acesso não são comuns. Cada serviço de nuvem costuma ter seu próprio mecanismo de controle de acesso, com linguagens próprias de definição de políticas.
Este trabalho define uma solução que provê autenticação e autorização homogêneas a usuários de múltiplos serviços de computação em nuvem heterogêneos no modelo de Infraestrutura como Serviço (IaaS). Isso é possível através de federações de identidade e de políticas de autorização. Nesta solução, políticas de segurança são armazenadas de forma centralizada no padrão “DNF” com semântica definida em uma Ontologia. Portanto, clientes de nuvens podem criar “Federações de Políticas de Autorização (APFs)” e associar suas contas em cada provedor a estas federações. Desta forma, regras de autorização globais, definidas e gerenciadas pela APF, passam a valer em todas as contas que fazem parte da federação, garantindo uma experiência homogênea de acesso.
Um protótipo do sistema, composto de um Ponto de Administração de Políticas (PAP) centralizado e mecanismos de tradução e sincronismo de políticas, foi implementado para nuvens OpenStack e Amazon Web Services (AWS). Uma ontologia também foi definida baseada no controle de acesso destas tecnologias.
A métrica “nível de equivalência semântica (LSE)” foi definida para calcular o percentual de regras de uma política que pode ser traduzido para termos de uma ontologia. Na validação da solução, políticas de autorização baseadas em exemplos fornecidos por OpenStack e AWS foram convertidos para regras globais, baseadas na ontologia, e vice-versa, com nível de equivalência semântica superior a 80%.
Palavras-chave: Ambientes Multi-Nuvem. Computação em Nuvem. Controle de Acesso. Federação de Autorização. Federação de Identidade. Infraestrutura como Serviço. Políticas de Segurança.
1.1 Simplified view of the Solution’s Architecture. An APF admin manage a
com-mon policy. . . 32
1.2 Simplified view of the Solution’s Architecture. A tenant admin manage a local policy. . . 33
1.3 Simplified view of the Solution’s Architecture. A user accesses different Infrastructure as a Service (IaaS) Cloud Service Providers (CSPs) and receives homogeneous privileges. . . 34
2.1 Simplified eXtensible Access Control Mark-up Language (XACML) data-flow model . . . 43
2.2 Cloud interoperability models. . . 50
3.1 Eucalyptus high-level architecture. . . 63
3.2 OpenStack high-level architecture. . . 64
3.3 Federated OpenStack authentication flow. . . 65
3.4 Keystone local authentication flow. . . 68
3.5 Keystone Security Assertion Mark-up Language (SAML) Web Browser SSO profile authentication flow. . . 70
3.6 Keystone OpenID Connect basic client profile authentication flow. . . 71
3.7 Keystone OpenID Connect implicit client profile authentication flow. . . 71
3.8 Amount of bytes received by the client (a) and total time (b) measured on the experiments using SAML Web SSO profile, OpenID Connect basic profile and OpenID Connect implicit profile. . . 75
3.9 ABFAB Architecture. . . 76
3.10 OpenStack flow for integration with identity federations using new versions of Keystone. . . 77
3.11 Application Bridging for Federated Access Beyond web (ABFAB) architecture instanced to OpenStack. . . 79
3.12 Screen to create new Virtual Organisations (VOs) and VO roles. . . 81
3.13 Screen with the list of assigned VO role. . . 81
3.14 Screen to join a VO role. . . 82
3.15 Administration screen for a VO role. . . 82
3.16 Example snippet from ABFAB’s Identity Provider (IdP) configuration on FreeRa-dius. . . 84
3.17 Example radsec.conf file at the OpenStack server. . . 84
3.21 Credential Managers on Operating Systems (OSs). . . 88
3.22 Screens after Log In on Windows/IE. . . 88
4.1 Authorisation Policy Management Flow (Offline). . . 92
4.2 Access Control Flow (Online). . . 93
4.3 Disjunctive Normal Form (DNF) policy tree . . . 95
4.4 Database Model to store DNF policies . . . 97
4.5 Database Model to store DNF policies supporting Attribute Hierarchies . . . . 100
4.6 Proposed architecture for Authorisation Policy Federations (APFs). . . 102
4.7 An Overview of the Architecture for APFs . . . 103
4.8 APF creation sequence diagram . . . 105
4.9 APF formation sequence diagram . . . 106
4.10 Leave APF sequence diagram . . . 108
4.11 Managing APF through Federated Authorisation Policy Management Service (FAPManS) sequence diagram . . . 109
4.12 FAPManS Login screen . . . 117
4.13 FAPManS Home screen . . . 117
4.14 FAPManS Policy management screen . . . 119
4.15 Example of an explicit deny scenario . . . 122
4.16 Database Model to store adaptors mapping rules . . . 125
4.17 Adaptor’s flow for attribute semantic translation . . . 130
4.18 Adaptor’s flow for operator semantic translation. . . 131
4.19 Adaptor’s flow for translating values . . . 133
5.1 Ontology Dynamics: Core and Extension Ontologies . . . 138
5.2 High level components of the ontology. . . 139
5.3 Detail of entity classes. . . 141
5.4 Detail of action class. . . 142
5.5 Detail of attribute subclasses. . . 143
5.6 Attributes of entities. . . 144
5.7 Attributes of resources. . . 145
5.8 Attributes of users. . . 146
5.9 Attributes of IdPs . . . 147
5.10 Attributes of actions. . . 148
5.11 Attributes of the environment. . . 148
5.12 Detail of operator subclasses. . . 149
5.13 Backus–Naur Form (BNF) grammar for values. . . 151
6.3 Attribute hierarchy example. . . 158
6.4 Example search criteria. . . 160
6.5 Adaptors object model. . . 164
6.6 First lines of the JSON policy file of OpenStack Keystone service. . . 166
6.7 Small example of a Keystone policy. . . 168
6.8 Example of a Keystone policy in DNF before semantic translation. . . 170
6.9 Example of a Keystone policy in DNF after semantic translation (part 1/2). . . . 171
6.10 Example of a Keystone policy in DNF after semantic translation (part 2/2). . . . 172
6.11 AWS user-based policy. . . 173
6.12 AWS resource-based policy. . . 173
6.13 Example AWS condition. . . 175
6.14 "Doughnut" Venn diagram representing statements with allow and deny effects 176 6.15 Example of AWS condition block. . . 182
6.16 Example of ontology defined in Web Ontology Language (OWL). . . 184
6.17 OntoGraf plugin for Protégé . . . 186
7.1 The APF solution. . . 189
7.2 Policy translation validation scenarios. . . 195
7.3 Validation steps. . . 202
7.4 Keystone rules. . . 205
7.5 Nova rules. . . 205
7.6 AWS example policy. . . 207
7.7 Condition in the global DNF format. . . 209
7.8 Condition in the intermediary OpenStack DNF format. . . 209
7.9 Condition in the global DNF format. . . 211
7.10 Condition in the intermediary AWS DNF format. . . 211
7.11 Converted AWS policy. . . 212
1.1 Technical Challenges . . . 30
2.1 Comparison of OpenStack and AWS authorisation mechanisms and policies . . 46
2.2 Similarities and differences on the state of the art solutions. . . 58
3.1 Summary of Comparison between SAML and OpenID Connect protocols (SETTE; FERRAZ,2014a). . . 67
3.2 Time and amount of bytes received by the client on 300 accesses to Swift service for listing files on an empty folder using SAML and OpenID Connect protocols. 74 4.1 Definition of the APF policy model format . . . 99
4.2 Operations on Policies . . . 110
4.3 Operations on And Rules . . . 112
4.4 Search on Policies . . . 113
4.5 Operations on Attribute Hierarchies . . . 115
4.6 List Values for an Attribute . . . 116
4.7 Mapping Rules. . . 127
4.8 Operations of Adaptors . . . 127
4.9 Definition of Federation Model . . . 135
6.1 Operations on Policies . . . 157
6.2 Operations on And Rules . . . 159
6.3 Search Operation . . . 160
6.4 Operations on Attributes and Hierarchies . . . 162
6.5 Operations of Adaptors . . . 165
6.6 Main Attributes in OpenStack Policies . . . 166
6.7 Main Values in OpenStack Policies . . . 167
6.8 Main Attributes in AWS Condition block . . . 183
6.9 Main Operators in AWS Condition block . . . 185
6.10 Main Values in AWS Policies . . . 187
7.1 OpenStack Syntax Mapping Results. . . 203
7.2 Scenario 1 Mapping Results. . . 206
7.3 Scenario 2 Mapping Results. . . 208
7.4 Scenario 3 Mapping Results. . . 210
7.5 Scenario 4 Mapping Results. . . 213
B.3 Translation table for Keystone actions. . . 254
B.4 Translation table for other OpenStack values. . . 255
B.5 Translation table for AWS attributes. . . 256
B.6 Translation table for AWS operators. . . 256
B.7 Translation table for AWS values (part 1/3). . . 257
B.8 Translation table for AWS values (part 2/3). . . 258
AAA Authentication, Authorisation and Accounting
AaaS Authorisation as a Service
ABAC Attribute-Based Access Control
ABFAB Application Bridging for Federated Access Beyond web
AC Access Control
ACM Access Control Module
ACL Access Control List
API Application Programming Interface
APF Authorisation Policy Federation
ARN Amazon Resource Name
AWS Amazon Web Services
BNF Backus–Naur Form
CA Certificate Authority
CESAR Recife Center for Advanced Studies and Systems
CI Confidence Interval
CIM Common Information Model
CIn Center for Informatics
CLASSe Cloud-ABFAB Federation Services in eduroam
CLI Command Line Interface
CNF Conjunctive Normal Form
CNPq National Counsel of Technological and Scientific Development
CPU Central Processor Unit
DAC Discretionary Access Control
DACI Dynamic Access Control Infrastructure
DBMS Data Base Management System
DIMAP Department for Informatics and Applied Mathematics
DNF Disjunctive Normal Form
DMTF Distributed Management Task Force
EAP Extensible Authentication Protocol
EC2 Elastic Compute Cloud
ER Entity-Relationship
FAPManS Federated Authorisation Policy Management Service
GIDLab Laboratory of the Identity Management Group
GMT Greenwich Meridian Time
GS2 Generic Security Service
GSS Generic Security Service
GT-CNC Working Group for Scientific Cloud Computing
GUI Graphical User Interface
HP Hewlett Packard
HRBAC Hierarchical Role-Based Access Control
HTTP HyperText Transfer Protocol
HTTPS Hyper Text Transfer Protocol Secure
IaaS Infrastructure as a Service
IAM Identity and Access Management
IBM International Business Machines
IETF Internet Engineering Task Force
INES National Institute of Science and Technology for Software Engineering
IP Internet Protocol
ISP Internet Service Provider
JSON JavaScript Object Notation
JWE JSON Web Encryption
JWS JSON Web Signature
LDAP Lightweight Directory Access Protocol
LoA Level of Assurance
LSE Level of Semantic Equivalence
MAC Mandatory Access Control
MIT Massachusetts Institute of Technology
MTAS Multi-Tenancy Authorisation System
OASIS Organization for the Advancement of Structured Information Standards
OIDC OpenID Connect
OO Object Oriented
OS Operating System
OTP One-Time Password
OWL Web Ontology Language
PaaS Platform as a Service
PAP Policy Administration Point
PCIM Policy Core Information Model
PDP Policy Decision Point
PFP Policy Federation Provider
PIN Personal Identification Number
PIP Policy Information Point
PKI Public Key Infrastructure
PoP-MA Point-of-Presence in Maranhão
PRP Policy Retrieval Point
PyEDA Python Electronic Design Automation
QoS Quality of Service
RADIUS Remote Authentication Dial In User Service
RAM Random Access Memory
RBAC Role-Based Access Control
RegEx Regular Expression
REST Representational State Transfer
RNP Brazilian National Research and Educational Network
RP Relying Party
S3 Simple Storage Service
SaaS Software as a Service
SAML Security Assertion Mark-up Language
SLA Service Level Agreement
SMTP Simple Mail Transfer Protocol
SOA Service-Oriented Architecture
SOAP Simple Object Access Protocol
SP Service Provider
STS Security Token Service
UCON Usage Control
UFPE Federal University of Pernambuco
UFRN Federal University of Rio Grande do Norte
UK United Kingdom
UKC University of Kent at Canterbury
URL Universal Resource Location
URN Universal Resource Name
VHD Virtual Hard Disk
VNI Virtual Network Interface
VM Virtual Machine
VO Virtual Organisation
VRM Virtual Resource Manager
WS Web Service
XACML eXtensible Access Control Mark-up Language
1 Introduction 23
1.1 Problem Statement . . . 25
1.2 Goals and Requirements . . . 26
1.3 Technical Challenges . . . 28
1.4 Proposed Solution . . . 31
1.5 Organisation of the Thesis . . . 35
2 Background and State of the Art 37 2.1 Authentication and Identification . . . 37
2.1.1 Integration of IaaS platforms with Identity Federations . . . 39
2.2 Authorisation, Access Control and Security Policies . . . 40
2.2.1 Access Control in OpenStack . . . 43
2.2.2 Access Control in AWS . . . 44
2.2.3 Comparison of OpenStack and AWS authorisation mechanisms and policies . . . 46
2.3 Interconnected Cloud Environments . . . 48
2.4 Access Control on Multi-Cloud Environment . . . 49
2.4.1 Access Control on the Broker Model . . . 51
2.4.2 Centralised Authorisation for Multiple Clouds . . . 52
2.4.3 Distributed Authorisation for Multiple Clouds . . . 54
2.5 Ontology . . . 56
2.6 Related Works in Summary . . . 58
2.7 Conclusion Remarks . . . 58
3 Integrating an IaaS platform to Identity Federations 60 3.1 Integrating Cloud Platforms to Identity Federations . . . 62
3.1.1 Authentication and Authorisation on Open IaaS Platforms . . . 63
3.1.2 Federated OpenStack . . . 64
3.1.3 SAML and OpenID Connect . . . 66
3.1.3.1 Comparisons between SAML and OpenID Connect . . . 66
3.1.3.2 Authentication Flows . . . 68
3.1.4 Experiments . . . 69
3.1.4.1 Environment . . . 69
3.1.4.2 Test Scenarios . . . 72
3.2.2 Integrating OpenStack with identity federations through Apache . . . . 77
3.2.3 Integrating OpenStack to ABFAB IdPs . . . 79
3.2.4 Virtual Organisations and OpenStack . . . 80
3.2.5 Implementation . . . 83
3.2.5.1 FreeRadius configuration . . . 83
3.2.5.2 OpenStack configuration to use ABFAB protocol . . . 83
3.2.5.3 ABFAB Authentication . . . 86
3.3 Concluding Remarks . . . 89
4 Federated Authorisation Policy in a Heterogeneous Multi-Cloud Environment 90 4.1 Authorisation Policy Federation . . . 90
4.2 DNF: The Common Format for Federated Policies . . . 94
4.2.1 A database model to store DNF policies . . . 96
4.2.2 Comparison between DNF and XACML formats . . . 98
4.2.3 Attribute Hierarchies . . . 99
4.3 Architecture for Authorisation Policy Federations . . . 101
4.3.1 Architecture Overview . . . 101
4.3.2 Use Cases . . . 104
4.3.2.1 Creation of an Authorisation Policy Federation . . . 105
4.3.2.2 Formation of an Authorisation Policy Federation . . . 106
4.3.2.3 Leaving an APF . . . 107
4.3.2.4 Managing policies with FAPManS . . . 107
4.4 Federated Authorisation Policy Management Service . . . 108
4.4.1 Federated Authorisation Policy Management Service API . . . 110
4.4.1.1 Policy API . . . 110
4.4.1.2 Rule API . . . 112
4.4.1.3 Search API . . . 113
4.4.1.4 Attribute and Attribute Hierarchy API . . . 114
4.4.1.5 Values API . . . 115
4.4.2 Federated Authorisation Policy Management Service GUI . . . 116
4.4.2.1 Login Screen . . . 116
4.4.2.2 Home Screen . . . 116
4.4.2.3 Policy Management Screen . . . 118
4.5 Cloud Authorisation Policy Adaptors . . . 120
4.5.1 Syntax Mapping . . . 121
4.5.1.1 Not Conditions . . . 121
4.5.2.2 Semantic Mapping Application Programming Interface (API) 127 4.5.2.3 Semantic Mapping of Attributes . . . 127 4.5.2.4 Semantic Mapping of Operators . . . 131 4.5.2.5 Semantic Mapping of Values . . . 132 4.6 Concluding Remarks . . . 134
5 An Ontology for Access Control on IaaS clouds 136
5.1 Definition Strategies . . . 136 5.1.1 Minimal and Maximum Set Approaches . . . 137 5.1.2 Ontology Dynamics . . . 137 5.2 High Level Elements of the Ontology . . . 139 5.3 Elements of an IaaS Access Control Policy . . . 140 5.4 Elements of an IaaS Condition . . . 142 5.4.1 Attributes . . . 142 5.4.2 Operators . . . 149 5.4.3 Values . . . 149 5.5 Concluding Remarks . . . 152
6 Implementation 153
6.1 The APF solution for IaaS Clouds . . . 153 6.1.1 FAPManS API . . . 154 6.1.1.1 Policy API . . . 154 6.1.1.2 Rule API . . . 158 6.1.1.3 Search API . . . 160 6.1.1.4 Attribute Hierarchy API . . . 161 6.1.2 Adaptors . . . 161 6.1.2.1 Adaptor API . . . 163 6.1.2.2 Adaptor for OpenStack clouds . . . 165 6.1.2.3 Adaptor for AWS . . . 169 6.2 Implementation of the Ontology . . . 182 6.2.1 Ontology model in OWL/Protégé . . . 183 6.3 Concluding Remarks . . . 185 7 Validation 188 7.1 Validation Method . . . 188 7.1.1 Goals Recapitulation . . . 188 7.1.2 Validation Metrics . . . 192 7.1.3 Validation Scenarios . . . 194
7.2.1.1 OpenStack Attribute Mapping . . . 196 7.2.1.2 OpenStack Operator Mapping . . . 198 7.2.1.3 OpenStack Value Mapping . . . 198 7.2.1.4 AWS Attribute Mapping . . . 200 7.2.1.5 AWS Operator Mapping . . . 201 7.2.1.6 AWS Value Mapping . . . 201 7.2.2 Validation Results . . . 201
7.2.2.1 Scenario 1: Translating OpenStack policies to DNF and On-tology . . . 202 7.2.2.2 Scenario 2: Translating AWS policies to DNF and Ontology . 206 7.2.2.3 Scenario 3: Translating Global policies to OpenStack . . . . 208 7.2.2.4 Scenario 4: Translating Global policies to AWS . . . 210 7.2.2.5 Discussion . . . 213 7.3 Limitations . . . 214 7.4 Concluding Remarks . . . 215
8 Conclusion 217
8.1 Major Contributions . . . 219 8.2 Limitations and Future Works . . . 220
References 221
Appendices 226
A An Ontology for Access Control of Heterogeneous IaaS Clouds 227
1
Introduction
Cloud computing has made the long-held dream of computing as a utility true. It allows software applications, computing platforms and computing infrastructures to be delivered as a service. Companies, especially small ones such as start-ups, do not need to invest huge amounts of money on infrastructure that goes underused most of the time. They can now hire virtual instances and dynamically increase and decrease their capacity according to their demand, paying only for the used resources (ARMBRUST et al.,2009).
Nowadays, multiple Cloud Service Providers (CSPs) offer services to their clients in a competitive and/or collaborative way. Tenants, as customers of cloud systems are called, want to enjoy the best offers of each provider, and also do not want to be tied to a unique supplier (a problem known as “vendor lock-in”). Besides such reasons,TOOSI; CALHEIROS; BUYYA
(2014) complement the list with other benefits such as the increase of availability of their services and resources, reduction of the network latency by storing resources close to the users, and meet laws and regulations that enforce data to be stored in a region or country. According to this survey, a CSP can communicate with other CSPs in many ways: in a Cloud Federation, a CSP can hire resources from the others to expand its capability and to meet the Service Level Agreements (SLAs) determined by the users; cloud services can also be offered to users through a broker, in a model which users are not aware that they are accessing multiple clouds, since the middleware layer abstracts the requests to them in a homogeneous way; on the other hand, in a Multi-Cloud environment, users have the burden to manage their accounts on distinct clouds using different technologies and platforms.
However, despite the success of cloud computing, a key barrier for the adoption of this technology is security. A major security concern is that tenants’ private and sensitive data, which were stored inside their domains, protected by their policies and firewall in a non-cloud model, are now stored in an outsourced infrastructure, which is shared with other customers, possibly competitors. According toALMUTAIRI et al.(2012), multi-tenancy and virtualisation features pose unique security and access control challenges due to sharing of physical resources among potential untrusted tenants.
biometry, physical devices (e.g. smart cards), and other mechanisms for this purpose. These mechanisms can also be combined to increase security, like in the multi-factor authentication. Authorisation specifies what a user is allowed to do. The authorisation rules, usually stored on a security policy, say who is allowed to access which resources and what they are allowed to do with them (ROUNTREE,2012).
The most basic authentication on cloud systems, which is also the most usual, is per-formed by matching user names and passwords. The boost on the offer of web services caused by cloud computing resulted in a massive amount of passwords that the users have to memorize. Therefore, people usually reuse their passwords on multiple services, or use weak easily remem-bered passwords that could be also easily broken. Using one password in multiple services is a bad practice, since if one of these services have the password leaked, this password is often tested on the other services, which will also be compromised. Unfortunately, password leaks often happen at many small, medium and especially big organisations including Apple, Sony, Ebay, AOL, NHS etc1. In this context, password management systems arise to help users to create strong passwords and to manage the passwords for different services. These systems store passwords encrypted and are available in multiple platforms. However, they require discipline and effort from the users to use them, and were adopted by a small niche of users.
A more sophisticated mechanism called Identity Federation (ROUNTREE,2012) can mitigate most of these problems. In this model, the authentication is outsourced to one or multiple Identity Providers (IdPs) which establish a trust relationship with the CSP. Identity federation protocols, such as Security Assertion Mark-up Language (SAML) (SAML SPECIFI-CATIONS,2005)2, OpenID Connect3and Application Bridging for Federated Access Beyond web (ABFAB) (HARTMAN; HOWLETT,2013a) (HARTMAN; HOWLETT,2013b) (WINTER; SALOWEY,2013), are responsible for the communication among users, Service Providers (SPs) and IdPs. Identity federations also bring the so-called Single Sign-On (SSO) facility (PARKER,
1995), which allows users to access multiple services by performing a single authentication. Despite a single password can be used for accessing multiple services, this risk is mitigated due to the fact that the IdPs are specialized authentication services with a major concern on security and which use appropriate protocols, processes and authentication methods. Since there are significantly less IdPs than SPs, users can use strong passwords since there are only a few to memorize. The IdP can also require strong authentication methods such as digital certificates, One-Time Password (OTP) tokens, and biometry. Big companies on the Internet provide IdP services, for instance Google, Facebook and Twitter. They can attest the user’s e-mail address or other attributes that were self-asserted by the user. Universities can also provide an IdP to authenticate their students, staff and professors, and attest their roles in the organisation. In this model, virtual stores, which act like SPs, can give discounts for students that are authenticated
1http://www.informationisbeautiful.net/visualizations/worlds-biggest-data-breaches-hacks/ 2https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security
through the university’s IdP4.
Cloud systems use a diversity of authorisation models, such as Role-Based Access Con-trol (RBAC) (FERRAIOLO; KUHN,1992) and Attribute-Based Access Control (ABAC) (YUAN; TONG,2005), which often use proprietary implementations and different security policies’ lan-guages and formats. eXtensible Access Control Mark-up Language (XACML) (PARDUCCI,
2005) is proposed by the OASIS consortium5to be a standard for security policies, but it has not been largely adopted because of its low performance and high complexity. The lack of authorisation standards make authorisation policies incompatible and difficult to be maintained by clients of multiple heterogeneous cloud services. Users of multiple cloud services must separately define and maintain their security policies to protect their information on each of these systems. It is a burden for the system administrators of the clients to keep these rules synchronized on all CSPs and to have a homogeneous behaviour at all of them.
This thesis intends to solve the problem of lack of homogeneity on the authentication and authorisation of users on multiple heterogeneous clouds. The proposed solution focus on Infrastructure as a Service (IaaS) clouds, but it can be generalised to other types of clouds like the Platform as a Service (PaaS) and the Software as a Service (SaaS) ones. Most current cloud providers have their own proprietary authentication and authorisation systems, containing different identification mechanisms and access control rules and models. The integration of identity federation and IaaS cloud services is also still in its early stages.
In the proposed solution, users may perform a single authentication to access multiple cloud services. Cloud tenants may also define a single security policy which is valid and enforced for all of its accounts on IaaS systems, providing a homogeneous access and management experience. These security rules may be shared with other tenants, since they trust each other, in order to provide homogeneous access to their users, making collaboration easier.
1.1
Problem Statement
Given the multitude of IaaS cloud systems and the diversity of technologies used by them, clients of multiple systems have the burden to manage their accounts in a complex heterogeneous environment. The administrators of these tenants have to manage the user’s identity credentials and authorisation policies for each cloud system individually. These credentials can be stored in different formats and systems, and policies can be declared in different languages and be compliant with different access control models.
Tenant users also suffer with the heterogeneity of authentication and authorisation mechanisms. A user must provide different credentials and may be ruled by different policies, which can give him different access permissions depending on the cloud system he is accessing. For instance, a user may be allowed to create a certain Virtual Machine (VM) or store a file in a
4https://www.myunidays.com 5https://www.oasis-open.org
given directory in one cloud system, but be denied to perform the same operation in another one. Maybe because he forgot his password in one of these, or maybe because there is a divergence in the policy rules.
The problem addressed in this thesis is stated in the following research question: “how can we provide homogeneous authentication and authorisation on heterogeneous IaaS multi-cloud environments?”
It can be split into two sub questions:
1) How to allow users to perform a SSO authentication to access multiple heterogeneous IaaS clouds, given the multitude of identity federation protocols in existence?
2) How to provide a single homogeneous authorisation policy that applies equally for users across multiple IaaS clouds?
Therefore, this thesis aims to provide a solution to mitigate the heterogeneity problems related to the access control on accounts in heterogeneous IaaS CSPs, in the perspective of tenant’s end users and security administrators. This includes providing a homogeneous authen-tication and authorisation experience for users of one tenant with accounts on providers using different cloud technologies, as well as for users of multiple tenants who want to form a Virtual Organisation (VO) by sharing authorisation rules on their cloud accounts.
1.2
Goals and Requirements
The main goal of the thesis is to enable homogeneous authentication and authorisation on accounts of multiple heterogeneous IaaS clouds. This goal can be achieved by meeting the following specific goals.
1) Support SSO and Identity Federations using multiple protocols
The SSO capability allows users to access multiple services from different IaaS cloud providers with a single authentication on its preferred IdP, using its preferred identity federation protocol.
Since each user use a small set of IdPs to authenticate, they have few passwords to memorise and therefore can use strong ones, which are difficult to break. Besides passwords, IdPs can use stronger authentication methods such as digital certificates, OTPs, biometry, and also combine them and provide multi-factor authentication which is even more secure. Given the multitude of identity federation protocols, for instance OpenID Connect, SAML and ABFAB, as more protocols are supported by a CSP, a greater number of users are able to use this form of authentication to access cloud services.
After the user is authenticated, the IdP provides a set of attributes about the user in its response to the CSPs. Each CSP will use these user’s attributes on its authorisation
decision. Therefore, it can be concluded that integrating with identity federations is essential for an homogeneous authentication experience and also contributes to a homogeneous authorisation, since the same set of attributes is provided for all CSPs.
2) Provide equivalent authorisation policies on accounts of multiple heterogeneous IaaS clouds
Besides assuring that the same set of attributes are used, it is also essential for a homogeneous authorisation that the security rules are also equivalent on each heterogeneous CSP account.
There are multiple ways to provide an equivalent authorisation policy on heteroge-neous CSPs. For instance, in a centralised authorisation approach, a single policy can be used to evaluate access requests on different cloud platforms that integrate to a central Policy Decision Point (PDP). On the other hand, distributed approaches are also possible, and each CSP can use its own PDP, which can be homogeneous or heterogeneous. A solution to provide equivalent authorisation policies on multiple IaaS accounts must consider the advantages and disadvantages of each approach, and also meet the following requirements.
a) Provide simple policy manageability
Security administrators must be able to define a single common autho-risation policy that can be used in multiple heterogeneous IaaS CSPs. Managing multiple policies in different languages is a complex task that must be avoided. This policy must preferably be available for management in a central Policy Administration Point (PAP), which provides an intuitive and simple interface. Dealing with multiple and complex interfaces also increase the complexity of management.
b) Be scalable and available
The authorisation process must be scalable. The evaluation of the autho-risation of an access on a system can be performed multiple times for a single access, for instance, considering a Usage Control (UCON) engine. This is different from authentication, which usually takes place once for a set of accesses. Therefore, the performance of authorisation decisions must not decrease when new cloud accounts share a common policy. The authorisation process must also not be a unique point of failure. The IaaS CSPs must be available and must not depend on any external component of the solution to perform authorisation.
c) Be easy for adoption
The proposed solution must require minimal intervention on existing CSPs to facilitate its adoption. For instance, the replacement of their
authori-sation engines is not desirable, as well as forcing them to be compatible with a policy language.
d) Provide quick policy synchronisation
The solution must provide an efficient synchronisation mechanism to quickly update the policies of all cloud accounts when the common policy is modified. The acceptable synchronisation time will depend on the criticality of the systems, and may be adjusted accordingly.
1.3
Technical Challenges
Enabling a homogeneous authentication and authorisation experience on multiple het-erogeneous systems is a complex problem to be solved. This section discusses the technical challenges to achieve this goal.
Regarding authentication, Identity Federations allow other systems, for instance CSPs, to outsource the authentication of their users to trusted specialized services, the IdPs. Since the IdPs are specialized, they can use sophisticated and secure methods, for instance, combining multiple factors of authentication. Besides the management of users’ credentials, the federated authentication also let the users access multiple cloud services in heterogeneous providers with a single authentication, through the SSO mechanism. And, more than just authentication, the Identity Federations also perform part of the authorisation process, since it issues an assertion containing user’s attributes such as name, date of birth, credit card information (if it is a bank), e-mail address (if it is an e-mail service), student’s id (if it is an academic institution), user roles (in a certain context) etc. These attributes on the subject can be used in the authorisation process of multiple services that trust on the issuer. Therefore, integrating IaaS platforms to Identity Federations will provide homogeneous authentication experience to users.
Cloud providers and technologies are starting to support integration with Identity Federa-tions. The Amazon Web Services (AWS) cloud provider6supports the integration with Identity Federation through the SAML and OpenID Connect protocols7. The OpenStack cloud platform8 also officially supports Identity Federations from its version Kilo9 through multiple identity protocols that are supported the Apache HTTPd Server, used as a front end, such as SAML, OpenID Connect and ABFAB.
However, besides the integration of IaaS cloud technologies with Identity Federation is in its early stages, it is not easy. One issue to be addressed regarding this integration is that IaaS cloud administrators often use Command Line Interface (CLI) tools, which are not straight forwardly supported by Identity Federation protocols designed for web applications. Another
6https://aws.amazon.com
7http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html 8https://www.openstack.org
problem is that the IdPs may issue identity attributes which are context dependable and cannot be directly understandable by the local cloud account. For instance, the values for the attribute “role” may vary according to the context (industry, academy, economy etc.). A proper mapping mechanism may be used for solving this problem. Also, because they are still in their early stages, some protocols and technologies are not simple to be configured and deployed. For instance, the set up for an identity federation using the ABFAB protocol requires complex and advanced configurations on multiple services and the installation of specific libraries and modules on the IdP, SP and client sides.
Regarding authorisation, cloud systems have different access control mechanisms and use policies written in different languages and formats. XACML was designed to be a standard for policies and Access Control (AC), but it was not massively adopted due to its complexity. Instead, systems, including the cloud platforms, usually implement their own authorisation mechanisms with proprietary policy languages and formats. AWS developed a proprietary ABAC10 and a policy language based on JavaScript Object Notation (JSON). In the same way, OpenStack implements RBAC on each of its modules. A proprietary policy format11, also based on JSON, is used by most of its modules, with the exception of the storage module, called Swift, which implements a different policy mechanism based on Access Control List (ACL) to control the read and write permissions on directories and files12. This heterogeneity of policy mechanisms and languages on existing cloud platforms makes the task to provide homogeneous access for users difficult to be achieved.
There are also no mature approach for homogeneous authentication corresponding to the Identity Federation. Some researches on the area of multi-cloud systems point to two main authorisation approaches: centralised and distributed. In the centralised approach, known as Authorisation as a Service (AaaS) (TANG; SANDHU; LI,2013), the cloud platforms forward the authorisation requests to external authorisation services. Similarly to the identity providers, these authorisation services are responsible to outsource the management of authorisation rules and of the authorisation decision engines, acting as both a central PAP and a central PDP, respectively. On the other hand, on the distributed approach (ALMUTAIRI et al.,2012), the authorisation management and decision engines are distributed and performed locally on each CSP. Distributed approaches vary from the exchange of the authorisation policies among the CSPs to the forward of the authorisation requests to the AC engine with the proper rule or policy.
The centralised authorisation approach brings some points of concern. Authorisation requests happen multiple times in a user’s session, one for each action it executes, differently from the identity requests that take place once at the beginning of the session. The authorisation decision can even occur multiple times on a single access in the case of UCON engines. Polling an external authorisation service, sited in a distant node of the network with high latency and/or
10http://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html 11http://docs.openstack.org/kilo/config-reference/content/policy-json-file.html 12http://docs.openstack.org/developer/swift/overview_auth.html
narrow bandwidth may impact on the system overall performance. Despite that, a central PDP may be a unique point of failure, which can stop all the cloud systems if it is down or in bad health.
The approaches based on distributed authorisation that have been found in the literature also have points of improvements. Multiple distributed PAPs can make policy management difficult if the security administrators have to access multiple systems to set them up. Besides that, all studied researches propose a homogeneous policy language and the use of compatible PDPs on each CSP (NGO et al.,2012). Forcing heterogeneous clouds to be compatible with homogeneous policies may be an impact to the adoption of the solution.
Using a homogeneous policy with a well defined syntax and semantic to represent security policies on clouds is a common sense on most of the studied approaches. This brings a problem of how to represent the common elements on cloud systems like subjects, actions and resources. For instance, VMs with Virtual Hard Disks (VHDs) and Virtual Network Interfaces (VNIs), files, directories, users and groups are elements that can be usually found in most IaaS technologies. Defining a complete set of global terms that can represent each of these concepts and rules that can map these terms to their local syntaxes is an important task for building homogeneous policies.
Nevertheless, there may also be some elements that are very specific to some contexts and hard to be mapped from one technology to another. For instance, the concept of a cloud “tenant” can be mapped to the CSP “account” on the AWS cloud. This same concept does not have a clear representation on the OpenStack platform. There are the concepts of “domain”, which group users, and “project”, which group resources. However, these concepts are recursive and a project can contain a “domain”, and a “domain” can contain a “project”. Therefore, the mapping of abstract elements, such as a cloud “tenant”, into specific ones can be a difficult task.
In summary, the major technical challenges of this thesis are shown in table 1.1.
Table 1.1: Technical Challenges
Challenge Description
Homogeneous user identification Each cloud system must uniquely identify the users in a uniform way.
Identity Attribute Mapping User attributes provided by IdPs must be mapped onto local attributes used in cloud systems.
Homogeneous authorisation Each cloud system must come to an equivalent autho-risation decision for the same access requests.
Homogeneous policy syntax A global policy must be defined and enforced on het-erogeneous cloud systems.
Homogeneous policy semantics The global policy must be defined using global terms that can be equally understood by the heterogeneous clouds.
1.4
Proposed Solution
The solution proposed in this thesis intends to achieve the goals and meet the requirements defined in Section 1.2. In other words, it allows users to authenticate on trusted IdPs and gain equivalent access privileges on tenant accounts of multiple heterogeneous IaaS clouds.
This solution consists of a distributed authorisation approach, using the heterogeneous PDPs provided by the CSP, and a centralised policy management, using a single PAP. This central PAP allows security administrators to create and manage common homogeneous policies that can be enforced across multiple heterogeneous cloud accounts.
Homogeneous access privileges are ensured through an abstract authorisation policy. A policy language is defined to support a common syntax and represent the common semantics of IaaS cloud elements. Each cloud system is able to interpret and enforce this policy in a homogeneous way. The term Authorisation Policy Federation (APF) is used to represent a group of tenant accounts that share a common authorisation policy.
An APF is composed of a unique authorisation policy defined in a global language that can be translated to and from multiple policy languages used in different cloud technologies. Members of an APF can be one or more tenants of federated heterogeneous cloud providers that want to enforce such globally defined authorisation policy on their accounts. When a cloud tenant creates a new APF or joins an existing one, the authorisation policy in his account must be compliant with the APF, i.e. the rules in the common policy must be enforced in his account.
Tenant administrators are also able to create local rules, valid only under the scope of their local accounts. Nevertheless, these rules must never conflict with the common federated ones, i.e. they can not override the decision of any rule from the common policy. Like in the federation political entity, the APF members are autonomous but must obey the global federal rules, which is the equivalent to the constitution.
The architecture of the proposed solution is depicted in Figures 1.1, 1.2 and 1.3. These images present a scenario with two clouds, using different technologies. Two tenant accounts, one on each cloud, join an APF in order to share a common policy. The main components of the solution are highlighted in thick borders and bold text: a global PAP, a policy adaptor and an APF agent. Figure 1.1 presents the common policy management flow, Figure 1.2 presents the local tenant policy management flow, and Figure 1.3 present the authorisation flow, in which a user receives similar privileges on different IaaS CSPs.
The definition and management of the common policy is responsibility of the APF administrators. Figure 1.1 presents this flow, indicated in cardinal numbers.
1) The APF administrators authenticate on a trusted IdP in order to gain access to the APF policy.
2) A centralised global PAP called Federated Authorisation Policy Management Service (FAPManS) provides a management user interface (see the proposal of
Figure 1.1: Simplified view of the Solution’s Architecture. An APF admin manage a common policy.
a Graphical User Interface (GUI) in Chapter 4) and an Application Programming Interface (API) for these administrators.
3) When a policy is created or modified, a synchronisation mechanism will ensure that all accounts will quickly update their local policies to be compliant with the new rules. The APF Agent runs inside each APF member account and is responsible for the policy synchronism.
4) The Policy Adaptor is a multi-tenant service provided by the CSPs that is responsible to translate the policy defined in the common abstract policy language to a tenant-scoped and cloud technology specific policy, and vice-versa.
5) The APF agent is responsible to merge the global and local policies and store the result on the local policy engines.
As previously stated, tenant security administrators may manage local policies since they do not conflict with the federated ones. Figure 1.2 presents the local policy management flow, indicated in Roman numbers.
I) The tenant administrator must authenticate to access the local cloud PAP and policy adaptor, which may be a federated authentication using a trusted IdP or use another authentication method supported by the local cloud.
II) One of the responsibilities of the tenant security administrators is to input tenant-scoped mapping rules on the adaptors. Mapping rules are important to allow the
Figure 1.2: Simplified view of the Solution’s Architecture. A tenant admin manage a local policy.
adaptors to perform the semantic mappings. For instance, a tenant may define a set of roles to be valid in their account, or a set of security levels in the Level of Assurance (LoA) attribute. In a federation context, other roles or LoA could be used, and a function that maps a local value into a federated one and vice-versa is required.
III) The tenant security administrator may also define authorisation rules that are specific for his tenant account.
IV) These local tenant rules will not be enforced on the other APF member accounts, and therefore they cannot conflict with the common rules. The APF agent will verify offline for conflicts and alert the tenant administrator if they exist.
V) The APF agent gets the common policy from the FAPManS in order to perform the conflict check.
VI) The adaptor is used to convert common policies into local syntax and semantics, and vice-versa.
Finally, the access control itself is represented in Figure 1.313 by the flow shown in lowercase letter.
a) Cloud users will authenticate on an IdP trusted by all members of the APF. Therefore, the APF members will also be members of an Identity Federation and take advantage
13It is important to note that the flows presented in Figures 1.1 and 1.2 happen offline, whereas the one in
Figure 1.3: Simplified view of the Solution’s Architecture. A user accesses different IaaS CSPs and receives homogeneous privileges.
of SSO.
b) Users may access services on any IaaS cloud tenant account that is an APF member.
c) When an action is requested, the Policy Enforcement Point (PEP) in the IaaS service will ask the PDP for a decision.
d) The PDP will verify the rules from the local PAP on its decision. These rules are the union of the common policy rules and the local tenant rules, which do not conflict.
IdPs are used for authentication of tenant users and administrators to access the cloud services, and also of APF administrators to access the FAPManS interface. They are responsible for a homogeneous authentication and also part of authorisation.
Common rules, when applicable to a combination of subject, action, resource and envi-ronment, will provide the same effect (allow or deny) on any IaaS service provided by members of the APF, i.e. on any federated IaaS service. This provides a homogeneous authorisation experience for users of IaaS clouds that are members of an APF.
The original cloud AC mechanisms are not modified in this solution, what makes it easy for adoption. Local policies can have a mix of federated and also non-federated rules, since these latest ones do not conflict with the former group. It is responsibility of the APF agents to detect these conflicts and notify the tenant administrator to take the proper action.
Therefore, the proposed solution presents the following characteristics.
authorisation operation, and it can also be deployed in a distributed and fault tolerant way.
2) It preserves the original policy engines of each CSP.
3) Policies of all the federated CSPs are stored and can be managed from a central PAP (FAPManS).
4) Different policies written in different languages can be represented and stored in a common model (Disjunctive Normal Form (DNF)).
5) Policies can be converted from the common model to the local languages, and back, preserving their semantics.
6) Subjects, actions, resources and environment entities cited in the policies are under-stood and represented in an homogeneous way in the stored federated policies.
Items 1 to 3 are inherent of the architecture of the proposed solution. Items 4 to 6 will be validated, and the Level of Semantic Equivalence (LSE), which represents how successful was a policy adaptation, will be measured.
1.5
Organisation of the Thesis
This thesis is organised in eight chapters, which are described in this section. The main technical background concepts and the state of the art on authentication and authorisation on multi-cloud environments are presented in Chapter 2. A critical appraisal shows the similarities and differences of the solution presented in this thesis and other approaches found in the literature.
Chapter 3 discusses homogeneous authentication on a specific open source IaaS cloud platform: OpenStack. This platform is integrated with Identity Federation using multiple proto-cols. A first approach uses a modified version of “Grizzly”, the seventh release of OpenStack, provided by the University of Kent at Canterbury (UKC). “Grizzly” does not offer native support to Identity Federation protocols, however this version integrates with IdPs through SAML. It was used as base for adding support to the OpenID Connect protocol, and both protocols were compared. This work inspired the OpenStack community to provide support for Identity Feder-ation, which was officially released in its eleventh release, called “Kilo”. A second approach uses the ninth OpenStack release, known as “Icehouse”, which is a preliminary version of the official support to federations. The OpenStack platform was integrated with Eduroam, an identity federation for network access, using the ABFAB protocol. Two points can be highlighted from this latest research: 1) OpenStack’s official support to federations provides an integration layer using Apache web server which facilitates the adoption of identity protocols such as ABFAB; 2) the ABFAB protocol allows the use of network credentials to access services in the application layer such as an IaaS cloud dashboard.
The solution presented in Section 1.4 is detailed in Chapter 4. It was designed to provide homogeneous authentication and authorisation on multi-cloud environments. This chapter discusses the concept of an Authorisation Policy Federation (APF), the DNF policy format, the architecture of the solution, and each of its major components: the FAPManS and the policy adaptors.
Chapter 5 defines a simple Ontology for representing elements of Access Control in IaaS clouds. The elements of the Ontology are used to define the common policies, which can be translated to local policies by the adaptors. Therefore, these elements must be common to all cloud technologies in use, otherwise they can not be translated to them. However, policies written in terms of a subset of the technologies, can also be written to be used on the compatible platforms. The dynamics of the Ontology definition and usage is also discussed in this chapter. The API of the FAPManS and of two adaptors were implemented to validate this solution, one for AWS and the other for OpenStack clouds. The Ontology was also defined in Web Ontology Language (OWL). These implementations are detailed in Chapter 6.
The validation of the proposed solution is detailed in chapter 7. It uses the implemen-tation of the adaptors to show that this solution achieves the goal of providing a homogeneous authorisation for users of heterogeneous IaaS multi-cloud systems. It is shown that a common federated policy in DNF using terms from the Ontology can be created from standard policies in two native cloud languages (OpenStack and AWS), and also translated back to these local formats. The success of the translations can be represented by the “Level of Equivalence” metric, and percentages above 80% were obtained from these validation scenarios.
Finally, Chapter 8 draws the conclusions, presenting the major contributions of this thesis and a summary of the limitations and future works.
2
Background and State of the Art
This chapter presents the state of the art on background concepts that are important for the comprehension of this thesis, as well as related works. This includes concepts related to authentication and authorisation of users that request access to cloud resources and services, multi-cloud environments, and ontologies for access control on Infrastructure as a Service (IaaS) clouds.
2.1
Authentication and Identification
User’s authentication is a task that intends to proof that a user is who he is claiming to be. In other words, the user shows proofs that his is authentic, genuine, and not another person or agent pretending to be himself. During the authentication process, the user usually present one or multiple authentication factors, such as something that he knows (like passwords), something that he is (i.e., biometric measures), and something that he owns (like One-Time Passwords (OTPs), digital certificates or hardware tokens).
During the authentication process, users can be identified or not. Identification happens when a user intends to proof to a service provider that he is a known user, which can be already associated to attributes that represent some of his characteristics. For instance, a user can proof to a bank, that he is the person who owns an account or a credit card. Or a user can proof to a university that he is a student with id “1234”, or that he is a staff member or a professor. On the other hand, it is also possible to authenticate anonymous users. For instance, an anonymous user may claim that he is a returning user. Fido alliance1provides authentication solutions that protect the user’s identity based on Public Key Infrastructure (PKI).
Identity federation arises when an entity that knows a user, called Identity Provider (IdP), attest to other entities, the Service Providers (SPs), that he is the known user that owns some attributes. In other words, IdPs are specialized third party entities that perform the authentication and identification of users to applications and services. For instance, an e-commerce store (SP) that gives discounts to university students cannot verify if their users are students or not by
themselves, so it trusts in the universities (IdPs) to attest this. Then the user authenticates to the university using its student credentials and present a proof of this authentication to the store, which will give the discount. Therefore, SPs do not need to perform the authentication of users, but trust in the information presented by the IdPs instead.
Identity federations also enables the Single Sign-On (SSO), i.e., users authenticate once with an IdP, and all SPs that trust on it will provide access without the need of authenticating multiple times. The solution proposed in this thesis uses SSO as part of it, through the use of identity federations. Multiple identity federation protocols can be used to enable identity federations. Security Assertion Mark-up Language (SAML), OpenID Connect and Application Bridging for Federated Access Beyond web (ABFAB) are among the major identity federation protocols. Most of them can be used to access cloud services such as IaaS platforms.
SAML is a mature protocol based on eXtensible Mark-up Language (XML) maintained by the Organization for the Advancement of Structured Information Standards (OASIS) Security Services Technical Committee, with contributors from big companies like Nokia, International Business Machines (IBM), Intel, Oracle, Red Hat, Sun, and also big academic and research cen-tres like Massachusetts Institute of Technology (MIT) and Internet2 (SAML SPECIFICATIONS,
2005). In SAML protocol, the user proves its identity to the IdP, which asserts attributes about him, such as name, affiliated institution/company, roles, date of birth etc. IdPs can possibly sign its assertion using PKI asymmetric keys, in a way that the SP can verify its authenticity. Subject attributes can be defined in multiple schemas, specified in attribute profiles (PROFILES FOR THE SAML V2.0, 2005). For instance, attributes defined in schemas that follow the X.500 and Lightweight Directory Access Protocol (LDAP) standard, such as EduPerson2or the inetOrgperson (SMITH,2000) can be used. The first version of its specification was released in November 2002 and the version 2.0, the latest one, in March 2005. SAML can be encapsulated in multiple data transfer protocols, such as HyperText Transfer Protocol (HTTP) and Simple Object Access Protocol (SOAP), which was the only option in its first versions.
OpenID Connect3is a RESTful protocol, based on JavaScript Object Notation (JSON) messages, maintained by the OpenID Foundation and also sponsored by big companies such as Google, Microsoft, Oracle, Paypal, Symantec, Verizon, RSA and VMWare4. In OpenID Connect protocol, the user proves its identity to the IdP, which sends an authentication code back to him. The user then sends this code to the SP, which communicates with the IdP in order to receive the user’s attributes. OpenID Connect specification is dated from 2012, and there is only one version (1.0). Although it performs the same tasks as its ancestor OpenID, which had two versions, OpenID Connect was completely rebuilt over the OAuth 2.0 protocol (HARDT,2012).
ABFAB5is maintained by Internet Engineering Task Force (IETF) and it allows users to use services (in the application layer) by authenticating to an IdP using his network layer
creden-2http://www.educause.edu/eduperson 3http://openid.net/connect/
4http://openid.net/foundation/sponsoring-members/ 5https://datatracker.ietf.org/wg/abfab/documents/
tials. This is possible thorough the integration of multiple protocols such as Generic Security Service (GSS), Extensible Authentication Protocol (EAP), SAML, Authentication, Authorisation and Accounting (AAA) and Remote Authentication Dial In User Service (RADIUS) ( HART-MAN; HOWLETT,2013a) (HARTMAN; HOWLETT,2013b) (WINTER; SALOWEY,2013). The user, using a client, normally a compatible web browser, authenticates with a RADIUS IdP and receives a SAML assertion which can be used on trusted SPs, also called Relying Parties (RPs) (HOWLETT et al., 2016). Multiple services can use ABFAB, including IaaS and Platform as a Service (PaaS) clouds (SMITH,2016). HOWLETT; HARTMAN; PEREZ-MENDEZ(2016) define the configuration details of the RADIUS IdP in order to reply the SAML assertion.
2.1.1
Integration of IaaS platforms with Identity Federations
A prototype intending to integrate OpenStack with IdPs using OpenID protocol was built in (KHAN; YLITALO; AHMED,2011). However, the OpenStack version that was used did not have a well defined identity module, like the Keystone module present on current versions. Therefore, the OpenStack service Application Programming Interface (API) was complemented with functions to authenticate through the OpenID protocol, which was a former protocol which inspired OpenID Connect.
In (REVAR; BHAVSAR,2011), the authors describe a high-level architecture with some code snippets demonstrating that it is possible to implement a SSO mechanism using PKI with X.509 certificates in Eucalyptus platform.
In (CHADWICK; FATEMA,2012), Eucalyptus is integrated with IdPs using SAML protocol. In (CHADWICK; CASENOVE; SIU,2013), the same author integrates a newer version of OpenStack through its identity module (Keystone) with identity providers also using SAML. The SimpleSAMLphp6 application was used as IdP. Besides SAML, this system provides a component called “Proxy IdP”, which interfaces with other identity providers through the protocols SAML, OAuth7, OpenID and others. In a blueprint8, this author explains how the integration of Keystone and identity federations works, and define two authentication flows: one for simple clients, and the other for intelligent clients protected against phishing attacks.
DINIZ; SILVA; ARAÚJO(2013) extends the solution ofCHADWICK; CASENOVE; SIU(2013) to integrate OpenStack to a Shibboleth IdP, presenting the implementation issues and solutions. In (SILVA et al.,2013), the authors present a case study to integrate the Open-Stack Swift module with an identity federation through a Shibboleth IdP using the solution from (DINIZ; SILVA; ARAÚJO,2013).
As a result of this thesis,SETTE; FERRAZ(2014a) extends the reference implementation fromCHADWICK; CASENOVE; SIU(2013) to allow the “Federated Keystone” to support
6https://simplesamlphp.org 7http://oauth.net
