Technisch-Naturwissenschaftliche Fakult¨at
Client-Centric Identity and Access Management
in Cloud Computing
DISSERTATION
zur Erlangung des akademischen Grades
Doktor der Technischen Wissenschaften
im Doktoratsstudium derTechnischen Wissenschaften
Eingereicht von:
Mircea Boris Vleju, MSc
Angefertigt am:
Christian Doppler Laboratory for Client-Centric Cloud Computing (CDCC)
Beurteilung:
Prof. Dr. Klaus-Dieter Schewe (Betreuung)
Prof. Dr. Dana Petcu
Ich erkläre an Eides statt, dass ich die vorliegende Dissertation selbstständig und ohne fremde Hilfe verfasst, andere als die angegebenen Quellen und Hilfsmittel nicht benutzt bzw. die wörtlich oder sinngemäß entnommenen Stellen als solche kenntlich gemacht habe. Die vorliegende Dissertation ist mit dem elektronisch übermittelten Textdoku-ment identisch.
I hereby confirm that this thesis is the result of my own work. I did not receive any help or support from commercial consultants. All sources and/or materials applied are listed and specified in the thesis. This thesis is identical to the text document transmitted electronically.
Furthermore, I confirm that this thesis has not yet been submitted as part of an-other examination process neither in identical nor in similar form.
Der Einsatz von Cloud-Computing-Technologien ist in den letzten Jahren stark gewach-sen, da Cloud-Computing-basierte Infrastrukturen viele Vorteile gegenüber traditionel-len Infrastrukturen bieten (niedrigere Kosten, höhere Flexibilität, Services auf Abruf, rasche Anpassungsfähigkeit, etc.). Trotz der vielen Vorteile birgt die Einführung von Cloud-basierten Services auch Nachteile, wie etwa: Verlust der Kontrolle, Bindung an den Serviceanbieter, technische und rechtliche Fragen, und Sicherheits- und Daten-schutzprobleme.
Das Forschungsziel dieser Dissertation ist das Untersuchen der Interaktionen für Identitäts- und Zugriffsmanagement (IAM) zwischen Klienten und Services aus einer klientenzentrierten Perspektive und das Entwerfen von Lösungen, die den Klienten in der Verwendung von Cloud-basierten Services unterstützen. In Bezug auf IAM wur-den mehrere Probleme iwur-dentifiziert: Verlust der Kontrolle (ein Klient kann nicht mehr bestimmen, wo Daten gespeichert werden und wie der Serviceanbieter diese Daten verarbeitet), Optimierung des Kundenerlebnisses durch den Serviceanbieter (dadurch werden mehr Informationen als nötig erhoben), konkurrierende Cloud-Märkte und Ge-fährdung durch Anbieterbindung (die Klienten werden zur Nutzung mehrerer Anbi-eter gezwungen), Bereitstellung und Löschung von serviceanbiAnbi-eterübergreifenden Be-nutzerkonten, Verwaltung von sensitiven Daten und damit verbundener Passwortmüdig-keit über mehrere Serviceanbieter, und die verstärkte Bedrohung durch Social-Enginee-ring-Angriffe.
Die angeführten Probleme können durch eine klientenzentrierte Herangehens-weise für IAM in Cloud Computing behandelt werden. Klient-Cloud Interaktion wurde in Bezug auf IAM untersucht, und drei Szenarien wurden erarbeitet: das direkte Inter-aktionsszenario (wo der Benutzer auf das IAM-System des Serviceanbieters beschränkt ist), das verschleierte Interaktionsszenario (wo der Benutzer zusätzlich aus echten, ver-schleierten und teils-verver-schleierten Identitäten auswählen kann) und das protokollba-sierte Interaktionsszenario (wo auf bestehende Protokolle aus föderationsbaprotokollba-siertem Identitätsmanagement für Authentisierung und Autorisierung zurückgegriffen wird). Basierend auf diesen detaillierten Szenarien wird ein IAM Metasystem vorgestellt.
Die zentrale Forschungsleistung dieser Dissertation ist die sogenannte Identity Management Machine (IdMM). Die IdMM ist ein klientzentriertes Metasystem model-liert mittels Abstract State Machines (ASM). Das System agiert als Middleware zwis-chen dem Klienten (repräsentiert durch ein Unternehmen, welches ein privates Iden-titätsverzeichnis betreibt) und den unterschiedlichen genutzten Serviceanbietern. Die IdMM ist ein Single Sign-On (SSO) Service, welches einen Benutzer für ein gegebenes Service automatisch authentisiert und autorisiert. Der SSO-Ansatz hat den Vorteil, dass die Benutzer ihre Zugangsdaten für Cloud-Services nicht kennen müssen und dadurch
ten Daten im Identitätsverzeichnis des Klienten. Bereitstellung und Löschung von Be-nutzern (in der Cloud und auf Seite des Klienten) wird automatisch durch das System durchgeführt. Periodisch werden die Cloud-basierten Zugangsdaten zurückgesetzt, um eine sichere Interaktion zu gewährleisten, und Klienten können protokollierte Aktiv-itäten für Auditierungszwecke abfragen. Die IdMM besteht aus mehreren Agenten, wobei jeder für eine bestimmte Interaktion zwischen dem System und den involvierten Aktoren (Benutzer, das Identitätsverzeichnis des Klienten, das IAM-System der Cloud) zuständig ist.
Während die Einführung der IdMM den Klienten in den IAM-spezifischen As-pekten der Benutzung von Cloud-Services unterstützt, müssen weitere Aspekte berück-sichtigt werden. Eine detailliertere Betrachtung der generischen Interaktion zwischen Klient und Clouds muss spezifiziert werden. Problematiken, wie etwa rechtliche und vertragliche Fragen in Bezug auf Service-Level-Vereinbarungen, Adaption an Endge-räte und Sicherheitsmonitoring müssen entsprechend behandelt werden. Daher funk-tioniert die IdMM sowohl als eigenständiges System als auch als Teilsystem einer Middleware-Lösung. In der Middleware-Lösung repräsentiert die IdMM eine Schlüs-selkomponente neben Komponenten für Sicherheits- und Service-Level-Monitoring, In-haltsaufbereitung und Serviceverhandlung.
The adoption of cloud computing technologies has seen a great growth in recent years. Cloud computing-based infrastructures present many advantages over traditional infras-tructures (reduced costs, higher flexibility, on-demand services, rapid elasticity, etc.). While cloud computing boasts other advantages it should be noted that the adoption of cloud-based services comes with disadvantages, such as: loss of governance, provider lock-in, technical and legal issues, security and privacy issues.
The purpose of this thesis is to investigate the Identity and Access Management (IAM) interactions between clients and cloud providers from a client-centric perspective and to propose solutions that would aid clients in using cloud-based services. With respect to IAM several issues were discovered: loss of control (the client no longer has control over where the data is stored and what the service provider does with it), the provider’s need to control the customer experience (leading them to ask for more information than required), the competitive cloud markets and threat of provider lock-in (leading clients to use multiple providers), user provisioning and de-provisioning across several providers, managing sensitive data and password fatigue across multiple service providers and the increased thread of social engineering attacks.
The problems presented above can be mitigated by adopting a client-centric ap-proach to IAM in cloud computing. To achieve this, the client-to-cloud interactions with respect to all aspects of IAM were studied and three distinct scenarios proposed: the direct interaction scenario (where the user is restricted to using the cloud provider’s IAM system), the obfuscated interaction scenario (where the client can choose between real identities and obfuscated or partially obfuscated ones which help protect sensitive identity information) and the protocol-based interaction scenario (which makes use of existing Federated Identity Management protocols to aid in authentication and autho-rization). With these detailed interaction scenarios a client-centric IAM meta-system will be introduced.
The Identity Management Machine (IdMM) represents the main contribution of the thesis. The IdMM is a client-centric IAM meta-system, based on Abstract State Machines (ASMs). The system acts as a middleware between a client (represented by a company hosting a private identity directory) and the various cloud providers used. The IdMM is a Single Sign-On (SSO) service that automatically authenticates and au-thorizes a user to a given service. The advantage of the SSO approach is that users are not aware of their credentials to the cloud services thus diminishing the risk of phishing attacks. In the protocol-based interaction the IdMM acts as an identity provider while in the direct case the IdMM synchronizes the information stored on cloud services with the data stored in the client’s directory. User provisioning and de-provisioning (both on the cloud and on the client’s side) is handled automatically by the system. Periodically
client’s directory, the cloud’s IAM system).
While the adoption of the IdMM will help clients with the IAM related aspects of using cloud services other aspects must also be taken into account. A more detailed look at the generic interaction between client and clouds has to be specified. Other issues, such as legal and contracting issues with respect to Service-Level Agreements (SLAs), adaptation to end devices and security monitoring must also be mitigated. As such, the IdMM functions as both an stand-alone system and as a system within a Client-Cloud Interaction Middleware (CCIM) solution. In the CCIM solution the IdMM represents one of the key components next to security and SLA monitoring components as well as content adaptation and service negotiation components.
I would like to express my sincere gratitude to my advisor, Prof. Dr. Klaus-Dieter Schewe, for his input and advices during the time I completed this thesis. I would also like to thank Prof. Dana Petcu for taking the time to advise me in my topic. I would also like to thank Prof. Bruno Buchberger for giving me the opportunity to study in Austria through the ISI master program and for his involvement and suggestions throughout my study period.
Many thanks go to my colleagues, Dr. Károly Bósa, Andreea Buga, Roxana Holom, Harald Lampesberger, Tania Nemes, and Mariam Rady for their input and sup-port, especially during the writing stage of my studies. Your support and the atmosphere in our lab really helped with the stress of completing the thesis. Special thanks also go to Ursula Haiberger for her help as well as her great restaurant cooking which helped nourish me throughout the latter part of my study period. Thanks also go to Ciprian Z˘avoianu and Harald for the endless fun we had during our breaks.
I would also like to thank my loving parents, Mircea Boris and Maria for their love, their support throughout the years. Their encouragement lead me to pursue this career and I will forever be indebted for their sacrifices in supporting me. Thanks also go to all my friends and loved ones for their support, especially for not frequently asking: “When will you finish?”.
And last but not least, I would like to thank the communities of Imgur and Reddit without whom this thesis would have been completed earlier.
Kurzfassung VII Abstract IX Acknowledgements XI Acronyms XXIII 1 Introduction 1 1.1 Motivation . . . 1
1.2 Objectives of the Thesis . . . 3
1.3 Outline . . . 5
1.4 Chapter Summary . . . 6
2 Literature Review 7 2.1 Cloud Computing . . . 7
2.2 Identity and Access Management . . . 10
2.2.1 Identity Management . . . 10
2.2.2 Access Management . . . 13
2.2.3 Federated Identity Management . . . 15
2.3 Identity and Access Management in Cloud Computing . . . 21
2.4 Client-Centric Identity Management in Cloud Computing . . . 23
2.4.1 Client-Centric Approaches to Identity Management . . . 23
2.4.2 Current Client-Centric Solutions for Identity and Access Man-agement in Cloud Computing . . . 29
2.5 Chapter Summary . . . 31
3 A Client-Centric Approach to IAM in Cloud Computing 33 3.1 Identity and Access Management Meta-System . . . 33
3.1.1 Problems of Identity and Access Management in Cloud Com-puting . . . 33
3.1.3 Other Aspects of Client-Centric Cloud Computing . . . 40
3.2 The Identity Management Machine (IdMM) . . . 42
3.2.1 Key Actors and Resources . . . 42
3.2.2 Client-Cloud Interaction Scenarios . . . 43
3.2.3 Key Features of the IdMM . . . 45
3.2.4 IdMM Architecture . . . 47
3.2.5 IdMM Deployment Scenarios . . . 48
3.2.6 The Idmm as Part of a Client-cloud Interaction Middleware . . 52
3.2.7 The IdMM in Literature . . . 54
3.3 Use-Case Scenarios . . . 55
3.3.1 Using a Stand-alone IdMM . . . 56
3.3.2 Using the CCIM with Integrated IdMM . . . 57
3.4 Chapter Summary . . . 58
4 The Identity Management Machine (IdMM) 61 4.1 Basics Concepts of the IdMM . . . 62
4.1.1 Data Types . . . 62
4.1.2 Encryption . . . 64
4.1.3 Communication Between Agents . . . 65
4.1.4 Choosing Random Values . . . 67
4.1.5 Role-Based Access Control . . . 68
4.2 The IdMM Core Agent . . . 69
4.2.1 Request Queue Mechanism . . . 70
4.2.2 User Authentication . . . 71
4.2.3 Cloud Authentication and Authorization . . . 72
4.2.4 Cloud De-Authentication . . . 76
4.3 The IdMM Client Agent . . . 77
4.3.1 Client Interaction Interface . . . 77
4.3.2 Obtaining Data From The Directory . . . 79
4.3.3 Storing and Editing Data on the Directory . . . 87
4.3.4 Removing an Identity . . . 88
4.3.5 Communication with Core Agent . . . 88
4.4 The IdMM Cloud Agent . . . 89
4.4.4 Communication with the Core Agent . . . 96
4.5 The IdMM User Agent . . . 97
4.5.1 Managing User Events . . . 98
4.5.2 Input from the User . . . 99
4.5.3 Displaying Messages to the User . . . 99
4.5.4 Communication with the Core Agent . . . 100
4.6 The IdMM Protocol Agent . . . 101
4.6.1 Managing Protocol Authentication . . . 101
4.6.2 Processing Protocol Authentication Request . . . 103
4.6.3 OpenID Implementation . . . 105
4.7 The IdMM Provisioning Agent . . . 108
4.7.1 Attribute Synchronization . . . 108
4.7.2 Creating an Identity . . . 109
4.7.3 Modifying an Identity . . . 111
4.7.4 Removing or Disabling and Identity . . . 121
4.7.5 Periodic or Random Password Resets . . . 124
4.8 The IdMM Monitoring Agent . . . 126
4.9 Chapter Summary . . . 131
5 The IdMM as Part of an Integrated Component of the CCIM 133 5.1 The Client-Cloud Interaction Middleware (CCIM) . . . 133
5.1.1 Plot-Based Access Management . . . 135
5.1.2 SLA Management and Monitoring . . . 137
5.1.3 Client-Side Adaptivity . . . 138
5.1.4 Security Monitoring and Anomaly Detection . . . 140
5.1.5 Client-to-Client Interaction (CTCI) . . . 142
5.1.6 Anonymous Docking Service . . . 143
5.2 Extending the IdMM for the CCIM . . . 144
5.2.1 Extending the IdMM’s data structures . . . 145
5.2.2 IdMM-CCIM Agent Communication . . . 146
5.2.3 Retrieving Service Information . . . 147
5.2.4 Service Authentication and De-authentication . . . 148
5.2.5 Authorizing Plots . . . 151
6 Validation and Implementation of the Identity Management Machine 155
6.1 Validation the IdMM specifications . . . 155
6.2 Proof of Concept Implementation . . . 158
6.3 A Comparison Between the IdMM and Existing Solutions . . . 159
6.4 Chapter Summary . . . 161
7 Conclusions 163 A Abstract State Machines and CoreASM 167 A.1 Abstract State Machines . . . 167
A.2 CoreASM . . . 169
A.3 Appendix Summary . . . 169
B Full IdMM ASM Specification 171
2.1 Cloud Computing Software Stack . . . 8
2.2 Example of an identity . . . 11
2.3 Flat RBAC Model . . . 14
2.4 Hierarchical RBAC Model . . . 16
2.5 Service Provider Centric Federated Identity Management . . . 16
2.6 Identity Provider Centric Federated Identity Management . . . 17
2.7 Multi-Provider Cross Domain Federated Identity Management . . . 17
2.8 OpenID Protocol . . . 20
2.9 Components of Java-based Identity Selector [1] . . . 25
2.10 Decentralized IdM In Cloud Computing [29] . . . 26
2.11 Information flow in Identity Metasystem [26] . . . 29
3.1 Client-Centric IAM Meta-System Deployment Scenarios . . . 37
3.2 Functionalities of the Client-Centric Identity Management Meta-System 39 3.3 IdMM Actors . . . 43
3.4 IdMM Architecture . . . 48
3.5 Application SSO Scope in an On-Premise Deployment . . . 49
3.6 Device SSO Scope in an On-Premise Deployment . . . 50
3.7 Client Scope in an On-Premise Deployment . . . 51
3.8 Cloud Deployment Architecture . . . 51
3.9 Hybrid Deployment Architecture . . . 52
3.10 Client-Centric Middleware Arhitecture . . . 53
3.11 Client-Centric Middleware Information Flow . . . 54
3.12 FooBar Use Case Scenario . . . 55
3.13 Use case scenario for Bob . . . 56
3.14 Use Case Scenario for Mary . . . 57
3.15 Use Case For Client-Centric Middleware . . . 58
4.4 ASM Fragment for IdMM Encryption . . . 64
4.5 ASM Fragment for IdMM Agent Communication Message . . . 65
4.6 ASM Rules for IdMM Agent Communication . . . 66
4.7 ASM Example for IdMM Agent Communication . . . 66
4.8 ASM Fragment for Choosing Random Identities and Protocols . . . 67
4.9 ASM Rule for Choosing Random Protocol ID . . . 67
4.10 ASM Rules for Choosing Random Passwords . . . 68
4.11 ASM Fragment for RBAC Data Types . . . 68
4.12 ASM Example for Adding Access Rights . . . 69
4.13 ASM Fragment for the Agent’s Dynamic Frame . . . 70
4.14 ASM Rules for Processing Messages . . . 71
4.15 ASM Rules for IdMM Authentication . . . 72
4.16 ASM Rules for Cloud Authentication . . . 72
4.17 ASM Rules for Cloud Authorization . . . 73
4.18 ASM Rules for Determining an Identity’s Access Rights for a Service . 74 4.19 ASM Rules for Determining the Identity Type and Protocol . . . 75
4.20 ASM Rule for Creating Partially Obfuscated Identities . . . 75
4.21 ASM Rule for Performing Cloud Authentication . . . 76
4.22 ASM Rules for Cloud De-Authentication . . . 77
4.23 ASM Fragment for the Client Interaction Interface . . . 78
4.24 ASM Fragment for Finding an Identity . . . 79
4.25 ASM Rules for Matching and Loading an Identity . . . 80
4.26 ASM Rules for Finding a Service . . . 81
4.27 ASM Rules for Retrieving Authentication Attributes . . . 82
4.28 ASM Rules for Retrieving Service Attributes . . . 82
4.29 ASM Rules for Finding Attributes . . . 83
4.30 ASM Rules for Retrieving Local and Remote Attributes . . . 84
4.31 ASM Rules for Retrieving Protocol Attributes . . . 85
4.32 ASM Rules for Retrieving Obfuscated Identities . . . 86
4.33 ASM Rules for Saving an Identity . . . 87
4.34 ASM Rule for Removing an Identity . . . 88
4.35 IdMMCoreAgent ASM Rules for IdMMCore- IdMMClientCommunication 89 4.36 ASM Fragment for the IdMMCloud Agent’s Data Types and Dynamic Frame . . . 90
4.39 ASM Rules for Cloud Authentication . . . 94
4.40 ASM Rules for Solving Captchas and Extracting Attributes . . . 95
4.41 ASM Rules for Logout . . . 95
4.42 ASM Rules for Attribute Synchronization . . . 96
4.43 ASM Rules for API-Based Attribute Synchronization . . . 96
4.44 IdMMCoreAgent ASM Rules for IdMMCore- IdMMCloudcommunication 97 4.45 ASM Fragment for the User Interface . . . 98
4.46 ASM Rule for Listening for an Event . . . 98
4.47 ASM Rules for Managing Events . . . 99
4.48 ASM Rules for Prompting for Input . . . 100
4.49 ASM Rules for Displaying Messages . . . 100
4.50 IdMMCoreAgent ASM Rules for IdMMCore- IdMMUser Communication 101 4.51 IdMMCoreAgent ASM Rules for Processing Authentication Requests . 102 4.52 IdMMCloudAgent ASM Rules for Protocol Authentication . . . 103
4.53 ASM Fragment for Protocol Request Data Types . . . 103
4.54 ASM Rules for Adding a Protocol Request to the List of Requests . . . 104
4.55 ASM Rules for a Relying Party Authentication Request . . . 104
4.56 OpenID Overview . . . 105
4.57 ASM Fragment for OpenID Implementation . . . 106
4.58 ASM Rules for Processing an OpenID Authentication Request . . . 106
4.59 ASM Rules for Processing an OpenID User Info Request . . . 107
4.60 ASM Rules for OpenID Termination . . . 107
4.61 ASM Rules for Synchronizing Cloud Attributes . . . 108
4.62 IdMMClientAgent ASM Rules for Getting All Services For An Identity . 109 4.63 IdMMUser Agent ASM Rules for Creating an Identity . . . 109
4.64 IdMMCoreAgent ASM Rules for Creating an Identity . . . 110
4.65 IdMMCoreAgent ASM Rules for Checking the Permitted Roles . . . 111
4.66 IdMMUser Agent ASM Rules for Editing an Identity . . . 112
4.67 IdMMCoreAgent ASM Rules for Editing an Identity . . . 112
4.68 IdMMClientAgent ASM Rules for Obtaining Editable Identities . . . 113
4.69 IdMMUser Agent ASM Rules for Adding and Selecting Services . . . . 114
4.70 IdMMCoreAgent ASM Rules for Selecting a Service . . . 114
4.73 ASM Rules for Creating an Account . . . 116
4.74 IdMMCloudAgent ASM Rules for Creating a Cloud Account . . . 117
4.75 IdMMUser Agent ASM Rules for Removing a Service . . . 118
4.76 IdMMCoreAgent ASM Rules for Selecting a Service . . . 118
4.77 ASM Rules for Removing an Account . . . 119
4.78 IdMMCoreAgent ASM Rules for Removing a Service . . . 119
4.79 IdMMCloudAgent ASM Rules for Removing a Cloud Account . . . 120
4.80 IdMMUser Agent ASM Rules for Disabling an Identity . . . 121
4.81 IdMMClientAgent ASM Rules for Disabling an Identity . . . 121
4.82 IdMMCoreAgent ASM Rules for Disabling an Identity . . . 122
4.83 IdMMUser Agent ASM Rules for Removing an Identity . . . 122
4.84 IdMMCoreAgent ASM Rules for Removing an Identity . . . 123
4.85 ASM Rules for Removing Accounts . . . 124
4.86 IdMMCoreAgent ASM Rules for Performing a Password Reset . . . 124
4.87 ASM Rules for Checking for a Password Reset . . . 125
4.88 ASM Rules for Making a Password Reset . . . 126
4.89 IdMMCloudAgent ASM Rules for Changing a Password . . . 127
4.90 ASM Fragment for the Log Message Data Types . . . 127
4.91 ASM Rules for Logging Messages . . . 128
4.92 ASM Rules for Determining Whether to Restrict the Identity Based on Access Frequency . . . 129
4.93 ASM Rules for Determining Whether to Restrict the Identity Based on Access the Device’s Location . . . 130
4.94 ASM Rules for Restricting Access to a Service . . . 130
4.95 IdMMCoreAgent ASM Rules for the Monitoring Rules . . . 131
5.1 Client-Cloud Interaction Middleware Architecture [23] . . . 134
5.2 CCIM Rules for Session Start and Termination . . . 145
5.3 ASM Fragment for Extending the IdMM to Include Service Plots . . . . 146
5.4 ASM Fragment for the Extension of the RequestType Enumeration First Described in Figure 4.14 on Page 71 . . . 146
5.5 IdMMCore Agent ASM Rule for Processing Agent Request Messages (Extended Version of Figure 4.14 on page 71) . . . 147
5.6 CCIM Rules for Retrieving Service Data . . . 148
5.7 IdMMCoreAgent ASM Rules for Retrieving Service Data . . . 148
5.10 CCIM Rules for Authorizing Plots . . . 151 5.11 IdMMCoreAgent ASM Rules for Authorizing Plots . . . 152 5.12 CCIM Rules for Retrieving Information about Identities . . . 153 5.13 IdMMCoreAgent ASM Rules for Retrieving Information about Identities 153
ABAC Attribute Based Access Control. 13, 14
ACL Access Control List. 13, 63, 68, 73, 129, 145, 151
AES Advanced Encryption Standard. 64, 158
AJAX Asynchronous JavaScript and XML. 141
Amazon AWS Amazon Web Services. 9
Amazon EC2 Amazon Elastic Compute Cloud. 9, 30 Amazon S3 Amazon Simple Storage Service. 9
API Application Programming Interface. 159
ASM Abstract State Machine. IX, XVII–XXI, 5, 52,
54, 61, 62, 64–91, 93–104, 106–131, 133–136, 139, 143, 146–148, 150, 152, 153, 155–157, 164, 167–169
CCIM Client-Cloud Interaction Middleware. X, XX,
XXI, 3–6, 33, 42, 53–55, 57, 59, 133–135, 137, 139, 142–149, 151–154, 157, 159, 163–165 CII Client Interaction Interface. 77, 81, 83, 87, 88,
131, 137, 156, 158
CMS Content Management System. 9
CRM Customer Relationship Management. 9
CTCI Client-to-Client Interaction. 134, 142–144, 154
DAC Discretionary Access Control. 13
DMZ demilitarized zone. 30, 37, 38, 42, 49, 52, 158
DTD Document Type Definition. 141
EDTD Extended DTD. 141
FIdM Federated Identity Management. IX, 16–18, 21– 23, 31, 45, 47, 48, 62–64, 88, 90, 101, 131, 163
GUI Graphical User Interface. 89
GWT Google Web Toolkit. 158
10–13, 16, 21–24, 26, 29–31, 33, 35, 36, 38–47, 52, 54, 57, 58, 61, 64, 89, 133, 154, 155, 159, 163, 164
IBAC Identity Based Access Control. 13, 14
IDaaS Identity Management as a Service. 21, 23, 30, 38, 47, 59, 159–161, 163
IdMM Identity Management Machine. IX, X, XVII–
XXI, 5, 38, 42, 43, 45–59, 61–72, 74, 76–78, 80–83, 87–90, 92–105, 107–137, 144–148, 150– 161, 163–165, 169, 171
IWA Integrated Windows Authentication. 18
JSON JavaScript Object Notation. 159
KAT Kleene algebras with test. 136
LBAC Lattice Based Access Control. 13
LDAP Lightweight Directory Access Protocol. 42, 77, 158
MAC Mandatory Access Control. 13, 24
NIST National Institute of Standards and Technology. 7, 15
OP OpenID Identity Provider. 20, 105, 132
OWL-DL Web Ontology Language. 138
PaaS Platform as a Service. 9, 24, 31, 134
RBAC Role-Based Access Control. XVIII, 13–16, 31,
68, 110, 131, 164
RPC Remote Procedure Call. 141
RSS Rich Site Summary. 141
SAA Subject Acting As. 28
SaaS Software as a Service. 9, 24, 92
SAML Security Assertion Markup Language. 17–19,
21, 22, 45, 91, 141
SDC Google Secure Data Connector. 22
SLA Service-Level Agreement. X, 1, 2, 8, 30, 41, 52, 53, 57, 133, 134, 137, 138, 154, 164, 165
SME Small and Medium Enterprise. 9, 55, 134
SOAP Simple Object Access Protocol. 141
76, 105, 155, 158–160, 163, 164
URI Uniform Resource Identifier. 54, 63, 70, 72, 78, 79, 81, 83, 88, 90, 92, 97, 105, 118, 124, 137, 147, 148, 156
URL Uniform Resource Locator. 20, 137
VM Virtual Machine. 9, 21, 23, 24, 30, 34, 38, 42, 51, 52, 135
WUAG Weighted Undirected Acyclic Graph. 26
XHTML XML Hypertext Markup Language. 141
XML Extensible Markup Language. 18, 140, 141
XMPP Extensible Messaging and Presence Protocol.
141
XRI Extensible Resource Identifier. 20
Introduction
Recent years have seen a growth in the adoption of cloud computing by enterprises. The advantages of cloud computing coupled with increasing efforts by cloud providers to offer better security and stability have made the cloud a must-have buzzword in the description of any enterprise. Cloud computing offers clients many advantages, such as scalability, elasticity, maintenance support and consequently cost efficiency. The cloud computing market has grown substantially in the past few years with providers investing in increasing the performance and security of their cloud systems in order to attract more customers.
While its many advantages present an enticing offer to customers, cloud com-puting does come with certain challenges that might deter the adoption of cloud-based services. Problems such as provider lock-in, loss of control, security and privacy is-sues pose significant challenges to customers wishing to adopt a cloud-based business model [24, 31, 124]. Consequently, a lot of research has been conducted in order to make cloud services more secure and easier to use.
However, most of the research done so far has been cloud-oriented, focused on improving the cloud itself. The client side aspects of cloud computing have often been ignored. My research focuses on the interaction between clients and cloud providers. In particular, the focus is on identity and access management in cloud computing, estab-lishing what problems/threats a client might face when adopting a cloud-based solution. The research conducted has highlighted the need for a client-centric identity manage-ment system to allow clients to safely and efficiently use cloud-based services.
1.1 Motivation
One of the main problems for clients in cloud computing is the loss of control over their data and processes. Clients that adopt cloud-based services have to entrust the providers with their private data. As stated by Schewe et al. [113], most of the offerings in the field of cloud computing are provider-centric. As such, the research is often focused on mitigating any threats on a provider level, often completely ignoring the client. This leads to further issues for a potential client, such as handling with the identities of the client, access rights, security and privacy concerns, adaptivity to the needs of the client and legal issues in contracting with respect to Service-Level Agreements (SLAs) [112,
113].
With respect to Identity and Access Management (IAM) several key issues can be identified. The first is the loss of control over the identity data. Clients must trust that cloud providers employ adequate means for securely storing data and executing pro-cesses. However, the clients themselves have no means of ensuring that cloud providers conform to the terms specified in the SLAs. Moreover, they cannot access the cloud’s internal infrastructure to ensure the proper storage of the data and processes. This issue is further aggravated by the fact that service providers often tend to control the cus-tomer experience, e.g. service providers will often request more information than they actually need. For instance, a service provider will ask for a full date of birth in order to check if a user is over 18 years old. However, in most cases the year of birth is sufficient to prove this. In such cases the client should have control over what identity related data is sent to a service. In other words, the client should only offer the minimum amount of private identity-related information in order for him or her to successfully use a given service.
In addition to the loss of control over the data, the management of identities and access rights across multiple providers must also be to considered. Clients may choose to use services provided by one or more cloud providers. In the latter case the client will have to manage the information and assure that the appropriate access rights are granted by each of the providers. Any change in the identity information (such as changing the phone number or access rights of a user) must be performed on each system. Similarly, the access rights of individual users may change over time, a process that has to be reflected on the provider’s system. User provisioning and de-provisioning must also be considered. That is, when a new employee joins a company the appropriate identities, credentials and access rights must be created, and when an employee leaves a company, the identities and access rights must be revoked to ensure he or she no longer has access to the services.
Having multiple identities for different services also increases the risk of phishing attacks. According to the APWG report [9] a total of 42,890 phishing websites were detected in December 2013 alone with 362 brands targeted by phishing campaigns. The report shows a clear increase in the number of phishing attacks worldwide. As such, a client must ensure that its users are protected from phishing attacks taking into consideration that phishing campaigns can target any of the providers used by the client. In my master thesis [124] I described a set of client-side threats resulting from client-to-cloud interaction. The focus was on scenarios depicting cloud vulnerabilities as well as the misuse of cloud resources by users. Since cloud services are offered on a pay-as-you-go model, users that misuse the services can create additional extra costs for a client. As such the client must be protected from misuse scenarios and must be allowed to deny access to users.
In order for a client to utilize the resources of one or more cloud providers the IAM issues presented above must be mitigated. However, this alone does not ensure the client’s full protection and efficient use of cloud services. Other security risks, contractual problems and adaptivity concerns must also be considered. When using cloud-based services clients must be able to fully understand the contracts or SLAs they sign with cloud providers, as pointed out by Rady [95]. They must also be able to ensure that the usage of cloud services is done in a secure way, as emphasized by
Lampesberger [63]. Similarly, the content supplied to clients should be adapted to the need of the clients, as investigated by Chelemen [28]. For an efficient and safe use of cloud-based services a client must take into consideration these aspects as well.
1.2 Objectives of the Thesis
The issues presented in Section 1.1 are addressed with the introduction of a client-centric identity and access management meta-system. The overall objective of the the-sis is to address the problems of managing identities and access rights across multiple providers. For this I investigate a client-centric approach. Such an approach entails the adoption of a Client-Cloud Interaction Middleware (CCIM) by the client. The CCIM would either be hosted on-premise by the client or as a separate cloud serv-ice (e.g. in a private cloud environment). For IAM alone the CCIM consists of an IAM meta-system used by the client for authentication, authorization, user provisioning and de-provisioning when accessing cloud-based services. As mentioned in the previous section, IAM is not the only aspect of cloud computing that needs to be taken into con-sideration. With this in mind the CCIM consists of various components (from IAM to security and monitoring components), which aim at improving the overall interaction between clients and cloud providers.
A client-centric IAM approach allows a client to maintain a local identity direc-tory that stores all required identity information. For security and privacy reasons this identity directory will be private (i.e. inaccessible from any external source). In this way the system allows the client to rapidly provision and de-provision users. On one hand, provisioning entails the quick creation of identities (or accounts), credentials and appropriate access rights on both the client’s directory as well as the provider’s system. On the other hand, if an employee leaves the company, then the system should allow for a quick and easy removal of the identities stored on all systems. The capability of rapid user-provisioning and de-provisioning also allows for a swifter migration from one provider to another (with respect to IAM).
To facilitate a more efficient use of cloud resources the meta-system includes a Single Sign-On (SSO) service for cloud-based services. An individual user will only have to authenticate to the system and he or she will then be authenticated automati-cally to any service on-demand, provided the user has the necessary access rights. The primary advance of this approach is that it gives the client full control over accessing cloud-based services. The client can choose which services can be accessed and what identity related information is send to the service providers. Another advantage of such a system is that the risk of phishing attacks is greatly reduced. The user will only be aware of his or her credentials for the SSO and will not know any of the credentials and authentication methods used in conjunction with cloud services. This approach renders phishing attacks against service providers useless as the user cannot give away informa-tion that he or she is unaware of. The approach only works provided the authenticainforma-tion to the SSO is itself secure.
The specific objective of the thesis (Objective 1) is to design, validate and imple-ment a client-centric SSO that can authenticate a user to any given cloud-based service. A secondary objective (Objective 2) is to enhance the privacy related aspects of the in-teraction between a client and cloud providers. To this end I introduce the concept of
obfuscated and partially obfuscated identities. In Section 1.1 it was mentioned that a service may not require the full birthday to check if a user is over 18 old. Thus the date and month of the user’s birthday can be obfuscated (e.g. replaced by random values). The usage of such obfuscated identities is a decision left to the client as it is in the position to know whether such an identity can be used.
In order to manage identities across multiple providers another secondary objec-tive (Objecobjec-tive 3) is to take into consideration that some identity-related information might change over time. For example a user might change his or her surname after marriage. As such, the system must also make the appropriate changes on the cloud systems whenever such a change is required. It is further desirable to integrate the us-age of open standards for authentication and authorization, such as OpenID [85] and OAuth [123] (Objective 4). The goal is to allow the identity meta-system to act as an identity provider whenever cloud services support these protocols.
To mitigate the thread of misuse by the client’s users another objective (Objective 5) is to introduce a monitoring component to the IAM system. This component will monitor the actions of individual users and, when a misuse scenario is detected, it will dynamically change the access rights of the user.
The last objective (Objective 6) is to design the IAM solution in such a way that it functions either as a standalone system or as an integrated component of a client-centric middleware system. As mentioned in the previous section IAM is only one of the client-side issues that can be mitigated by the introduction of a client-centric middleware.
For future references, the objectives of the thesis are as follows:
Objective 1. Design, validate and implement a client-centric SSO that can authenticate a user to any given cloud-based service.
Objective 2. Enhance the privacy related aspects of the interaction between a client and cloud providers.
Objective 3. Take into consideration that some identity-related information might change over time, thus the identity attributes must be synchronized.
Objective 4. To incorporate the usage of open standards for authentication and autho-rization, such as OpenID [85] and OAuth [123].
Objective 5. Design a monitoring component to the IAM system, mitigating the threat of the misuse of services.
Objective 6. Design the IAM solution in such a way that it functions either as a stan-dalone system or as an integrated component of a Client-Cloud Interaction Middleware (CCIM).
1.3 Outline
The remainder of this thesis is structured as follows:
Chapter 2 provides a literature review for identity management in the area of cloud computing. Section 2.1 introduces key notions about cloud computing while IAM is described in Section 2.2. A literature review focusing on the IAM in cloud computing is provided in Section 2.3. Finally, Section 2.4 details existing IAM client-centric approaches for cloud computing.
Chapter 3 represents a description of the client-centric approach to IAM in cloud computing. The chapter argues the necessity of a client-centric approach (Section 3.1), focusing on the issues surrounding IAM, cloud computing and the interactions between client and cloud providers with respect to IAM. The specific objective of the thesis is to design, validate and implement a SSO that can authenticate users to cloud services. In Section 3.2 the client-centric SSO, dubbed the Identity Management Machine (IdMM), is introduced. To illustrate the advantages of the IdMM two use cases are proposed in Section 3.3. The first use case (Section 3.3.1) illustrates the usage of the standalone version of the IdMM while the second use case (Section 3.3.2) details the usage of the IdMM as part of the CCIM.
The design of the IdMM is described in detail in Chapter 4. This chapter covers the design part of Objective 1 as well as objectives 2-5. The specification of the IdMM-Core (Section 4.2), IdMMClient (Section 4.3), IdMMCloud (Section 4.4) and IdMMUser (Section 4.5) agents allows for the automatic authentication of users to cloud-based services. Section 4.6 introduces the IdMMProtocol agent allowing the IdMM to act as an identity provider for the OpenID protocol, fulfilling Objective 4. Objectives 5 is fulfilled with the introduction of the IdMMProvisioningagent in Section 4.7. The IdMM-Provisioningagent will perform attribute synchronization, ensuring that the identity related information stored on cloud services is up to date. Finally, Objective 3 is fulfilled by the introduction of the IdMMMonitoring agent.
The sixth objective of the thesis is to design the IdMM in such a way that it func-tions either as a stand-alone system or as an integrated component of a client-centric middleware system. While Chapter 4 describes the stand-alone system, Chapter 5 de-scribes the IdMM as a integrated component of a Client-Cloud Interaction Middleware (CCIM).
The validation and implementation part of Objective 1 are covered in Chapter 6. First, the validation of the IdMM specifications is provided in Section 6.1. A browser-based stand-alone proof of concept implementation of the IdMM is detailed in Sec-tion 6.2. In SecSec-tion 6.3 the two versions of the IdMM are compared with existing IAM software solutions for cloud services.
Finally, I give my conclusions and discuss what is left open in Chapter 7. Since the specification of the IdMM was performed using the Abstract State Machine (ASM) method, Appendix A details the concept of ASMs (Section A.1) as well as the Core-ASM project (Section A.2). The full specification of the IdMM is then provided in Appendix B.
1.4 Chapter Summary
This chapter represents the introductory chapter of the thesis. The motivation behind the research is described in Section 1.1. Section 1.2 describes the main objectives of the thesis: to design, validate and implement a client-centric SSO that can authenticate a user to any given cloud-based service (Objective 1), while enhancing the privacy related aspects of the interaction between a client and cloud providers (Objective 2), taking into consideration that some identity-related information might change over time (Objective 3), incorporating the usage of open standards for authentication and authorization (Ob-jective 4), to design a monitoring component to the IAM system (Ob(Ob-jective 5) and to design the IAM solution in such a way that it functions either as a standalone system or as an integrated component of a Client-Cloud Interaction Middleware (CCIM) (Objec-tive 6). Finally, Section 1.3 outlines the structure of the rest of the thesis.
Literature Review
This chapter provides a literature review, highlighting the state-of-the-art in the fields relevant to this thesis. As the topic of the thesis is ’Client-Centric Identity and Access Management in Cloud Computing’ the chapter is structured in four separate sections. Section 2.1 provides an introduction into the basic concepts of cloud computing. The concepts of Identity and Access Management (IAM) are then introduced in Section 2.2. Section 2.3 describes the existing literature for IAM within the area of cloud computing. Finally, Section 2.4 highlights the existing state-of-the-art with respect to client-centric approaches for IAM in the area of cloud computing.
2.1 Cloud Computing
According to the National Institute of Standards and Technology (NIST) cloud com-puting is "a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction" [74]. Cloud computing has a num-ber of essential characteristics:
On-demand self-service. Cloud services allow customers to automatically pro-vision computing capabilities. This means that clients can deploy and utilize services without the need for human interaction.
Broad network access. Cloud providers offer services that are accessed on the network via the use of a variety of mechanisms like traditional networking layer standards as well as other thin layer network protocols such as mobile phones, laptops or PDAs.
Resource pooling. Resource pooling defines the provider’s capability to use a multi-tenant model to pool resources for multiple clients. A cloud’s infrastructure is designed to efficiently pool together resources from various clients. As such, the clients themselves are not aware of the underlying infrastructure (e.g. clients may not know the location where data is being stored or processed).
Rapid elasticity. Rapid elasticity defines the provider’s ability to rapidly scale resources. From a client’s perspective this has the effect of having seemingly unlimited resources.
Measured service. Cloud providers measure the resources used by clients both for scalability as well as monetary purposes (e.g. billing clients). Providers mon-itor certain resource parameters (such as bandwidth, processing or storage) and use this measurements to offer pay-per-use business models.
Cloud-based models can be deployed in one of four forms: private clouds, com-munity clouds, public clouds and hybrid clouds. In private clouds the infrastructure is designed for the use of a single organization. The infrastructure is either kept on-premise, by the organization, or off-on-premise, in which case the infrastructure may or may not be owned by the organization. Community clouds are used by several organi-zations with shared interests. As with private clouds, only the organiorgani-zations have access to the infrastructure, which can be owned by one or more of the organizations or can be offered by a third party. Public clouds can be used by anybody. The infrastructure is offered by providers usually on a pay-per-use model. Finally, hybrid clouds are a mixture of the previous cloud models. Parts of the infrastructure are available to the general public while others are available only for certain organizations. Hybrid clouds are often used by organizations that require higher data processing, where by the use of standardized technology they can outsource to public clouds via the use of cloud burst-ing. Cloud bursting represents the process by witch cloud providers can use resources from external providers, for limited time periods, with the aim of scaling out their in-frastructure [79]. Cloud bursting is often used by smaller private cloud providers when their own infrastructure reaches peak capacity (e.g. during workload peaks). To ensure the requirements specified in the Service-Level Agreements (SLAs) the provider would typically rent resources from other cloud providers.
Cloud computing resources are offered to clients via the use of a number of serv-ice models. Figure 2.1 details the three main servserv-ice models. To offer clients access to the cloud’s resources cloud providers maintain an internal infrastructure, which can-not be accessed by clients. This infrastructure consists of the facilities and hardware used by cloud providers together with the software mechanisms required for resource pooling and providing clients with an abstraction of the infrastructure.
Infrastructure as a Service (IaaS) allows clients to be allocated a set of process-ing, storage, networks and other computing resources. The client is then allowed to deploy arbitrary code on these resources. As shown in Figure 2.1, IaaS is comprised of the set of APIs, storage and computing services that clients have access to. These services are interconnected via the use of custom network services offered by cloud providers. An example of such a service model is the Amazon Elastic Compute Cloud (Amazon EC2) where clients are allowed to create Virtual Machine (VM) instances and deploy customized software on them [5]. For storage, Amazon offers the Amazon Simple Storage Service (Amazon S3) [4]. While clients can choose to use Amazon EC2 or Amazon S3 separately, Amazon also offers the Amazon Web Services (Ama-zon AWS) [3] consisting of the entire package of APIs, computing, storage and network services.
Platform as a Service (PaaS) is a service model that allows clients to deploy ap-plications using predefined languages and libraries that are supported by the cloud pro-vider. Unlike IaaS, the client does not have access to the underlying cloud infrastructure (such as network, servers or operating systems) which is automatically managed by the provider. As Figure 2.1 shows, clients instead have access to a set of services which allow runtime deployment of customized applications using specific programming lan-guage APIs and databases. Microsoft Azure [12] and Google Apps Engine [49] are two example of such services. While Microsoft Azure makes use of the existing Microsoft-based technologies (e.g. C#, .NET framework, Microsoft SQL Server), the Google Apps Engine utilized Java, PHP, Go and a customized MySQL compatible database engine called Cloud SQL. To develop applications for multiple cloud providers, the mOSAIC Project [78] offers tools "to support the design, deployment and execution of service-independent applications as well as the management of resources from multiple Clouds" [90].
Software as a Service (SaaS) is a service model, where the client utilizes an ap-plication offered by the cloud service provider. As shown in Figure 2.1, the client is offered a variety of applications, such as Content Management Systems (CMSs), col-laborative real-time editors, Customer Relationship Management (CRM), mobile and web applications. The customer only has access to the functionalities of the appli-cations and not the underling technologies used by them (i.e. the source code of the applications, the PaaS or IaaS services used by the applications). Examples of SaaS include Google Apps for Business [47] (which offers professional email, online stor-age, shared calendars, video meetings, etc.), Microsoft Office 365 [76] (which offers the functionality of the Microsoft Office suite but with the added mobility of the cloud) and Fabasoft Cloud [38] (offering an array of business-to-business collaboration and file sharing tools).
Cloud computing offers clients, especially businesses, many advantages: lower IT infrastructure costs, reduced need for training personnel and increased productiv-ity [53]. The cloud’s high scalabilproductiv-ity and seemingly infinite resources coupled with its on-demand pay-for-use model entails lower costs for clients. The client does not need to invest in a off-premise infrastructure. In addition to this cloud computing can save clients money by reducing the need for training. PaaS developers, for example, do not need to be trained in deploying applications and installing local servers, as this is done automatically by the cloud services. Cloud computing also increases the productivity and quality of a business by offering collaborative tools, better usage of information,
better manageability and a better quality of IT provision. The advantages presented above make cloud computing services more attractive to businesses, especially to Small and Medium Enterprises (SMEs) [37].
The adoption of cloud-based services also comes with certain disadvantages: loss of governance, provider lock-in, isolation failure, other technical and legal issues [36] as well as performance problems from the massive transfer of data to and from the cloud [112]. For security and privacy, the Cloud Security Alliance [31] describes the top threats as the following: abuse and nefarious use of cloud computing, insecure interfaces and APIs, malicious insiders, shared technology issues, data loss or leakage, account or service hijacking, unknown risk profile.
2.2 Identity and Access Management
Identity and Access Management (IAM) is a field of IT security dealing with the man-agement of digital identities and the provisioning of privileges and access rights to those identities within the scope of an organization. The purpose of IAM systems is to offer organisations an automated, often centralized, software system that mainly handles:
• The creation (provisioning) and deletion (de-provisioning) of identities. • The management of identity-related data (attributes).
• Secure authentication, authorization and auditing means.
• The privileges of identities across system and enterprise boundaries.
2.2.1 Identity Management
According to Chong identity and access management is defined as “the processes, tech-nologies and policies for managing digital identities and controlling how identities can be used to access resources” [30]. The three main technological components of IAM identified by Chong [30] are: identity life cycle management, access management and directory services.
Identity life cycle management entails the creation, usage and deletion of iden-tities, each element posing numerous challenges. According to ISO/IEC 24760-1 an identity “is the information used to represent an entity in an ICT system. The purpose of the ICT system determines which of the attributes describing an entity are used for an identity” [58]. Chong [30] categorizes the attributes of an identity into four types (Figure 2.2):
Identifiers. Unique information that identifies the entity within a given context (e.g. uid or username).
Credentials. Information used to assert the authenticity of an identity claim (e.g. password).
Core attributes. The information describing the identity (e.g. name, date of birth).
Context-specific attributes. Information that describes an identity within a spe-cific context (e.g. address, credit card number).
Figure 2.2: Example of an identity
Identity directories represent the backbone of any IAM system. They provide means by which identity-related data is securely stored and organized. Directories store and manage the attributes of identities and also provide the means to enforce security and access policies for identities. A survey of existing identity directories and IAM solutions is presented by Madhan and Rodrigues [71]. The survey compares five IAM systems: IBM Tivoli Identity Manager, Novell Identity Manager, Sun Java System Iden-tity Manager, Oracle IdenIden-tity Management and CA IdenIden-tity Manager. The systems are compared with respect to features, capabilities, strategy and vision factors.
Mather et al. [72] also describe the concepts of identity and access management, defining the following main processes: user management, authentication management, authorization management and privileges, access management, data management and provisioning and monitoring and auditing. The processes described in Mather et al. [72] have the following operational activities: provisioning, credential management, entitle-ment manageentitle-ment, compliance manageentitle-ment, identity federation manageentitle-ment and cen-tralization of authentication and authorization.
Provisioning entails the creation of identities in IAM systems and giving the iden-tifies access to certain resources. De-provisioning in the process of removing access and identities from such systems. Credentials management refers to the life cycle of the credentials used by identities. Entitlement management refers to access management while compliance management ensures the monitoring of the access rights for auditing purposes.
Cameron [25] introduces seven laws of identity which he claims are essential for any IAM system:
L.1 User Control and Consent. Any IAM system must ask a user for his or her permission before processing information related to the identities of the user.
L.2 Minimal Disclosure for a Constrained Use. An IAM system should only expose the minimal information required for the use of a service.
L.3 Justifiable Parties. Only trusted parties who have a need for the identity-related information should be offered the information.
L.4 Directed Identity. An IAM system must use of omni-directional and unidi-rectional identifiers to facilitate the use of both public and private identities. L.5 Pluralism of Operators and Technologies. An IAM system must
sup-port interoperability with multiple external identity providers and relying parties.
L.6 Human Integration. The system must ensure adequate human-machine interaction to avoid identity-based attacks like phishing.
L.7 Consistent Experience across Contexts. An IAM system must support multiple providers and technologies while at the same time offering the user a uniform experience.
The seven laws introduced by Cameron [25] should be part of any IAM system. Cameron [25] argues that the laws presented above need to obeyed, otherwise “we cre-ate a wake of reinforcing side-effects that eventually undermine all resulting technol-ogy. The result is similar to what would happen if civil engineers were to flout the law of gravity” [25]. The proposed client-centric IAM meta-system obeys the laws proposed by Cameron. If the client can be regarded as a user, the meta-system respects L.1, L.2, L.3 by letting the client choose what data to send to cloud providers. L.5 is respected by the use of a Single Sign-On (SSO) service and by the fact that the meta-system will act as an identity provider, allowing for directed identities. The SSO service also means the system respects L.5, L.6 and L.7.
In contrast to the laws introduced by Cameron [25], Dhamija and Dusseault [34] introduce seven flaws that are often present in identity management:
F.1 Identity management is not a goal in itself. IAM systems are used as part of services. While providers offer IAM services the services themselves are not the means to an end. They can and will be used in conjunction with other services to achieve the requirements of clients.
F.2 Cognitive scalability is as important as technical scalability. While ap-plications and services can scale, the cognitive abilities of users cannot. This means that users are often overwhelmed by the number of usernames, passwords and communication identifiers.
F.3 Users follow the path of least resistance. When technology interferes with the goal of users they often tend to ignore oblivious security warnings, creating ’shortcuts’ to minimize the time related to achieving their goals. F.4 User consent could lead to maximum information disclosure. The trend
of users following the path of least resistance also means that they are more likely to offer more information than required instead of spending the time to understand the security and privacy issues surrounding the information. F.5 We need mutual authentication (not just user authentication). There
exists a need for authentication mechanisms not just for the user but also for identity providers and relying parties.
F.6 RPs want to control the customer experience. Relying parties (service providers) often tend to control the experience of customers for reasons such as usability, portability and security. This involves asking the user for more information than is required by the service, thereby reducing privacy. In addition, this need leads providers to ignore the benefits of identity fed-eration and endorses the implementation of their custom IAM systems. F.7 Trust must be earned (and is hard for users to evaluate). It is very hard
organiza-tion can ensure that a system is completely trustworthy.
2.2.2 Access Management
Access Management is the process of allowing identities access to specific resources. This process entails a combination of first authenticating and then authorizing an tity for a given resource. Authentication represents the process of confirming the iden-tity of an eniden-tity within a system. Authorization entails the determination of the priv-ileges of an entity with respect to the execution of certain operations. In addition to authenticating and authorizing identities, IAM systems also provide means of auditing. Auditing represents the reviewing of authentication, authorization and general activity records to determine the compliance of IAM systems with respect to security and access policies and to identify potential breaches in security services.
Access Control Models
To enforce access control policies various access control models have been developed. Several such models are described below. For the purpose of this thesis the RBAC access control model will be described in more detail.
Mandatory Access Control (MAC), first introduced by Bell and LaPadula [15], restricts resources based on a set of fixed attributes. The term mandatory is derived from the fact that users cannot modify the values. Such an access control model is required when the security policies of the system dictate that the owner is not allowed make authorization decisions and is often seen in defence or government systems.
Discretionary Access Control (DAC) models restrict access to resources based on the identity, processes or groups to which the user belongs. Unlike MAC, users are capable of granting other users access to resources. For example, the owner of a folder in Microsoft Windows is able to grand access to other users or groups.
Identity Based Access Control (IBAC) models work by associating permissions to an identity’s unique identifier. Access to a resource is granted if and only if the as-sociation between the permissions and the identifier exists. One example of an IBAC model is the use of Access Control Lists (ACLs). An ACL contains a list of identities together with their permissions (access rights) for a resource. An identity is allowed access to the resource if their identifier is contained within this list. ACLs are often used in operating systems and network security services because they are easy to im-plement. It must be noted, however, that there are drawbacks with IBACs models. Such models are hard to maintain, when the number of identities increases and access control decisions are not based on any business functions or characteristics of identities rather just on the unique identifiers.
Lattice Based Access Control (LBAC) we first developed in the 1970 to deal with the confidentiality of military information [107]. “Under an LBAC, a totally ordered set of security labels (e.g., TS > S > C > U) are combined with a set of categories (e.g., X, Y, Z) to form a ’lattice’, allowing for the representation of a set of security classes ranging from system-low to system-high using a much smaller number of security labels” [137]. One of the drawbacks of LBAC is that it is only manageable, when there are few security labels and categories making it effective for coarsely-grained security scenarios.
Yuan and Tong [137] introduce an Attribute Based Access Control (ABAC) model for web services consisting of a policy model (defying the ABAC policies) and an ar-chitecture model (responsible for the enforcement of the ABAC policies for web serv-ices). Unlike IBAC or RBAC, ABAC model defines permission on any security-relevant characteristics or attributes. Yuan and Tong define three classes of attributes: subject attributes (attributes belonging to an entity/identity), resource attributes (attributes that belong to the resource used by the subject) and environment attributes (attributes de-scribing the operational, technical or the context in which information access occurs). Roles and identities are treated as attributes allowing the ABAC model to encompass the functionalities of IBAC and Role-Based Access Control (RBAC).
Role-Based Access Control (RBAC)
According to Ferraiolo and Kuhn Role-Based Access Control (RBAC) models “pro-vide a means of naming and describing relationships between individuals and rights, providing a method of meeting the secure processing needs of many commercial and civilian government organizations” [42]. RBAC gives access to resources based on the business function (or role) of an identity. As shown in Figure 2.3, roles represent a set of operations that one or more identities can perform. In Figure 2.3 Alex is shown as being a member of both role 1 and 2 and can perform operations on all resources. Bob is a member of role 1 and thus can perform operations only on resources A and B.
Figure 2.3: Flat RBAC Model
Ferraiolo and Kuhn [42] provide a formal description of RBAC. They consider identities as subjects and operations as transactions. They define the active role of a subject as AR(s). A subject may have one or more authorized roles, RA(s), with each role authorized to perform one or more transactions. TA(s). The predicate exec(s,t) defines whether a subject can execute a transaction.
AR(s : sub ject) = the active role f or sub ject s RA(s : sub ject) = authorized roles f or sub ject s TA(r : role) = transactions authorized f or role r
With the roles, subjects and transactions specified Yuan and Tong [137] define three basic rules:
∀s : sub ject, t : tran, (exec(s,t) ⇒ AR(s) 6= /0) (2.1)
∀s : sub ject, (AR(s) ⊆ RA(s)) (2.2)
∀s : sub ject, t : tran, (exec(s,t) ⇒ t ∈ TA(AR(s))) (2.3) The first rule represents a role assignment meaning that the only way for a subject to execute a transaction is if he or she has been assigned to a role. Rule 2.2 defines a role authorization, meaning that the subject’s active role must be authorized (i.e. part of the set of authorized roles of the subject). Rule 2.3 defines a transaction authorization allowing a subject to execute a transaction only if the transaction is authorized for the specific role.
NIST provides a unified model for RBAC [106]. They provide a four step model increasing the functional capabilities with each step. The four steps are: flat RBAC, hierarchical RBAC, constrained RBAC and symmetric RBAC.
In the flat RBAC model users are assigned to roles and roles are assigned a set of permissions on resources. The assignment of users to roles is a many-to-many relation, meaning that a user can have different roles and a role can have more than one user assigned to it. Figure 2.3 describes a flaw model.
Hierarchical RBAC introduces the concept of role hierarchy. Sandhu et al. [106] define a model where senior roles can inherit permissions from junior roles. Figure 2.4 describes such a model. Both Bob and Alex have access to resource B while Alex (because of role inheritance) has access to resource C. Sandhu et al. also consider two distinct sub-models. The General Hierarchical RBAC model offers support for arbi-trary partial order as a role hierarchy mechanism. The Limited Hierarchical RBAC model imposes some restrictions on the role hierarchy mechanism (such as limiting the hierarchical structure to trees).
Constrained RBAC models offer the possibility of statically or dynamically en-forcing Separation of Duties (SOD). SOD entails dividing tasks and their associated privileges among different users as to prevent a single user from acquiring too much authority. SOD can be divided into two part: static and dynamic SOD.
Symmetric RBAC models add the ability to perform permission-role reviews. This means that the roles assigned to a given permission can be determined. Such a model is often used in distributed IAM systems where maintaining the appropriate per-missions for roles can be problematic because of distributed administrative boundaries.
2.2.3 Federated Identity Management
Federated Identity Management (FIdM) allows for local identities to be shared by pro-viding copies of the information to service providers. FIdM uses a set of protocols and
Figure 2.4: Hierarchical RBAC Model
standards to provide copies of identity-related information to third parties. Three dis-tinct types of FIdM profiles exist: service provider centric, identity provider centric and multi-provider cross domain [91].
In a service provider centric scenario a service provider represents a hub sur-rounded by one or more identity providers. As shown in Figure 2.5, the service provider acts as a relying party accepting identities and their information from the identity pro-viders. Authentication is done at the identity provider side, with the information then relayed via FIdM assertions to the service provider. The system allows organizations to either use or act as identity providers, giving them the means to do user provision-ing and de-provisionprovision-ing. The roles, authorization policies and credentials must then be asserted from the identity provider to the service provider via identity information exchange policies.
Figure 2.5: Service Provider Centric Federated Identity Management
The identity provider centric profile represents the opposite of the service pro-vider centric scenario, as shown in Figure 2.6. The identity propro-vider acts as a central
hub, allowing for a centralized authentication. The methods by which users are authen-ticated to service providers vary according to the security and authentication standards offered by each service provider. Such profiles are often used by large organizations with the system allowing service providers to act as their identity attribute providers by storing and disseminating context-specific attributes pertaining to their users (e.g. user preferences).
Figure 2.6: Identity Provider Centric Federated Identity Management
Multi-provider cross domain FIdM represents a mixture of the other two profiles (Figure 2.7). It allows for scenarios where each organization can act as both identity provider, offering identity assertions, as well as a service provider, consuming identity assertions. The need for such a profile stems from the problems very large organiza-tions have with maintaining several security domains, such as: affiliates, acquisiorganiza-tions, subsidiaries and joint ventures. As such, organizations may have various internal and external authentication and assertion policies. The interaction of entities acting as both identity providers and service providers allows for proper access to resources as well as diminishing the IT and employee complexity (e.g. maintaining multiple passwords).
Figure 2.7: Multi-Provider Cross Domain Federated Identity Management Federated Identity Management systems allows for the sharing of identity-related information by providing copies of the information to third parties. To achieve this task
