ThesisPDF Available

User-controlled Identity Management Systems using mobile devices

Authors:

Figures

Glasgow Theses Service
http://theses.gla.ac.uk/
theses@gla.ac.uk
Ferdous, Md. Sadek (2015) User-controlled Identity Management
Systems using mobile devices. PhD thesis.
http://theses.gla.ac.uk/6621/
Copyright and moral rights for this thesis are retained by the author
A copy can be downloaded for personal non-commercial research or study
This thesis cannot be reproduced or quoted extensively from without first obtaining
permission in writing from the Author
The content must not be changed in any way or sold commercially in any format or
medium without the formal permission of the Author
When referring to this work, full bibliographic details including the author, title,
awarding institution and date of the thesis must be given
USER-CONTROLLED IDENTITY MANAGEMENT
SYSTEMS USING MOBILE DEVICES
MD. SADEK FERDOUS
SUBMITTED IN FULFILMENT OF THE REQUIREMENTS FOR THE DEGREE OF
Doctor of Philosophy
SCHOOL OF COMPUTING SCIENCE
COLLEGE OF SCIENCE AND ENGINEERING
UNIVERSITY OF GLASGOW
JULY, 2015
© MD. SADEK FERDOUS
Abstract
Thousands of websites providing an array of diversified online services have been the crucial
factor for popularising the Internet around the world during last 15 years. The current model
of accessing the majority of those services requires users to register with a Service Provider
- an administrative body that offers and provides online services. The registration procedure
involves users providing a number of pieces of data about themselves which are then stored
at the provider. This data provides a digital image of the user and is commonly known as
the Identity of the user in that provider. To access different online services, users register
at different providers and ultimately end up with a number of scattered identities which
become increasingly difficult to manage. It is one of the major problems of the current
setting of online services. What is even worse is that users have less control over the data
stored in these providers and have no knowledge how their data is treated by providers. The
concept of Identity Management has been introduced to help users facilitate the management
of their identities in a user-friendly, secure and privacy-friendly way and thus, to tackle
the stated problems. There exists a number of Identity Management models and systems,
unfortunately, none of them has played a pivotal role in tackling the problems effectively
and comprehensively.
Simultaneously, we have experienced another trend expanding at a remarkable rate: the con-
sumption and the usage of smart mobile devices. These mobile devices are not only growing
in numbers but also in capability and capacity in terms of processing power and memory.
Most are equipped with powerful hardware and highly-dynamic mobile operating systems
offering touch-sensitive intuitive user-interfaces. In many ways, these mobile devices have
become an integrated part of our day-to-day life and accompany us everywhere we go. The
capability, portability and ubiquitous presence of such mobile devices lead to the core objec-
tive of this research: the investigation of how such mobile devices can be used to overcome
the limitations of the current Identity Management Systems as well as to provide innovative
online services.
In short, this research investigates the need for a novel Identity Management System and the
role the current generation of smart mobile devices can play in realising such a system.
In this research it has been found that there exist different inconsistent notions of many
central topics in Identity Management which are mostly defined in textual forms. To tackle
this problem, a comprehensive mathematical model of Identity and Identity Management
has been developed. The model has been used to analyse several phenomenons of Identity
Management and to characterise different Identity Management models.
Next, three popular Identity Management Systems have been compared using a taxonomy of
requirements to identify the strength and weakness of each system. One of the major findings
is that how different privacy requirements are satisfied in these systems is not standardised
and depends on a specific implementation. Many systems even do not satisfy many of those
requirements which can drastically affect the privacy of a user.
To tackle the identified problems, the concept of a novel Identity Management System, called
User-controlled Identity Management System, has been proposed. This system offers better
privacy and allows users to exert more control over their data from a central location using
a novel type of provider, called Portable Personal Identity Provider, hosted inside a smart
mobile device of the user. It has been analysed how the proposed system can tackle the stated
problems effectively and how it opens up new doors of opportunities for online services.
In addition, it has been investigated how contextual information such as a location can be
utilised to provide online services using the proposed provider. One problem in the existing
Identity Management Systems is that providers cannot provide any contextual information
such as the location of a user. Hosting a provider in a mobile device allows it to access
different sensors of the device, retrieve contextual information from them and then to provide
such information. A framework has been proposed to harness this capability in order to offer
innovative services.
Another major issue of the current Identity Management Systems is the lack of an effective
mechanism to combine attributes from multiple providers. To overcome this problem, an
architecture has been proposed and it has been discussed how this architecture can be utilised
to offer innovative services. Furthermore, it has been analysed how the privacy of a user can
be improved using the proposed provider while accessing such services.
Realising these proposals require that several technical barriers are overcome. For each
proposal, these barriers have been identified and addressed appropriately along with the re-
spective proof of concept prototype implementation. These prototypes have been utilised to
illustrate the applicability of the proposals using different use-cases. Furthermore, different
functional, security and privacy requirements suitable for each proposal have been formu-
lated and it has been analysed how the design choices and implementations have satisfied
these requirements. Also, no discussion in Identity Management can be complete without
analysing the underlying trust assumptions. Therefore, different trust issues have been ex-
plored in greater details throughout the thesis.
Acknowledgements
I would like to thank my supervisor Ron Poet for his continuous guidance and support
throughout this research. He has given me the freedom and the flexibility to explore dif-
ferent avenues and has always encouraged me in a wide variety of research endeavours.
I would also like to thank my second supervisor Gethin Norman for all the interesting and
challenging discussions and for brining a different point of view that helped immensely.
Without his help, it would not be possible to shape this research in its current form.
My heartfelt thanks go to everyone in the School of Computing Science for making it a
delightful place to work and for all the support I received during my PhD. Special thanks to
my colleagues and friends Niaz Morshed Chowdhury and Soumyadeb Chowdhury for many
stimulating discussions and for all the crazy ideas we thought we could explore. I am also
thankful to Dr. Naima Reza, for proofreading this thesis in a very short period of time.
I would like to offer my sincere gratitude to all my family members, especially my mother
Sultana Ferdous, for all the inspiration since my childhood and for helping me throughout
my PhD with lots of encouragement and support. Last but not least, I am eternally indebted
to my wife Farida Chowdhury, who herself is a PhD student, for enduring my miserable self
throughout my PhD and for all the love and care during this long journey. It would certainly
not be possible without her.
This research was funded by the Scottish Informatics and Computer Science Alliance (SICSA)
for which I am extremely grateful.
To my family.
Table of Contents
1 Introduction 1
1.1 Introduction and Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Thesis Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Research Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5 Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.6 Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 Background 9
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Popular Identity Management Systems . . . . . . . . . . . . . . . . . . . . 9
2.2.1 Security Assertion Markup Language (SAML)-based IMS . . . . . 10
2.2.2 OpenID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.3 OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 Dynamic Federation Management . . . . . . . . . . . . . . . . . . . . . . 18
2.4 User-controlled Identity Management Systems . . . . . . . . . . . . . . . . 20
2.5 Context-aware Identity Management . . . . . . . . . . . . . . . . . . . . . 22
2.5.1 Context-aware Authentication . . . . . . . . . . . . . . . . . . . . 22
2.5.2 Context-aware Authorisation . . . . . . . . . . . . . . . . . . . . . 25
2.5.3 Context-aware Authentication and Authorisation . . . . . . . . . . 27
2.5.4 Context-aware Identity Management . . . . . . . . . . . . . . . . . 30
2.6 Attribute Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3 Identity Management: Basic Terminologies and Models 35
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2 Entity, Identity, Identity Management and Other Related Terminologies . . 36
3.2.1 Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2.2 Domain, Application Domain or Identity Domain . . . . . . . . . . 38
3.2.3 Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2.4 Identifiers, Partial Identifiers, Null Identifiers and Credentials . . . 43
3.2.5 Partial Identity and Identity . . . . . . . . . . . . . . . . . . . . . 46
3.2.6 Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.2.7 Anonymity, Anonym and Pseudonym . . . . . . . . . . . . . . . . 48
3.2.8 Digital Identity Model . . . . . . . . . . . . . . . . . . . . . . . . 49
3.3 Identity Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.3.1 Steps in Identity Management Systems . . . . . . . . . . . . . . . 52
3.3.2 Identity Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.3.3 The Basic Identity Management Model . . . . . . . . . . . . . . . 59
3.3.4 Trust Issues in Identity Management . . . . . . . . . . . . . . . . . 59
3.4 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.4.1 Effect of Multiple Partial Identities . . . . . . . . . . . . . . . . . 59
3.4.2 Data Ownership and Controllability . . . . . . . . . . . . . . . . . 62
3.4.3 Analysing Identity Theft . . . . . . . . . . . . . . . . . . . . . . . 63
3.4.4 Modelling Popular Identity Management Models . . . . . . . . . . 65
3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4 Comparative Analysis of Identity Management Systems 75
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.2 A Study of Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.2.1 Functional Requirements (FR) . . . . . . . . . . . . . . . . . . . . 76
4.2.2 Security Requirements (SR) . . . . . . . . . . . . . . . . . . . . . 77
4.2.3 Privacy Requirements (PR) . . . . . . . . . . . . . . . . . . . . . . 78
4.2.4 Trust Requirements (TR) . . . . . . . . . . . . . . . . . . . . . . . 79
4.3 Comparative Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5 Dynamic Identity Federation 83
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.2 Dynamic Federation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.2.1 Trust Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.3 Proof of Concept: Dynamic Management . . . . . . . . . . . . . . . . . . 87
5.3.1 Use-case: Dynamic Federation . . . . . . . . . . . . . . . . . . . . 87
5.3.2 Use-case: Dynamic Defederation . . . . . . . . . . . . . . . . . . 92
5.4 Proof of Concept: Service Provisioning . . . . . . . . . . . . . . . . . . . 96
5.4.1 IdP-SP Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.4.2 IdP-IdP-SP Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6 User-controlled Identity Management Systems 105
6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
6.2 Definitions and Requirement Analysis . . . . . . . . . . . . . . . . . . . . 106
6.2.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
6.2.2 Requirement Analysis . . . . . . . . . . . . . . . . . . . . . . . . 108
6.3 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
6.4 Prototype Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 111
6.4.1 Personal Attribute Store . . . . . . . . . . . . . . . . . . . . . . . 112
6.4.2 Identity Provider Component . . . . . . . . . . . . . . . . . . . . . 112
6.4.3 Implementation Challenges . . . . . . . . . . . . . . . . . . . . . 113
6.4.4 SAML Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . . 115
6.4.5 OpenID Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 119
6.5 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
6.5.1 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . 121
6.5.2 Security Requirements . . . . . . . . . . . . . . . . . . . . . . . . 126
6.5.3 Privacy Requirements . . . . . . . . . . . . . . . . . . . . . . . . 129
6.5.4 Trust Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 129
6.6 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
6.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
7 Context-aware Federated Services using PPIdP 132
7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
7.2 Context-aware Identity Management . . . . . . . . . . . . . . . . . . . . . 133
7.3 Requirement Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
7.4 CAFS Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
7.5 Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
7.5.1 Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
7.5.2 Use-Case: SP1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
7.5.3 Use-Case: SP2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
7.6 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
7.6.1 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . 148
7.6.2 Security Requirements . . . . . . . . . . . . . . . . . . . . . . . . 148
7.6.3 Privacy Requirements . . . . . . . . . . . . . . . . . . . . . . . . 149
7.6.4 Trust Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 149
7.7 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
7.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
8 Attribute Aggregation in Federated Identity Management 153
8.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
8.2 Attribute Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
8.2.1 Taxonomy of Attribute Aggregation Models . . . . . . . . . . . . . 155
8.2.2 Aggregation at an SP . . . . . . . . . . . . . . . . . . . . . . . . . 156
8.2.3 Aggregation at an IdP . . . . . . . . . . . . . . . . . . . . . . . . 158
8.2.4 Aggregation at a Client . . . . . . . . . . . . . . . . . . . . . . . . 159
8.2.5 Comparative Analysis . . . . . . . . . . . . . . . . . . . . . . . . 159
8.3 The State of the Art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
8.3.1 SAML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
8.3.2 OpenID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
8.3.3 OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
8.4 The Hybrid Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
8.4.1 Requirement Analysis . . . . . . . . . . . . . . . . . . . . . . . . 165
8.4.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
8.4.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
8.5 Use-cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
8.5.1 Use-case 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
8.5.2 Use-case 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
8.5.3 Use-case 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
8.6 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
8.6.1 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
8.6.2 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
8.6.3 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
8.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
9 Conclusions 188
9.1 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
9.2 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
9.3 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
References 195
List of Tables
4.1 Functional and Security Requirements. . . . . . . . . . . . . . . . . . . . . 81
4.2 Privacy and Trust Requirements. . . . . . . . . . . . . . . . . . . . . . . . 81
6.1 Different properties of the used NFC card. . . . . . . . . . . . . . . . . . . 125
7.1 Attributes required for each page . . . . . . . . . . . . . . . . . . . . . . . 140
7.2 Comparison of CAFS with existing works. . . . . . . . . . . . . . . . . . . 151
8.1 Aggregation Models: Strengths and Weaknesses. . . . . . . . . . . . . . . 160
9.1 Functional and Security Requirements. . . . . . . . . . . . . . . . . . . . . 192
9.2 Privacy and Trust Requirements. . . . . . . . . . . . . . . . . . . . . . . . 192
List of Figures
2.1 Protocol flow in SAML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Protocol flow in OpenID without exchanging keys. . . . . . . . . . . . . . 14
2.3 Protocol flow in OAuth. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1 The relation between the user, identifier and the partial identifiers. . . . . . 46
3.2 The (total) identity of an entity. . . . . . . . . . . . . . . . . . . . . . . . . 46
3.3 Current identity space. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.4 SILO Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.5 Representation of the SILO Model. . . . . . . . . . . . . . . . . . . . . . . 67
3.6 Federated Identity Domain. . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.7 Representation of the Federated Model. . . . . . . . . . . . . . . . . . . . 70
3.8 Open Unfederated Identity Model. . . . . . . . . . . . . . . . . . . . . . . 72
3.9 Representation of the OUI Model. . . . . . . . . . . . . . . . . . . . . . . 73
4.1 Taxonomy of core requirements for Identity Management Systems. . . . . . 76
5.1 Protocol flow for a dynamic federation. . . . . . . . . . . . . . . . . . . . 89
5.2 Additional text fields at the WAYF. . . . . . . . . . . . . . . . . . . . . . . 90
5.3 Code generate page at the IdP. . . . . . . . . . . . . . . . . . . . . . . . . 90
5.4 Generated code at the IdP. . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.5 Entering values at the WAYF. . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.6 Added IdP at the WAYF. . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.7 Protocol flow for a dynamic defederation. . . . . . . . . . . . . . . . . . . 93
5.8 Removing an SP at the IdP. . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.9 Protocol flow for dynamic update. . . . . . . . . . . . . . . . . . . . . . . 95
5.10 Metadata update page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.11 Protocol flow for IdP-SP service provisioning. . . . . . . . . . . . . . . . . 98
5.12 Attributes to be released at the Consent page. . . . . . . . . . . . . . . . . 99
5.13 Protocol flow for IdP-IdP-SP service provisioning. . . . . . . . . . . . . . 101
5.14 Initially, one authentication source Username/password at the IdP. . . . . . 102
5.15 Linked untrusted IdP as the authentication source in the Proxy IdP. . . . . . 102
6.1 Architecture of the PPIdP. . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
6.2 Main control panel of the PAS. . . . . . . . . . . . . . . . . . . . . . . . . 113
6.3 Main control panel of the IdP. . . . . . . . . . . . . . . . . . . . . . . . . . 113
6.4 PIF Type 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
6.5 PIF Type 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
6.6 Protocol flow in SAML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
6.7 Released attributes in Type 1 Federation. . . . . . . . . . . . . . . . . . . . 118
6.8 Two authentication sources at the trusted IdP. . . . . . . . . . . . . . . . . 118
6.9 PIF Type 2 Protocol flow in SAML. . . . . . . . . . . . . . . . . . . . . . 119
6.10 LoA 1 for attributes from the PPIdP. . . . . . . . . . . . . . . . . . . . . . 119
6.11 LoA 2 for attributes from the trusted IdP. . . . . . . . . . . . . . . . . . . . 119
6.12 OpenID service access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
6.13 Logged transactions at the PAS. . . . . . . . . . . . . . . . . . . . . . . . 122
6.14 Attribute synchronisation at PAS. . . . . . . . . . . . . . . . . . . . . . . . 122
6.15 Identity space with the PPIdP. . . . . . . . . . . . . . . . . . . . . . . . . 130
7.1 A simpler architecture of XACML. . . . . . . . . . . . . . . . . . . . . . . 136
7.2 CAFS Type 1 Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . 138
7.3 CAFS Type 2 Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . 138
7.4 Scanning a QR code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
7.5 Homepages of Service Providers. . . . . . . . . . . . . . . . . . . . . . . . 141
7.6 Protocol flow for accessing the Page1.php. . . . . . . . . . . . . . . . . . . 143
7.7 Releasing location attributes at the PPIdP. . . . . . . . . . . . . . . . . . . 144
7.8 Protocol flow for accessing the Page3.php. . . . . . . . . . . . . . . . . . . 145
7.9 The consent form at the Proxy IdP allowing the user to combine attributes. . 146
7.10 Combined attributes from the Proxy IdP and the PPIdP. . . . . . . . . . . . 147
8.1 A single assertion containing all profiles (attributes). . . . . . . . . . . . . 155
8.2 A single assertion containing all assertions. . . . . . . . . . . . . . . . . . 155
8.3 Taxonomy of Attribute Aggregation Models. . . . . . . . . . . . . . . . . . 156
8.4 Application Database Model. . . . . . . . . . . . . . . . . . . . . . . . . . 157
8.5 SP-Mediated Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
8.6 Linking Service Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
8.7 Identity Federation/Linking Model. . . . . . . . . . . . . . . . . . . . . . . 158
8.8 Identity Proxying Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
8.9 Identity Relay Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
8.10 Yahoo Login screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
8.11 Google Login screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
8.12 LiveJournal Login screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
8.13 myopenid Login screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
8.14 VeriSign Login screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
8.15 Facebook Authorisation screen. . . . . . . . . . . . . . . . . . . . . . . . . 164
8.16 Linkedin Authorisation screen. . . . . . . . . . . . . . . . . . . . . . . . . 165
8.17 Twitter Authorisation screen. . . . . . . . . . . . . . . . . . . . . . . . . . 165
8.18 Architecture of Hybrid Model. . . . . . . . . . . . . . . . . . . . . . . . . 167
8.19 The usual consent form. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
8.20 The modified consent form. . . . . . . . . . . . . . . . . . . . . . . . . . . 169
8.21 The data structure for the attribute list. . . . . . . . . . . . . . . . . . . . . 170
8.22 The requested attributes at the consent form. . . . . . . . . . . . . . . . . . 172
8.23 Protocol flow for Use-case 1. . . . . . . . . . . . . . . . . . . . . . . . . . 174
8.24 Aggregated attributes from two IdP at the consent form. . . . . . . . . . . . 176
8.25 Released attributes from multiple IdPs in a single SP session. . . . . . . . . 177
8.26 Protocol flow for Use-case 2. . . . . . . . . . . . . . . . . . . . . . . . . . 178
8.27 Encrypted assertion as the attribute in the consent page. . . . . . . . . . . . 179
8.28 Protocol flow for Use-case 3. . . . . . . . . . . . . . . . . . . . . . . . . . 181
8.29 Filtered out non-SAML IdPs. . . . . . . . . . . . . . . . . . . . . . . . . . 182
8.30 Consent form at the PPIdP. . . . . . . . . . . . . . . . . . . . . . . . . . . 182
8.31 Available IdP at the PPIdP. . . . . . . . . . . . . . . . . . . . . . . . . . . 182
8.32 Aggregated attributes at the PPIdP. . . . . . . . . . . . . . . . . . . . . . . 183
1
Chapter 1
Introduction
1.1 Introduction and Motivation
Currently there are millions of websites around the world providing a plethora of different
online services (also known as web-based services or simply web services). These services
are accessed via the Internet using different protocols. Originally, the protocols for digi-
tal communication were designed to exchange information efficiently and reliably. At that
budding stage, the identities of communicating parties could be assumed, and there was no
need to verify these formally. This led to the omission of an Identity Layer in these pro-
tocols for the formal verification of the identity of a user [1]. As the web and web-based
services evolved, the verification of a user’s identity became crucial, particularly for a Ser-
vice Provider (SP; the administrative body that offers and provides services) which needs to
identify users in order to provide the relevant services only to the authorised users.
To overcome this limitation, the process of authentication was subsequently added which
became an integrated part of web services. The authentication process is preceded by the
process of Registration which involves users providing data about themselves which is then
stored at the respective SP. The data regarding a user portrays the digital image of the user
in a provider and is commonly known as the Identity of the user in that SP. With the rapid
expansion of the Internet from the 1990s, the number of web services, as well as the user-
base, was expanding rapidly with more and more identities being created, and as a result
their management became challenging, both for SPs and for users. Identity Management
(IdM, in short) was introduced by the industry to facilitate online management of user iden-
tities. Different groups worked on their own projects resulting in various incompatible IdM
solutions. Additionally, several research initiatives in academia were undertaken leading to
different prototypes of Identity Management Systems. Many of these systems not only differ
in their architectures but also use different protocols and serve different purposes. They are
extensively used by organisations to provide online services. Among them, the popular sys-
1.1. Introduction and Motivation 2
tems are mature and stable in their functionalities and provide services in a secure manner;
unfortunately, they fail to comply with a number of different privacy requirements. More-
over, when a novel SP emerges in the landscape of online services, a new identity is issued
to the user. The after effect is that the user ends up with a number of identities scattered
across multiple SPs. The management of these identities becomes increasingly difficult for
any single user as the number of SPs keeps increasing. Furthermore, users have less control
over their data which are stored at different providers and lack knowledge regarding how
their data is being treated.
Simultaneously, we have experienced another trend expanding at a remarkable rate the con-
sumption and the usage of mobile devices including smartphones and tablets. In 2014, there
were nearly 7 billion mobile subscribers around the world which is 95.5% of the world popu-
lation [2]. In 2013, nearly 1 billion smartphones were sold and for the first time smartphones
outsold feature phones (non smartphones) [2]. Also, the sale of other smart mobile devices
such as tablets are rising steadily with almost 200 million tablets sold in 2013 [2]. Most
of these mobile devices are being used to access the Internet which has contributed to the
increase in global mobile data traffic by 69% in 2014 and the forecast was that the global
mobile data traffic would increase 10-fold between 2014 to 2019 [3]. Another compelling
fact is that mobile devices are not only growing in numbers but also in capability and capac-
ity in terms of processing power and memory. Most are equipped with powerful hardware
and highly-dynamic mobile operating systems offering touch-sensitive user-interfaces. In
many ways, these mobile devices have become an integrated part of our day-to-day life and
accompany us everywhere. It is fascinating to note the evolution of the mobile device during
its short span of life, compared to the Personal Computer (PC). From a mere telecommuni-
cation device to an all-round multimedia gadget, mobile devices are rapidly reaching a point
where the services of telecommunications, media and information technology are converg-
ing seamlessly. The portability, power, intuitive software and ubiquitous presence of mobile
devices lead to the core objective of this research: the investigation of how such mobile de-
vices can be used to overcome the limitations of current Identity Management Systems as
well as to provide and consume innovative online services.
This thesis investigates the need for a novel Identity Management System that offers better
privacy and allows users to have more control over their data from a central location. Addi-
tionally, the thesis investigates the role that the current generation of smart mobile devices
can play in realising such a system. This thesis argues and shows evidence that the existing
Identity Management Systems have limitations regarding different aspects of privacy and do
not allow users to have complete control over their own data. Furthermore, the manage-
ment of different scattered identities will become more and more difficult for any user as she
accesses more novel online services. There exists a notion of User-centric Identity Manage-
ment in the literature that has been proposed to tackle these problems [4]. In reality, findings
1.2. Thesis Statement 3
in this thesis suggest that the existing systems based on the concept of User-centric Identity
Management do little to improve the situation and the privacy problems are still prevalent.
Hence, in this thesis, a novel Identity Management System, called the User-controlled Iden-
tity Management System, is proposed. The proposed system allows users to have complete
control over their own data and to improve the privacy of the user while accessing online
services.
To realise such a system, a proposal for a novel Identity Provider (IdP in short and IdPs in plu-
ral) which is hosted inside a user’s smart mobile device is put forward. This thesis explores
the ways the power and novel capabilities of these devices can be harnessed to implement the
proposal of a novel Identity Provider and the User-controlled Identity Management System.
In addition, the thesis also outlines the additional benefits such a system offers and how such
benefits can be utilised to offer innovative online services. No discussion in Identity Man-
agement can be complete without analysing the underlying trust assumptions. Therefore,
different trust issues have been explored throughout the thesis.
1.2 Thesis Statement
The statement of this thesis is that smart mobile devices can be used to realise the novel
User-controlled Identity Management System which will:
1. tackle several outstanding shortcomings, especially regarding privacy, in existing Iden-
tity Management Systems,
2. offer users complete control over their data from a central location, and
3. provide additional functionalities that can be utilised to offer innovative online ser-
vices.
Since each Identity Management System is bound by a set of trust assumptions, realising
the User-controlled Identity Management System using mobile devices will also require the
formulation of a set of trust assumptions that must be satisfied by the system.
1.3 Research Objectives
The core research goals of this thesis are to identify the shortcomings of existing Identity
Management Systems, to rectify these shortcomings by proposing, designing and developing
a novel Identity Management System and investigating how such a system can be used to
1.3. Research Objectives 4
provide innovative online services. To achieve these goals, the following research objectives
have been formulated.
Research Objective 1 (RO1): Building a consistent vocabulary for Identity Manage-
ment. The first objective is to review the existing work and literature on Identity Manage-
ment in order to compile a consistent vocabulary. Different projects have assumed different
interpretations of many similar topics related to Identity Management which introduce incon-
sistencies. To ensure consistency throughout the thesis, it is essential to build up a vocabulary
related to Identity and Identity Management.
Research Objective 2 (RO2): Mathematical Modelling of Identity Management. The
second objective is to develop a mathematical model of Identity and Identity Management.
As mentioned earlier, there remains an inconsistency in different central topics of Identity
Management. The main reason behind this inconsistency is the lack of a mathematical model
on the core issues of Identity and Identity Management. To tackle this, a formal mathematical
model of Identity and Identity Management has been developed.
Research Objective 3 (RO3): Comparative Analysis of existing Identity Management
Systems. The third objective is to compile a set of requirements of an ideal Identity Man-
agement System. This set of requirements will be used to provide a comparative analysis of
a few popular existing Identity Management Systems and to identify the strength and weak-
ness of each system. Based on the result of the analysis, a system will be chosen for the
subsequent research.
Research Objective 4 (RO4): User-controlled Identity Management System. The fourth
objective is to propose a User-controlled Identity Management System that will be used to
rectify different problems in existing systems.
Research Objective 5 (RO5): Framework for Context-aware Federated Services. The
fifth objective is to propose a framework that will combine two popular trends of online ser-
vices, context-awareness and federated services, using the proposed User-controlled Identity
Management System.
Research Objective 6 (RO6): Attribute Aggregation in Federated Services. The sixth
objective is to propose an improved architecture for attribute aggregation in federated ser-
vices and to investigate how it can handle different privacy issues using the proposed Identity
Management System.
Among these objectives, the first three (RO1 - RO3) are for developing terminologies related
to IdM based on mathematical principles and for identifying shortcomings in the existing
systems. The fourth objective (RO4) is to propose a system to tackle the identified shortcom-
ings. The final two objectives (RO5 and RO6) are to investigate how the proposed system
can be used to offer innovative online services.
1.4. Contributions 5
1.4 Contributions
The key contributions of the thesis are the following.
Mathematical Model of Identity and Identity Management. A novel mathematical model
of different core topics covering a wide range of topics related to Identity Management has
been developed. This is the first model of this kind where, at first, each atomic related issue
is treated separately to highlight the inter-relationship between each issue and then all these
issues are combined to build up the whole model of Identity. The proposed mathematical
model has been used to tackle the issue of inconsistency in different central topics of Identity
Management. In addition, the applicability of the model has been illustrated by utilising it
to characterise the behaviour of an Identity Management System and to characterise three
popular IdM models mathematically. Furthermore, the model has been used to analyse three
issues related to Identity Management: the effect of multiple identities, data ownership and
Identity Theft. The model has been useful to analyse crucial problems in existing online
services.
Dynamic Identity Federations. A mechanism for managing a dynamic federation in a fully
automatic fashion using SAML (Security Assertion Markup Language) has been proposed.
This approach can be easily adopted by any SAML implementation and requires no modifi-
cation of SAML. A proof of concept has been implemented to show the applicability of the
mechanism through use-cases.
User-controlled Identity Management Systems. The need for a more privacy-friendly
Identity Management System is advocated. Then, a proposal of a User-controlled Identity
Management System is put forward to allow users to have better control over their data. To
realise such a system, a novel Identity Provider called Portable Personal Identity Provider
(PPIdP) has been developed and a proof of concept using the mechanism of dynamic fed-
erations has been implemented. It has been analysed how the PPIdP can be used to rectify
several problems of existing Identity Management Systems.
Context-aware Federated Services. To demonstrate how a PPIdP can be used to provide
context-aware federated services, a framework for accessing such services has been designed
and developed. Both context-aware and federated services have been popular trends in online
services in recent years. The proposed framework is the first attempt to combine these two
trends that shows how the additional capabilities of a PPIdP can be leveraged to provide
innovative context-aware federated services. The implemented proof of concept shows the
applicability of this approach through different use-cases.
A Hybrid Architecture for Attribute Aggregation. Finally, a hybrid architecture for ag-
gregating attributes from heterogeneous identity providers is presented. The existing mech-
anisms of attribute aggregation are complex and require preliminary steps which are not
1.5. Publications 6
intuitive. The proposed approach improves upon the existing work; in particular, it does
not require any preliminary steps or complex user interactions. The implemented proof of
concept shows the applicability of this approach through different use-cases. Also, it has
been examined how the privacy of a user during attribute aggregation can be improved by
integrating the PPIdP with the proposed architecture.
1.5 Publications
The research in this thesis has led to the following publications:
1. Md. Sadek Ferdous, Gethin Norma, Audun Jøsang and Ron Poet. “Mathematical
Modelling of Trust Issues in Federated Identity Management” . In the proceedings of
the 9th IFIP WG 11.11 International Conference on Trust Management (IFIPTM-15),
Hamburg, Germany, 26-29 May, 2015.
2. Md. Sadek Ferdous and Ron Poet. “Managing Dynamic Identity Federations using
Security Assertion Markup Language (SAML)” . Journal of Theoretical and Applied
Electronic Commerce Research (JTAER). 10(2):53
˝
U76. 2015.
3. Md. Sadek Ferdous and Ron Poet. “CAFS: A Framework for Context-Aware Fed-
erated Services” . In the proceedings of the 13th IEEE International Conference on
Trust, Security and Privacy in Computing and Communications (IEEE TrustCom-14),
Beijing, China, 24-26 September, 2014.
4. Md. Sadek Ferdous, Gethin Norman and Ron Poet. “Mathematical Modelling of Iden-
tity, Identity Management and Other Related Topics” . In the proceedings of the 7th
International Conference on Security of Information and Networks (SIN-14), Glasgow,
UK, 9-11 September, 2014.
5. Md. Sadek Ferdous and Ron Poet. A Hybrid Model of Attribute Aggregation using
Security Assertion Markup Language (SAML)” . Submitted to the Journal of Com-
puter Security (JCS), 2014.
6. Md Sadek Ferdous and Ron Poet. Analysing Attribute Aggregation Models in Feder-
ated Identity Management” . In the proceedings of the 6th International Conference on
Security of Information and Networks (SIN-13). Aksaray, Turkey, 26-28 November,
2013.
7. Md Sadek Ferdous and Ron Poet. “Portable Personal Identity Provider in Mobile
Phones” . In the proceedings of the 12th IEEE International Conference on Trust,
1.6. Thesis Outline 7
Security and Privacy in Computing and Communications (IEEE TrustCom-13). Mel-
bourne, Australia, 16-18 July, 2013.
8. Md Sadek Ferdous and Ron Poet. “Dynamic Federation using Security Assertion
Markup Language (SAML)” . In the proceedings of the 3rd IFIP WG 11.6 Work-
ing Conference on Policies & Research in Identity Management (IFIP IDMAN 2013).
London, UK, 8-9 April, 2013.
9. Md Sadek Ferdous and Ron Poet. A comparative analysis of Identity Management
Systems” . In the Security Track of the IEEE International Conference on High Per-
formance Computing and Simulation (HPCS). Madrid, Spain, 2-6 July, 2012.
1.6 Thesis Outline
The rest of this thesis is structured as follows:
Chapter 2 provides a short introduction to three popular Identity Management Systems and
reviews related work on different topics of Identity Management that have been chosen for
further exploration in this research.
Chapter 3 builds up the consistent set of terminologies related to Identity Management and
presents the mathematical model of Identity Management. The model is then used to char-
acterise several aspects of Identity Management Systems as well as to characterise different
Identity Management models. In addition, the model is used to analyse four application sce-
narios showing how it can be applied to examine a few problems in existing online services.
This chapter addresses RO1 and RO2.
Chapter 4 presents a comparative analysis of three popular Identity Management Systems
where each system is compared side-by-side using a set of requirements. For this, a taxon-
omy of requirements for an ideal Identity Management System has been formulated. This
chapter addresses RO3.
Chapter 5 presents the proposal for creating federations in a dynamic fashion. The existing
mechanism for creating a federation makes it difficult to manage and is not scalable. This
problem has been tackled with the given proposal. In addition, the implementation based on
the proposal has been extensively used in the subsequent chapters to realise different proof
of concepts.
Chapter 6 introduces the core proposal of a User-controlled Identity Management System
using the Portable Personal Identity Provider and explains how this can be used to tackle
some of the stated problems in existing systems. In addition, this chapter explores different
use-cases using the PPIdP, analyses different security, privacy and trust issues involved, the
1.6. Thesis Outline 8
advantages the developed system offers and the current limitations it has. In doing so, this
chapter addresses RO4.
Chapter 7 discusses the framework for context-aware federated services. This chapter illus-
trates how the PPIdP can be leveraged to build up the framework that combines these two
trends, Context-aware and federated online services, for offering novel use-cases of online
service access. Thus, this chapter addresses RO5.
Chapter 8 presents the hybrid architecture for aggregating attributes from multiple hetero-
geneous identity providers, examines different issues and requirements while designing and
developing such an architecture and discusses the implemented proof of concept using sev-
eral use-cases. Hence, this chapter addresses RO6.
Chapter 9 concludes the thesis by summarising the conducted research. It revisits the
novel contributions of the research and investigates how the research objectives have been
achieved. The chapter also discusses the limitations of the work and proposes a number of
directions for future research.
9
Chapter 2
Background
2.1 Introduction
The need for managing user identities was first realised by service providers as the number of
their user-bases increased. That need motivated the industry to design and develop different
systems to manage the identities of users. Such a system is commonly known as an Identity
Management System (IMS). The majority of research on Identity Management is heavily
reliant on these systems. Hence, this chapter starts with a short introduction to the three
most popular IMSs.
Next, the existing work on different aspects of Identity Management that have been selected
for this research are reviewed. The motivations behind each of these aspects have been
briefly discussed in Chapter 1. However, the motivation for choosing these aspects will
become clearer in subsequent chapters.
2.2 Popular Identity Management Systems
Different Identity Management Systems are based on different IdM models and utilise dif-
ferent protocols. There are three classes of entities involved in each Identity Management
System:
1. Identity Providers (IdPs) - entities that are responsible for managing digital identities
of users and providing identity related services to Service Providers,
2. Service Providers (SPs) - entities that are responsible for providing online services to
the users, and
3. Users (Clients) - entities that receive services from SPs.
2.2. Popular Identity Management Systems 10
Entities from these classes interact with each other using a respective protocol so that on-
line services can be offered and ultimately provisioned. Currently, several IMSs exist. In
this section, a short introduction to the three most popular Identity Management Systems is
presented: SAML-based Systems [5], OpenID [6] and OAuth [7].
2.2.1 Security Assertion Markup Language (SAML)-based IMS
SAML-based IMSs are based on the Federated User Identity model [4] and utilise the Secu-
rity Assertion Markup Language (SAML) [5]. In this system, involved parties need to create
a virtual association, known as a federation, before they can interact with each other. SAML
is an XML (EXtensible Markup Language)-based standard for exchanging authentication
and authorisation information between different autonomous application domains [5]. It is
based on the request/response protocol in which one party (an SP) requests particular iden-
tity information about a user and the other party (an IdP) responds with the information. The
whole language comprises of four key concepts: assertions, bindings, profiles and protocols.
A SAML assertion is the declaration about a user by an IdP for an SP. In its most general
form, an assertion states the following [5, 8]: The assertion A issued at time T by issuer
(IdP) I about the user U holds as long as conditions C are valid.
An assertion can contain three different types of statements:
1. Authentication statements - which are used to state that the user has been authenticated
by the asserted IdP at the specified time,
2. Attribute statements - which are used to specify the attributes of the user and
3. Authorisation statements - which are used to assert that the user is permitted a certain
action on specified resources under certain conditions.
The SAML protocol is used to define the rules on how to pack the above SAML statements
inside the request/response packet and to process them on receipt. The SAML binding is
used to map the SAML protocol into a communication protocol such as HTTP (Hypertext
Transfer Protocol) or SOAP (Simple Object Access Protocol) by which the SAML elements
are transported. Simply, bindings define the mechanisms by which SAML elements are
placed inside any HTTP or SOAP packet. A SAML profile combines all of the above men-
tioned SAML elements and describes how they can be used to implement a use-case. The
most important use-case is the Web Browser SSO (Single Sign On) profile which will be dis-
cussed later. The SSO facility allows a user to authenticate once and then to access multiple
services without further authentications.
2.2. Popular Identity Management Systems 11
A SAML protocol flow based on the Web Browser SSO Profile where both the IdP and the
SP are part of a federation and use the HTTP Post binding is collected from [8], illustrated
in Figure 2.1 and discussed below:
1. A user wants to access a service provided by an SP and hence submits a service access
request to the SP.
Figure 2.1: Protocol flow in SAML.
2. The SAML interface in the SP captures the request and checks if the user is already
authenticated (or authorised) at the SP. If yes, the user is allowed to access the service.
If not, the following steps take place.
3. The user is redirected to the Discovery Service, also known as the Where Are You
From (WAYF) Service, where a pre-configured list of trusted IdPs is shown to the
user. The user selects one of the IdPs and an authentication request is sent to the IdP.
4. The IdP captures the request and checks if the user is already authenticated. If so, step
5 is ignored.
5. The authentication of the user takes place. There are many authentication mecha-
nisms (such as username/password, Kerberos, X.509 certificates, etc.) supported by
the SAML which depends on the respective IdP.
6. Once authenticated, a response containing a SAML assertion with user attributes is
sent back to the SP.
2.2. Popular Identity Management Systems 12
7. Upon receiving the response, the assertion is extracted and validated. If valid, the user
is considered authenticated. Next, user attributes are extracted from the assertion and
the user is re-directed to the requested service.
8. The SP checks if the user is authorised to access the service using the extracted at-
tributes. If so, the user is allowed to access it. If not, the request of the user is denied
and an error message is displayed to the user.
To enable the protocol flow discussed above, a notion of trust needs to be established between
an IdP and an SP inside a federation. A SAML SP needs to trust that the IdP will authenticate
a user using appropriate security mechanisms and release attributes to the SP as per the
contractual agreement [9]. Similarly, the IdP has to trust that the SP will not abuse the
released attributes and use them only for the stated purpose as per the agreement. This
notion of trust between the IdP and SP in SAML is established by exchanging the respective
metadata of the IdP and SP and then storing such metadata at the appropriate repositories.
This enables each party to build up the so-called Trust Anchor List (TAL). This exchange
takes place in an offline fashion after a technical contract between the IdP and SP is signed.
Moreover, this has to be done before any interaction takes place between the said IdP and SP.
Once the exchange of metadata is complete, the IdP and SP are said to be part of the same
federation. Metadata is an XML file in a specified format that contains:
an entity descriptor (an identifier for each party),
service endpoints (the locations of the appropriate endpoints for an IdP and an SP
where the request will be sent to and where the response will be consumed respec-
tively),
a certificate,
an expiration time, and
contact information.
Metadata serves three purposes as explained below.
Firstly, it allows each entity to discover the required service endpoint of another entity
for sending SAML requests/responses.
Secondly, the embedded certificate can be used by an SP to verify the authenticity of
any SAML Assertion.
2.2. Popular Identity Management Systems 13
Thirdly, metadata behaves like an anchor of trust for each party. During the discovery
service at an SP, the list of IdPs returned to the user only contains those IdPs whose
metadata can be found in its repositories (in other words in the TAL) and only those
IdPs are considered trusted. An SP will allow a user to select only those IdPs which
are trusted. Similarly, an IdP will respond only to those requests that are initiated from
an SP whose metadata can be found in its TAL.
The life-cycle of a SAML-based federation consists of four major steps that define how a
federation is created, maintained and updated. The steps are: federation, federation provi-
sioning, maintenance and revocation. These steps are dependent on how the TAL is built and
maintained. For example, when the metadata of two entities are inserted into their respective
TAL, it indicates that both entities are now federated with each other, thus symbolising the
federation step. Identifying and discovering the IdP from the TAL of the SP exemplifies the
federation provisioning stage whereas the maintenance stage is required when the metadata
of an entity stored in the TAL of another entity needs to be modified (e.g. due to changes in
the location of service endpoints, etc.). Lastly, removing the metadata of two entities from
their respective TAL exemplifies the revocation. More about the life-cycle of a federation
will be discussed in Chapter 3.
There are a number of different libraries for SAML for building up a SAML-based IMS
with Shibboleth [10] and SimpleSAMLphp [11] being the two most widely used libraries
developed using Java and PHP respectively.
2.2.2 OpenID
OpenID is a decentralised Identity Management System which provides SSO solutions for
web services over the Internet [12]. It aims to assist users by alleviating the need for main-
taining and using different identities to access different web services as well as to aid an SP
by removing the need to manage its user-bases. It is based on the Open Unfederated Identity
Model (discussed in Chapter 3). With a user-base of more than 1 billion users, it is one of the
most widely used IMSs and is used by many web service providers including AOL, BBC,
Google, IBM, MySpace, Orange, PayPal, Verisign, LiveJournal and Yahoo [12, 13].
Like SAML, OpenID protocol has three different classes of actors (entities): Users, OpenID
Providers (also simply known as Providers) and Service Providers, known as Relying Parties
(RPs) in OpenID terminology. A user is an entity that wants to access a protected service
provided by an RP. An OpenID Provider allows a user to create an identity. The provider
is also responsible for authenticating a user who wants to access the protected service from
an RP and provides an assertion regarding the user to an RP. An RP is essentially a service
provider providing services to a user and consumes an assertion given by a provider to decide
2.2. Popular Identity Management Systems 14
Figure 2.2: Protocol flow in OpenID without exchanging keys.
if a user can access the service. There are a number of libraries for all major web technologies
and programming languages such as Apache, C#, Coldfusion, Haskell, Java, JavaScript, Perl,
PHP and Python [14].
To understand the protocol flow of the OpenID, it is considered that a user wants to access
a service from an OpenID RP. Before engaging into the protocol flow, the first step for the
user is to create an OpenID identifier (also known as just OpenID) at an OpenID Provider.
An OpenID is essentially either a URL (Uniform Resource Locator) or an XRI (Extensive
Resource Identifier) and analogous to an email address in the sense that an OpenID is univer-
sally unique. Many large popular web service providers such as Google, Yahoo, LiveJournal,
Blogger, flickr, AOL and WordPress can be used as OpenID Providers since they allow their
users to use their respective identifiers (usernames) to be used as OpenIDs. There are also
many dedicated OpenID providers such as claimID, myOpenID, myid.net and VeriSign. The
main point is that any provider can act as an OpenID provider by deploying the required
libraries and users can choose any OpenID Provider for accessing a service. The protocol
flow in OpenID is illustrated in Figure 2.2 and is discussed below:
1. A user visits an RP to access one of its services.
2. The RP needs to authenticate the user. As it supports OpenID, it has a special button
tagged as Sign in with OpenID. Once clicked, this will allow the user to enter her
OpenID.
2.2. Popular Identity Management Systems 15
3. The user enters her OpenID and clicks the Login button.
4. The RP uses that OpenID to discover the OpenID provider.
5. Once the provider is discovered, the RP may initiate an optional Key Exchange step
in which the RP and the provider exchange a shared secret key to be used to verify the
signature of the RP in a response message (see below).
6. Once the provider is found, the user is redirected to that respectiv