Conference PaperPDF Available

Analysing Attribute Aggregation Models in Federated Identity Management

Authors:

Abstract and Figures

This paper presents a comparative analysis of different at-tribute aggregation models against a set of requirements in the settings of the Federated Identity Management (FIM). There are several attribute aggregation models currently available which allow the user to collate attributes from multiple identity providers (IdP in short) in a single service. These models impose different novel requirements which have never been analysed before and there lacks a thorough analysis of these models that will compare them side-by-side against a set of requirements. We aim to �ll in these gaps in this work. We have formulated a set of trust, functional, security and privacy requirements that are needed for each model and shown the interlink between these requirements. These requirements have been used to compare the models side-by-side in tabular forms which would allow the readers to instantly identify the requirements for each model, the advantages it offers and the weaknesses it has.
Content may be subject to copyright.
Analysing Attribute Aggregation Models in Federated
Identity Management
Md. Sadek Ferdous
School of Computing Science, University of Glasgow
Glasgow, G12 8QQ, Scotland
m.ferdous.1@research.gla.ac.uk
Ron Poet
School of Computing Science, University of Glasgow
Glasgow, G12 8QQ, Scotland
ron.poet@glasgow.ac.uk
ABSTRACT
This paper presents a comparative analysis of different at-
tribute aggregation models against a set of requirements in
the settings of the Federated Identity Management (FIM).
There are several attribute aggregation models currently
available which allow the user to collate attributes from
multiple identity providers (IdP in short) in a single service.
These models impose different novel requirements which have
never been analysed before and there lacks a thorough anal-
ysis of these models that will compare them side-by-side
against a set of requirements. We aim to fill in these gaps
in this work. We have formulated a set of trust, functional,
security and privacy requirements that are needed for each
model and shown the interlink between these requirements.
These requirements have been used to compare the models
side-by-side in tabular forms which would allow the readers
to instantly identify the requirements for each model, the
advantages it offers and the weaknesses it has.
Categories and Subject Descriptors
C.2.0 [General]: [Security and protection]; D.4.6 [Security
and Protection]: [Access controls, Authentication]
General Terms
Design, Security
Keywords
Attribute Aggregation, Identity Management, Federated Iden-
tity Management, Trust.
1. INTRODUCTION
We have experienced a tremendous popularity and expan-
sion of online services in last 15 years or so. Many of these
services require that the user must prove their identities be-
fore accessing the services. The term Digital Identity, a pro-
jection of one’s identity consisting of different attributes en-
coded in electronic formats [4], is used in such scenarios.
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are not
made or distributed for profit or commercial advantage and that copies bear
this notice and the full citation on the first page. Copyrights for components
of this work owned by others than ACM must be honored. Abstracting with
credit is permitted. To copy otherwise, or republish, to post on servers or to
redistribute to lists, requires prior specific permission and/or a fee. Request
permissions from Permissions@acm.org.
SIN ’13, November 26 - 28 2013, Aksaray, Turkey
Copyright 2013 ACM 978-1-4503-2498-4/13/11...$15.00.
http://dx.doi.org/10.1145/2523514.2526998.
Since, different services require different types of attributes,
the users end up with different digital identities stored at
different providers. These separated digital identities are
known as the Partial Digital Identity (or Partial Identity, in
short) of the user.
Identity Management (IdM, in short) was introduced by
the industry to facilitate online management of user iden-
tities (digital identities of the user) which resulted in vari-
ous different Identity Management Systems (IMS, in short).
Shibboleth [1], OpenID [3], Microsoft’s CardSpace [8], etc.
are all examples of different IMS. Each IMS has several par-
ties involved which are: Service Provider (SP) or Relying
Party (RP) - an entity that provides services to the clients
or to the other service providers, Identity Provider (IdP) -
an entity that holds and releases the partial identity (user
attributes) to enable the user to receive services from a SP
and Client/User - an entity that receives services from a SP.
Among different IMS, Federated Identity Management (FIM,
in short) has gained much popularity. The FIM model is
based on the concept of Identity Federation (also known as
Federated Identities or Federation of Identities). A feder-
ation with respect to the Identity Management is a busi-
ness model in which a group of two or more trusted parties
legally bind themselves with a business and technical con-
tract [6, 14]. The IdPs and SPs who bind themselves in such
a way form the so-called Circle of Trust (CoT) which make
them a part of the same federation. One major advantage of
the FIM is its Single Sign On (SSO) capability that allows
users to log in to one system and then access services from
federated service providers without further logins. Security
Assertion Markup Language (SAML) [15] and OpenID [3]
are two of the most popular identity federation technolo-
gies. In this paper, our main focus is on the SAML-based
identity federation. Shibboleth [1] and SimpleSAMLphp [2]
are currently two popular implementations based on SAML.
To access a service from a SP in SAML, the user is forwarded
to the chosen IdP where the user authenticates. Then, the
user is sent back to the SP with an assertion that contains
user attributes. The SP validates the assertion, retrieves
attributes from it and based on these attributes, the SP de-
cides if the user can access the service.
Even though the federated services improve the usability
and experience of online services, there exists a serious limi-
tation: the user is allowed to chose only one partial identity
from one single IdP during one single service session at a SP
[7]. The concept of Attribute Aggregation has been intro-
duced to tackle this very problem that will allow the user to
aggregate attributes from multiple IdPs in a single service
To appear in the proceedings of the 6th International Conference on Security of Information and Networks (SIN'13).
session. A number of novel approaches exist in reality for
aggregating attributes, each with their own strengths and
weaknesses. Each of these methods, depicted in different
models, has additional interactions, require additional enti-
ties to function and impose novel requirements. The existing
literature of attribute aggregation discuss these methods and
their interactions in a casual way without analysing these re-
quirements [12, 5, 10]. These make it difficult for anyone not
only to have a thorough understanding on these models, but
also to compare them against a set of requirements. We aim
to address this issue in this paper where we compare each
model side-by-side against a set of requirements and anal-
yse their strengths and weaknesses in a more systematic way.
The contributions of this paper are:
At first, we have created a taxonomy of existing at-
tribute aggregation models.
We have formulated the types of requirements and
then populated each type with different requirements
for the basic Federated Identity Management.
Then, we have treated each model individually to anal-
yse the novel requirements it has to consider in addi-
tion to the basic set of requirements.
We have shown the interlink between different require-
ment that illustrates how meeting one or more require-
ments leads to satisfying another requirement.
Finally, we have presented our findings in tabular forms
making it easier for the reader to instantly identify the
requirements for each model, the advantages it offers
and the weaknesses it has.
With this introduction, this paper is organised as follows.
We formulate a basic set of Functional, Trust, Security and
Privacy requirements that are needed for the traditional fed-
erated services in Section 2. Then, we define the taxonomy
of different Attribute Aggregation Models in Section 3. We
have analysed each model separately to devise the additional
requirements that a single model imposes in Section 4, 5 and
6. We present our findings in tabular forms in Section 7 and
some existing works on Attribute Aggregation are discussed
in Section 8. Finally, we conclude in Section 9.
2. A STUDY OF REQUIREMENTS
There are different types of requirements for the Feder-
ated Identity Management. We classify them as four types:
Functional, Trust, Security and Privacy. Each of them is
analysed below.
Functional Requirements (FR): The functional require-
ment outlines the way federations must be created between
the SP, whose services the user is trying to access, and the
IdPs, from where attributes will be aggregated, for each
model and any other requirements that are needed to ensure
its functionalities. The type of federations that will need to
be created will vary from one model to another. For the tra-
ditional simple FIM model with a single CoT where there
are one or more IdPs and one or more SPs, the functional
requirement can be expressed in the following way:
F1. The IdPs and the SPs are part of the same federation.
Trust Requirements (TR): Jøsang et al. compiled a
set of trust requirements for different Identity Management
models [11]. Kylau et al. also present a set of require-
ments targeting mainly the FIM [13]. However, some trust
requirements have been ignored by both works. We have
picked the suitable existing requirements from [11, 13] and
combined them with a few novel ones, that we have formu-
lated, to create a comprehensive set of trust requirements
for the FIM. The set is presented below. Each requirement
has been marked to indicate if they existed before, as pre-
sented in [11, 13].
Client Trust in IdP:
T1. The IdP has implemented satisfactory user registration
procedures and authentication mechanisms (from the
client’s perspective, denoted as T2 in [11]).
T2. The IdP protects client privacy to the SP, either by us-
ing anonymous techniques or by using pseudonymous
identifiers, when the client wishes to employ them (de-
noted as T1 in [11]).
T3. The IdP has satisfactory mechanisms to store user at-
tributes safely and securely.
T4. The IdP will release only those attributes to the SP
that the client has consented to.
Client Trust in SP:
T5. The SP will ask only for the minimum number of user
attributes that are required to access any of its ser-
vices.
T6. The SP will not abuse the released user attributes and
will use them only for the stated purpose(s).
IdP Trust in Client:
T7. The client handles their authentication credentials with
adequate care (denoted as T3 in [11]).
SP Trust in Client:
T8. During the registration procedure, the IdP might ask
the client to provide several attributes which are then
stored at the IdP. In such scenarios, the SP trusts the
client to be honest while providing such attributes.
IdP Trust in SP:
T9. The SP adheres to the agreed privacy policies regard-
ing non-disclosure of user data (denoted as IdP-T.1 in
[13]). In other words, the SP will not abuse the re-
leased user attributes and will use them only for the
stated purpose(s). The policy might include that the
SP will not cache any user-attributes other than those
which are absolutely necessary. This is to ensure that
the IdP can always provide the updated attributes re-
garding the user. In cases where the SP needs to cache
any attributes (e.g. IdP-supplied identifiers), the SP
must inform the IdP.
T10. The SP adheres to the agreed policies and procedures,
in cases if they are available, regarding access control
and delegated access. If there are no such policies or
procedures, this (T10) requirement is ignored.
SP Trust in IdP:
T11. The IdP has implemented adequate procedures for
registering users and for issuing credentials (denoted
as T7 in [11]).
T12. The IdP will authenticate the client appropriately as
per the requirement and will release user attributes
securely.
This set forms the basic set of trust requirements for the
FIM. The attribute aggregation model leverages the basic
FIM and extends it in many ways (which we will explore
shortly). Such an extension requires formulating novel trust
requirements which must be augmented with this basic set.
We will formulate and analyse such additional requirements
separately for each aggregation model.
Security Requirements (SR): Security requirements de-
fine what must be imposed to ensure the security of the
system and all other parties involved. A taxonomy of re-
quirements for an ideal Identity Management System can
be found in [9]. We can use that taxonomy as a basis to
formulate the list of security requirements which is given
below:
S1. The user-registration procedure at the IdP is completed
in a secure manner. If the registration takes place on-
line, it must be done over the HTTPS channel.
S2. If the IdP allows the user to choose a credential (e.g. a
password) for the identifier, the IdP must ensure that
the chosen credential is secure (in other words, it is
hard to guess or tamper with).
S3. The user is authenticated securely (over the HTTPS
channel, if the authentication takes place online) using
appropriate authentication mechanisms.
S4. The user attributes are stored securely at the IdP.
S5. To ensure the confidentiality, integrity and non-repudiation
of the assertions/claims holding user attributes, they
must be digitally signed and must be exchanged, be-
tween the IdP and the SP, over the HTTPS channel.
Privacy Requirements (PR): Privacy requirements mainly
focus on preserving the privacy of the user while using an
IMS. Using the taxonomy of requirements from [9], we can
formulate the following list of privacy requirements:
P1. The IdP should provide the user with the choice to
access services anonymously or using a pseudonym. If
the user chooses to be anonymous, the user identifier
should not be transferred to the SP. If the user chooses
to use a pseudonym, an identifier (either a persistent
or a temporary one) should be created and transferred
to the SP.
P2. The IdP must inform the user about the SP to which
the attributes are being released to ensure data trans-
parency.
P3. The IdP must allow the user to select the attributes
that they want to release to a particular SP. This will
ensure that the user has consented to exchanging par-
ticular attributes and the user has full control over the
data flow.
P4. To ensure data minimisation, the SP must inform the
user about the minimum number of attributes that
the user must release to access any particular service
of that SP.
P5. One way to enforce the control over the data, released
to a SP, is to allow users to administer their data re-
motely preferably using remote policies. If the IdP
and the SP inside a federation offer this facility, there
should be a user-interface at the IdP for the user to
administer such policies and there should be a mech-
anism to exchange such policies between the IdP and
the SP.
Analysis: The curious readers might have noticed many
similarities between the Trust and Security-Privacy Require-
ments. In fact, functional, security and privacy require-
ments signify the technical conditions that must be con-
sidered while designing and developing an IMS and can be
used to satisfy the trust requirements. Now we will anal-
yse which Security and Privacy requirements can be used to
satisfy which trust requirements.
The requirement T1 can be satisfied by fulfilling require-
ments S1, S2 & S3 since these security requirements ensure
that the IdP has implemented the required methods for ad-
equate user registration and subsequent authentication. It
is easy to note that P1 will fulfil T2 and S3 will fulfil T3. If
P2 & P3 can be fulfilled, this will end up satisfying T4. By
ensuring P4,T5 can be satisfied and similarly, by ensuring
P5,T6 can be fulfilled. If there are mechanisms available
to allow remote administration of policies at the SP (P5 ), it
will allow the IdP to ensure that the SP has adhered to the
agreed policies regarding non-disclosure of user attributes
and access control thereby fulfilling T9 & T10. Finally, it is
not difficult to conclude that security requirements S1 & S4
will help to satisfy T11 & T12 respectively.
It is important to note that some requirements such as
T7 & T8 cannot be satisfied by any technical means since
it is not possible to determine whether the user handles the
credentials with adequate care or whether the user is honest
in providing different attributes. In such cases, the IdP can
only assume that the user will handle the credentials appro-
priately for the sake of their own interests or the SP can
only trust that the user is honest while providing attributes
- any of both such assumptions might not be honoured at
all.
3. TAXONOMY OF ATTRIBUTE AGGRE-
GATION MODELS
Attribute Aggregation is the mechanism of aggregating or
collecting attributes of a user retrieved from multiple iden-
tity providers in a single session. In FIM technologies such
as SAML, the attributes are embedded inside an assertion.
Therefore we have two interpretations of attribute aggre-
gation: it either means the aggregation of attributes when
all attributes are embedded inside a single assertion or it
means the aggregation of assertions when other assertions
are embedded inside a single assertion.
Before we can create a taxonomy of existing attribute ag-
gregation models, we need to select the criteria that can be
used to classify each model. We have two criteria: where
the attribute aggregation takes place and who mediates the
whole process. Here, by mediation we mean the process of
initiating the aggregation mechanism. Based on where the
attribute aggregation takes place, the existing attribute ag-
gregation mechanisms can be classified in three categories:
Aggregation at the SP, Aggregation at the IdP and Aggre-
gation at the Client (e.g. the User-Agent/Browser). Each
category can then further be classified based on who medi-
ates the aggregation process: the IdP or the SP. Based on
these categories, the taxonomy that we have created is il-
lustrated in Figure 1. In the following sections, we provide
a brief description of each mechanism and analyse the func-
tional, security and privacy requirements for each model.
Figure 1: Taxonomy of Attribute Aggregation Models.
4. AGGREGATION AT THE SP
The models discussed in the section enable the user to
aggregate attributes at the SPs. As mentioned earlier, the
models can be further classified based on the entity that
initiates the process: the SP or the IdP.
4.1 Mediated by the SP
The models which allow the SP to initiate the aggregation
mechanism falls into this category.
4.1.1 Application Database (AD) Model.
This is the simplest form of attribute aggregation model
(Figure 2) [12, 5]. In this model, the SP might store addi-
tional user attributes such as a local identifier, user-preferences
for that particular service, group membership, etc., in addi-
tion to the attributes supplied by the IdP. The SP creates
a mapping of the SP-created identifier to the IdP-supplied
identifier to store these additional attributes, into a local
repository. Such local attributes can be retrieved later on
using this mapping to determine if the user is authorised to
access a particular service.
Figure 2:
Application
Database
Model.
Figure 3:
SP-Mediated
Model.
Figure 4: Link-
ing Service
Model.
FR: The functional requirement is that the IdP and SP
are federated with each other meaning that the requirement
F1 must be fulfilled. In addition, the following requirement
arises:
F2. The mapping of the IdP-supplied and the SP-created
identifiers is correct.
TR:T1 - T12. The model formulates the following new
trust requirement:
T13. The IdP provides a persistent SP-specific user identi-
fier to the SP so that the SP can create the mapping
between the IdP-supplied and SP-created identifiers
in the first instance and then map the IdP-supplied
identifier to the SP-created identifier in all subsequent
instances to retrieve attributes from the local reposi-
tory.
SR:S1 - S5. The model formulates the following new secu-
rity requirement:
S6. The mapping information of the IdP-supplied and the
SP-created identifiers as well as other local user at-
tributes are stored safely and securely in the SP repos-
itory.
PR: The model does not introduce any additional privacy
requirements. However, it is required that the existing pri-
vacy requirements (P1 - P5 ) are fulfilled.
Analysis - It is easy to note that the requirement P1 sat-
isfies T13.
4.1.2 SP-Mediated (SPM) Model.
In this model, the SP allows the user to aggregate at-
tributes from multiple IdPs in a single session (Figure 3)
[12, 5]. The user is forwarded to different IdPs one after
another where the user is authenticated separately and re-
turns to the SP with the IdP-supplied attributes. The SP
combines the sets of attributes at its end to determine if the
user can access a particular service.
FR: The functional requirement is that the SP and each IdP
are federated with each other meaning that the requirement
F1 must be fulfilled for each IdP-SP pair. In addition, the
following requirement arises:
F3. A session is maintained at the SP so that the SP can
correlate the attributes from the current IdP with at-
tributes retrieved previously from other IdPs.
TR/SR/PR: This model does not have any additional trust,
security and privacy requirements other than T1 - T12,S1
- S5 and P1 - P5 respectively.
4.1.3 Linking Service (LS) Model.
Linking Service model is a combination of the linking and
identity relay model (see below). It consists of a special type
of SP called the Linking Service (LS, Figure 4) [7, 5] which
is used by the user using a LS-supplied identifier. This iden-
tifier is used to link different IdPs using the IdP-supplied
LS-specific persistent identifiers in a table called the Link-
ing Table. To access any service of the SP, the user visits the
SP and is forwarded to the first IdP (IdP1 in Figure 4). The
user authenticates at IdP1 and then an assertion contain-
ing user-attributes, the persistent identifier for the LS and a
reference to the LS is returned to the SP. The SP forwards
the persistent identifier to the LS to aggregate attributes.
At this point, two options are available: either the LS can
retrieve the list of linked IdPs for this persistent identifier
using the Linking Table and retrieve attributes from each of
them which are then combined at the LS and is returned to
the SP or the LS can send back the list of linked IdPs to the
SP. The SP, then, retrieves attributes from each IdP. Based
on the aggregated attributes, the SP determines if the user
can access the service.
FR: The functional requirement is that the IdPs and the SP,
the LS and the IdPs and the LS and the SP are federated
with each other meaning that the requirement F1 must be
fulfilled for each pair (except for any IdP-IdP pair). More-
over, F3 has to be fulfilled during the Link Registration
phase between the LS and the IdPs while keeping a session
at the LS as well as during the attribute aggregation phase
between the LS and other IdPs while keeping a session at
the SP. In addition, the following requirements arise:
F4. The Linking Table is accurate so that the mapping of
the IdP-supplied and the LS-supplied identifiers is cor-
rect.
F5. The LS has dual capabilities of an IdP as well of a SP.
The LS has to act as an IdP to the SP and as a SP to
other IdPs.
F6. The IdPs have extended capabilities to embed a referral
to the LS and the encrypted persistent identifier for the
LS along with the attributes inside an assertion to be
sent to the SP.
F7. The SP has extended capability to follow the referral
to interact with the LS so that the SP either can re-
ceive aggregated attributes from the LS or can receive
a list of linked IdPs with their respective encrypted
identifiers. For the second case, the SP must have a
mechanism to retrieve attributes from the linked IdPs
(except the first IdP) using the encrypted identifiers.
F8. The IdPs have extended capabilities to provide asser-
tions containing attributes to the LS or the SP without
any user authentication when the LS or the SP submits
a valid encrypted identifier retrieved from the Linking
Table of the LS.
TR:T1 - T11. In addition, the model has the following new
trust requirements:
T14. The IdPs provide persistent LS-specific user identifiers
to the LS so that the LS can build up the Linking Table
and to the SP so that it can use it to query the LS.
T15. The LS builds up the Linking Table correctly to en-
sure that only IdPs to which a user has accounts are
linked.
T16. The LS will either provide correctly aggregated at-
tributes or the list of linked IdPs to the SP for that
specific user.
T17. The SP will use that list to aggregate attributes just
once.
T18. The IdPs will release attributes to the LS or the SP
upon receiving the persistent identifier and without
any user authentication.
SR:S1 - S5. In addition, the model has the following new
security requirements:
S7. The Linking Table is stored safely and securely at the
LS repository.
S8. Each LS-specific user identifier acts like a secret be-
tween the IdP and the LS. Hence, it must be encrypted
by the IdP to be decrypted only by the LS and by the
LS to be accessible by each individual IdP. This will
ensure that the SP does not get hold of the respective
identifier at any time.
S9. If the list of linked IdPs is released to the SP, the LS
should ensure that the SP cannot use that list more
than once.
PR: Other than fulfilling (P1 - P5 ), the model has the fol-
lowing privacy requirements:
P6. The IdP releases the referral of the LS to the SP only
after the user has explicitly consented to do so.
P7. To ensure transparency, the SP should allow the user
to choose where the attributes will be aggregated: at
the LS or at the SP.
Analysis - Building an accurate Linking Table implicitly
implies that the IdPs have provided LS-specific user identi-
fiers to the LS. Also IdPs having the ability to embed the
encrypted identifier means that the IdPs will release that
identifiers to the SP. Therefore, F4, F6 & P6 combinedly
satisfy T14. It is easy to see that F4 satisfies T15,F7 &
P7 satisfy T16 and S9 satisfies T17. Since all IdPs other
than the first IdP where the user will authenticate herself
will release user-attributes without any user-authentication,
we will need S8 & F8 to satisfy T18.
4.2 Mediated by the IdP
The model which allows the IdP to initiate the aggregation
mechanism falls into this category.
4.2.1 Identity Federation/Linking (IFL) Model.
This model, introduced by the Liberty Alliance frame-
work, is one of the very first models to address the problem
of attribute aggregation (Figure 5) [12, 5]. In this model,
IdPs allow the user to create a pair-wise link between two
IdPs. To create the link, the user has to visit and authen-
ticate to the first IdP. The first IdP will ask the user if she
wants to federate this IdP with another IdP. If chosen, the
user will be asked to federate the second IdP with the first
one. At this point, both IdPs will interact with each other
to create a random alias. During accessing services from a
SP, one IdP will provide that random alias to the SP along
with the assertion containing attributes. The SP can use
that alias to retrieve another assertion containing attributes
from the other IdP. Combining attributes from both IdPs,
the SP can determine if the user can access a service.
FR: The functional requirement is that IdPs and the SP are
federated pair-wise meaning that the requirement F1 must
be fulfilled for each pair. Moreover, F3 has to be fulfilled
during the attribute aggregation phase between the SP and
the other IdP while keeping a session at the SP. Moreover,
F6, F7 & F8 must be fulfilled using the random alias in-
stead of the persistent identifier. In addition, the following
requirement arises:
Figure 5:
Identity Feder-
ation/Linking
Model.
Figure 6: Iden-
tity Proxying
Model.
Figure 7: Iden-
tity Relay
Model.
F9. The random alias is correctly created.
TR:T1 - T11. In addition, T17 must be fulfilled using the
random alias instead of the list and T18 must be fulfilled
using the random alias instead of the persistent identifier.
The model also has the following new trust requirement:
T19. The IdPs provide the correct random alias to the SP.
SR: S1 - S5. In addition, the model must also satisfy S8
where the random alias needs to be encrypted instead of
the persistent identifier. Moreover, S9 has to be met to
ensure that the SP cannot use the random alias to aggregate
attributes more than once in a single session. The model also
has the following new security requirement:
S10. The random alias is stored safely in the IdP repository
and is transmitted securely during any transmission.
Privacy Requirements - The model must fulfil require-
ments P1 - P6.
Analysis - It is easy to see that F9 satisfies T19.
5. AGGREGATION AT THE IDP
The models discussed in the section enable the user to
aggregate attributes at the IdPs.
5.1 Mediated by the IdP
The model that allows the IdP to initiate the aggregation
mechanism falls into this category.
5.1.1 Identity Proxying (IP) Model.
In this model, the SP allows the user to aggregate at-
tributes from multiple IdPs using a highly trusted IdP (Fig-
ure 6) [12, 5]. The user is forwarded to the trusted IdP (IdP1
in Figure 6) at first and then the trusted IdP forwards the
user to other multiple IdPs. After the user is authenticated
separately at each IdP, the user returns back to the trusted
IdP with an assertion including attributes. At this point,
the trusted IdP validates each assertion, retrieves attributes
from them and combines all these attributes. The trusted
IdP might supplement the combined set with its own user-
attributes and then reasserts all attributes to the SP as its
own attributes. The SP, not being aware of other IdPs, as-
sumes that all attributes have been released by the trusted
IdP. Based on the combined attributes, the SP determines
if the user can access the service.
FR: The trusted IdP is federated with other IdPs and the
SP meaning that it needs that the requirement F1 is fulfilled
for the trusted IdP with other IdPs and the SP. Moreover,
F3 has to be fulfilled during the attribute aggregation phase
between the trusted IdP and other IdPs while keeping a ses-
sion at the trusted IdP. Also, F5 has to be fulfilled in the
sense that the trusted IdP should have the dual capabilities:
acting as an IdP to the SP and acting as a SP to other IdPs.
In addition, the following requirement arises:
F10. The assertion returned by other IdPs should be tar-
geted for the trusted IdP so that it can validate each as-
sertion, extracts attributes from them and then aggre-
gate all of them, possibly also with its own attributes.
TR/SR/PR: This model does not have any additional trust,
security and privacy requirements other than T1 - T12,S1
- S5 and P1 - P5 respectively.
5.1.2 Identity Relay (IR) Model.
The Identity Relay model is a generalised case of the Prox-
ying model (Figure 7) [12, 5]. Since the Proxying model re-
quires the SP to have a strong trust in the trusted IdP, it
cannot function properly in situations when the proxy IdP
cannot be fully trusted. The Identity Relay model fits in
such scenarios where an intermediary IdP (or Relay IdP),
(IdP1 in Figure 7) is used instead of a trusted IdP . The
user is forwarded to the relay IdP at first and then the relay
IdP forwards the user to other multiple IdPs. The user is
authenticated separately at each IdP and is returned back
to the relay IdP with assertions including user-attributes.
The relay IdP combines all assertions into a single assertion
and forwards it to the SP. The SP extracts embedded as-
sertions from this assertion and validates each assertion to
retrieve attributes from other IdPs. Based on the combined
attributes, the SP determines if the user can access the ser-
vice.
FR: The functional requirement is that the IdPs and the
SP, the relay IdP and other IdPs and the relay IdP and
the SP are federated with each other meaning that the re-
quirement F1 must be fulfilled for each pair (except for any
IdP-IdP pair). Moreover, F3 has to be fulfilled during the
attribute aggregation phase between the relay IdP and other
IdPs while keeping a session at the relay IdP. Also, F5 has
to be fulfilled in the sense that the relay IdP should have the
dual capabilities: acting as an IdP to the SP and acting as
a SP to other IdPs. In addition, the following requirement
arises:
F11. The assertion returned by other IdPs should be tar-
geted for the SP. The relay IdP will just aggregate all
assertions and embed them inside another assertion
and send it back to the SP. The SP will validate the
outer assertion and retrieve all embedded assertions.
Then it must validate each assertion in turn to extract
attributes from them.
TR: Other than fulfilling (T1 - T12 ), the model has the
following trust requirement:
T20. The other IdPs release assertions in such a way that
they are only accessible by the SP.
SR/PR: This model does not have any additional security
and privacy requirements other than S1 - S5 and P1 - P5
respectively.
Analysis - It is easy to see that F11 satisfies T20.
6. AGGREGATION AT THE CLIENT
In this model, a user client (e.g. a browser) is used to
aggregate attributes.
6.0.3 Client-Mediated (CM) Model.
This model is similar to the Relay Model. Here, the func-
tionality of the relay IdP has been replaced by an intelligent
user-agent or application that has the capability to aggre-
gate attributes from different IdPs [12, 5]. The SP informs
the client about the IdPs that it trusts. The client forwards
the user to each of these IdPs. After respective authentica-
tion at each IdP, the client receives assertions from all IdPs
and present the combined set of assertions to the SP. The
SP validates each assertion, retrieves all attributes and then
determines if the user can access the service.
FR: The functional requirement is that the IdPs and the SP
are federated with each other meaning that the requirement
F1 must be fulfilled for each pair (except for any IdP-IdP
pair). Also, F11 must be fulfilled where all intermediary
functions should be performed by the intelligent client rather
than the relay IdP. In addition, the following requirement
arises:
F12. The intelligent client, the IdP and the SP have been
deployed with the required capabilities to interact with
each other.
TR: This model requires T1 - T12 and T20 to be fulfilled.
SR/PR: This model does not have any additional security
and privacy requirements other than S1 - S5 and P1 - P5
respectively.
7. DISCUSSION
We have shown in the previous section that the aggre-
gation models formulate novel trust requirements. They
also require novel functional, security and privacy require-
ments. The previous section has analysed how these novel
functional, security and privacy requirements can satisfy the
newly formulated trust requirements.
Each model has different sets of requirements with their
own strengths and weaknesses. It is rather difficult to il-
lustrate this fact with any textual description as provided
in the previous section. Therefore, we present our analysis
in tabular forms below. Table 1 and Table 2 illustrate a
side-by-side comparison of all aggregation models where Ta-
ble 1 presents the comparison of requirements and Table 2
presents the comparison of strengths and weaknesses of each
model. The more the requirements one model has to fulfil
the more complex it will be to establish, maintain and scale.
Therefore, an optimal aggregation model should have a rel-
atively small number of requirements with a good number
of advantages. Unfortunately, it is evident from the tables
that no model is unquestionably superior to other models.
Extensive research is needed to come up with a model that
requires not only a relatively small number of requirements
but also offers a good number of advantages. In our opin-
ion, a good research candidate for that would either be the
Identity Proxying model or the Identity Relay model. We
are currently investigating how these two models can be im-
plemented while reducing their disadvantages as much as
possible.
8. RELATED WORK
The works discussing different existing attribute aggrega-
tion mechanisms can be found in [12, 5] where the author
provided the comparative analysis of existing attribute ag-
gregation models and an exhaustive discussion on several as-
pects of attribute aggregation and identity management in
general without using any requirement. In another work, the
authors presented a survey of requirements required for at-
tribute aggregation from multiple sources [10] and analysed
the strengths and weaknesses of four different generic mech-
anisms (Identity Proxying, SP-Mediated, Client-Mediated
and Identity Federation/Linking) using that set of require-
ments.
Our work in this paper is influenced by the works pre-
sented in [12, 5, 10]. However, we believe that our work is
more comprehensive in every sense. The set of requirements
devised in this work is more thorough than that of [10] where
the trust, functional, security and privacy requirements were
not properly categorised and many trust, functional, secu-
rity and privacy requirements were not even considered. The
works of [12, 5] just provided a brief discussion on each model
without any analysis of requirements. Our work is the first
one that provides a taxonomy of existing attribute aggrega-
tion models, categorises different requirements in a system-
atic manner, analyses the novel requirements that arise for
each aggregation model and interlinks how different trust re-
quirements can be fulfilled using the functional, security and
privacy requirements. It also presents the result in tabular
forms to compare all models side-by-side not only based on
their architectural flexibilities/constrains, but also based on
different requirements.
9. CONCLUSION
As online services evolve and their maturities increase,
there will be a pressing need for a secure yet usable attribute
aggregation mechanism. As our findings suggest, none of
the existing methods can claim to be unquestionably better
than others and each has major drawbacks that must be
addressed. In essence, there is a need for further research
on it. For that, a thorough analysis of existing methods
are necessary to make readers to be aware of the additional
requirements and to keep them informed of the strengths
and weaknesses of each model, thereby enabling them to
gain a deep understanding on each one. In this paper, we
aim to address these issues. We have created a taxonomy
of existing attribute aggregation models and analysed them
individually to investigate the additional requirements each
model has. Then we have presented our finding in tabular
forms to make it easier for the reader to compare each model
side-by-side. We believe that this work will lay down the
path to help anyone to embark on research to design and
develop a secure, usable and realistic attribute aggregation
mechanism.
10. REFERENCES
[1] Shibboleth. http://shibboleth.internet2.edu/.
[2] SimpleSAMLphp. http://simplesamlphp.org/.
[3] OpenID Authentication 2.0 - Final. 5 December, 2007.
http://openid.net/specs/
openid-authentication-2_0.html.
[4] Modinis - Common Terminological Framework for
Interoperable Electronic Identity Management.
Accessed on 28th June, 2011. https:
//www.cosic.esat.kuleuven.be/modinis-idm/
twiki/bin/view.cgi/Main/GlossaryDoc.
Table 1: Aggregation Models: Comparison of Requirements
Models TR FR SR PR
AD T1 - T13 F1 - F2 S1 - S6 P1 - P5
SPM T1 - T12 F1, F3 S1 - S5 P1 - P5
LS T1 - T11, T14 - T18 F1, F4 - F8 S1 - S5, S7 - S9 P1 - P7
IFL T1 - T11, T17 - T19 F1, F3, F6 - F9 S1 - S5, S8 - S10 P1 - P6
IP T1 - T12 F1, F3, F5, F10 S1- S5 P1 - P5
IR T1 - T12, T20 F1, F3, F5, F11 S1 - S5 P1 - P5
CM T1 - T12, T20 F1, F11 - F12 S1 - S5 P1 - P5
Table 2: Aggregation Models: Strengths and Weaknesses
Models Advantages Disadvantages
AD Easy to implement and maintain. Small number of
requirements.
Aggregation from only one IdP in a session. Chang-
ing identifiers causes the system to fail.
SPM Aggregation from a number of IdPs in a session Hard to maintain. Multiple logins at the IdPs in a
single SP session. No implementation exists.
LS Secure and Privacy-preserving. Proof of concept im-
plementation available. Attribute aggregation from
multiple IdPs in a single session. SSO capability dur-
ing service access.
Unrealistic trust assumption. Hard to deploy and
difficult to maintain. The LS represents a single
point of failure.
IFL Secure and Privacy-preserving. Proof of concept im-
plementation available. SSO capability during ser-
vice access.
Unrealistic trust assumption. Difficult to maintain
and scale. Attribute aggregation from only two IdPs
in a single session.
IP Attribute aggregation from multiple IdPs in a single
session. The SP is easy to maintain. Relatively small
number of requirements.
The proxy IdP requiring huge trust might not be
suitable. The proxy IdP is the single point of fail-
ure. No implementation based on Shibboleth and
SimpleSAMLphp.
IR Attribute aggregation from multiple IdPs in a single
session. The SP is easy to maintain. Relatively small
number of requirements. Less trust on the relay IdP.
The relay IdP is the single point of failure. Hard to
maintain. No implementation based on Shibboleth
and SimpleSAMLphp.
CM No need to rely on external IdPs. Attribute aggrega-
tion from multiple IdPs in a single session. Relatively
small number of requirements.
No implementation exists currently. Extensive
changes are required to ensure that the IdPs, the
SPs and the client can interact.
[5] Bob Hulsebosch, Maarten Wegdam, Bas Zoetekouw,
Niels van Dijk, Remco Poortinga - van Wijnen.
Virtual collaboration attribute management. Accessed
on 1 May, 2013, 2011. http://www.surfnet.nl/nl/
Innovatieprogramma’s/gigaport3/Documents/EDS%
2011-06%20AttributeManagement%20v1.0.pdf.
[6] David W Chadwick. Federated Identity Management.
In A. Aldini, G. Barthe, and R. Gorrieri, editors,
FOSAD 2008/2009, number 5705 in LNCS, page
96-120. Springer-Verlag, Berlin, January 2009.
[7] D.W. Chadwick and G. Inman. Attribute aggregation
in federated identity management. Computer,
42(5):33-40, 2009.
[8] David Chappell. Introducing Windows CardSpace,
April 2006. http://msdn.microsoft.com/en-us/
library/aa480189.aspx.
[9] M.S. Ferdous and R. Poet. A comparative analysis of
Identity Management Systems. In High Performance
Computing and Simulation (HPCS), 2012
International Conference on, page 454-461, july 2012.
[10] George Inman, David W Chadwick, and Nate
Klingenstein. Authorisation using attribute from
multiple authorities-a study of requirements. In
Proceedings of HCSIT Summit-ePortfolio
International Conference, 2007.
[11] Audun Jøsang, John Fabre, Brian Hay, James Dalziel,
and Simon Pope. Trust requirements in identity
management. In Proceedings of the 2005 Australasian
workshop on Grid computing and e-research - Volume
44, ACSW Frontiers ’05, page 99-108, Darlinghurst,
Australia, Australia, 2005. Australian Computer
Society, Inc.
[12] N. Klingenstein. Attribute Aggregation and Federated
Identity. In Applications and the Internet Workshops,
2007. SAINT Workshops 2007. International
Symposium on, page 26-26, 2007.
[13] U. Kylau, I. Thomas, M. Menzel, and C. Meinel.
Trust Requirements in Identity Federation Topologies.
In Advanced Information Networking and
Applications, 2009. AINA ’09. International
Conference on, page 137-145, 2009.
[14] Md. Sadek Ferdous, Mohammad Jabed Morshed
Chowdhury, Md. Moniruzzaman, and Farida
Chowdhury. Identity federations: A new perspective
for Bangladesh. In Informatics, Electronics Vision
(ICIEV), 2012 International Conference on, page
219-224, may 2012.
[15] OASIS Standard. Assertions and Protocols for the
OASIS Security Assertion Markup Language (SAML)
V2.0. 15 March, 2005. http://docs.oasis-open.org/
security/saml/v2.0/saml-core-2.0- os.pdf.
... Beyond "security" and "authentication" it's important to include "user control" and "portability" in the design of digital identity systems. [30] Analyzes different models of attribute aggregation in federated identity management. Three models are detailed: aggregation at the SP, aggregation at the IdP, aggregation at the client. ...
... Attribute aggregation. Ferdous and Poet [30] analyzed different models of attribute aggregation in federated identity management systems. They discussed the trust requirements considering the classical actors in the federated model (SP, IdP, and the client), and they modeled attribute aggregation at each side. ...
... The SP has a trust relationship with the trusted IdP, and it is not aware of the other IdPs from where the attributes have been collected. There are some similarities between the Italian IdP Proxy (part of the eIDAS node) described in this paper and the trusted IdP in [30]. They both act as attribute collector and aggregator, trusted by the user. ...
Article
Full-text available
Within digital virtual space, secure and efficient user authentication and identification are essential to prevent identity theft and unauthorized access to sensitive information and services. The eIDAS network implementing the European (EU) Regulation 910/2014 links the electronic identity (eID) systems of EU countries to allow citizens to access services by authenticating with government eIDs. At authentication time, the eIDAS nodes transfer core personal attributes to the service providers (SPs), i.e., name, surname, date of birth, and an identifier. Since long-term applications require more personal or domain-specific data, e.g., to perform identity matching, the SPs must obtain them securely afterward in addition to the eIDAS attributes, with additional costs and risks. Herein, we extend the eIDAS network to retrieve and transfer additional person and domain-specific attributes besides the core ones. This process introduces technical, usability, and privacy issues that we analyze. We exploit a logical AP Connector acting between the eIDAS node and the local entities providing additional attributes. We implemented two AP Connectors, named AP-Proxy and AP-OAuth2, allowing the Italian pre-production eIDAS node to get additional attributes from the Politecnico di Torino university backend. In an experimental campaign, about 30 students have accessed academic services at three foreign universities with Italian eIDs and transferred additional attributes over the eIDAS network. Regardless of some usability and privacy concerns encountered, the user experience was positive. We believe our work is helpful in the implementation of the recently adopted European Digital Identity framework, which proposes to extend the person identification data set recognized cross border and the creation of digital wallets that link different data sets or credentials.
... Bien que ce problème a été largement étudié soit par des particuliers ou des groupes internationaux, relativement peu d'études ont été réalisées à ce sujet. Dans ce contexte, les études menées dans [37,208,209,210,211] [210], ont été utilisés dans [208] pour évaluer le niveau de confiance d'un IdP. Dans le même contexte, les auteurs dans [153], ont proposé une nouvelle taxonomie de critères de confiance pour la FIM dans le cloud computing. ...
... Bien que ce problème a été largement étudié soit par des particuliers ou des groupes internationaux, relativement peu d'études ont été réalisées à ce sujet. Dans ce contexte, les études menées dans [37,208,209,210,211] [210], ont été utilisés dans [208] pour évaluer le niveau de confiance d'un IdP. Dans le même contexte, les auteurs dans [153], ont proposé une nouvelle taxonomie de critères de confiance pour la FIM dans le cloud computing. ...
... Comme déjà mentionné dans les chapitres précédents, la sécurité est effectivement l'un des critères de confiance les plus importants dans la FIM [37,208,209,210,211]. Elle désigne l'ensemble des mécanismes permettant d'assurer la confidentialité, l'intégrité et la disponibilité des informations d'identités (voir figure 5.5) [37]. ...
Thesis
Full-text available
Secure and efficient management of identities remains one of the greatest challenges that facing cloud computing, where entities belonging to different domains continually exchange and share a huge amount of personal information. Federated Identity Management is considered the most useful solution that simplifies the user experience, by providing secure access to services belonging to different domains, while reducing the complexity and cost of managing a large number of user accounts. However, trust management is considered as one of the biggest obstacles to the wide adoption of this approach in cloud computing. Actually, poor management of trust carries significant security and privacy risks. Most of the proposed solution typically follow a similar architecture based on a preconfigured, static and closed circle of trust, in which interactions are only possible with pre-configured entities. Such a trust model is unsuitable for cloud computing, where interactions are carried out between prior unknown entities. For other frameworks, there is no specified model to manage trust between cloud service providers and identity providers, as cloud service providers must decide by themselves which identity providers are trustworthy. As an answer to these problems, we propose a new trust model that relies on Fuzzy Cognitive Maps and Blockchain for modelling and evaluating trust relationships between the involved entities in federated identity management systems. This trust mechanism facilitates the creation of trust relationships between prior unknown entities in a secure and dynamic way. This makes Federated Identity Management systems more scalable and flexible to deploy and maintain in cloud computing environments. We also propose a set of trust features for federated identity management systems, which serves as a basis for modelling and quantifying the trust level of unknown entities. The proposed set is intended to be generic compared to previous work and useful for any federated identity management protocol. Intensive experiments were conducted on a prototype of this trust model to prove its effectiveness in a cloud computing environment.
... Therefore, several providers are needed. Ferdous and Poet [9] provide a classification scheme to categorize different types of attribute aggregation models. The main distinctive feature is the location where the aggregation occurs: at the SP, at the IdP or at the side of the user. ...
... Fig. 7 presents the function to create a new authentication challenge for uPort. The function requires an application name, a DID and the associated private key to create credential object (line [3][4][5][6][7][8][9]. Additionally, the required claims are wrapped correspondingly in a claim or verified claim list (line 10-13). ...
Article
Full-text available
Identity management is a principle component of securing online services. In the advancement of traditional identity management patterns, the identity provider remained a Trusted Third Party (TTP). The service provider and the user need to trust a particular identity provider for correct attributes amongst other demands. This paradigm changed with the invention of blockchain-based Self-Sovereign Identity (SSI) solutions that primarily focus on the users. SSI reduces the functional scope of the identity provider to an attribute provider while enabling attribute aggregation. Besides that, the development of new protocols, disregarding established protocols and a significantly fragmented landscape of SSI solutions pose considerable challenges for an adoption by service providers. We propose an Attribute Trust-enhancing Identity Broker (ATIB) to leverage the potential of SSI for trust-enhancing attribute aggregation. Furthermore, ATIB abstracts from a dedicated SSI solution and offers standard protocols. Therefore, it facilitates the adoption by service providers. Despite the brokered integration approach, we show that ATIB provides a high security posture. Additionally, ATIB does not compromise the ten foundational SSI principles for the users.
... In all these studies, the set of the required trust features is typically divided into security, privacy, and functional requirements. Proposed features in [41] were used in [42] to evaluate trust between entities in a federation and to assess the quality of service provided by IdPs or CSPs. In [43], the authors proposed a novel taxonomy of trust risks in cloud FIM, which were divided into three main categories: security and privacy, knowledge, and interoperability. ...
Article
Abstract—Efficient identity management system has become one of the fundamental requirements for ensuring safe, secure and transparent use of cloud services. In such a borderless environment, entities belonging to different network domains need to cooperate dynamically with each other by exchanging and sharing a significant amount of personal information in a scalable, effective and seamless manner. The traditional approach to address this challenge has been identity federation, aiming to simplify the user experience by aggregating distributed rights and permissions. However, the current federated identity man- agement solutions are missing mechanisms to achieve agile and dynamic trust management, which remains one of the biggest obstacles to their wide adoption in cloud computing. In this paper, we aim to address this issue by introducing a novel dynamic trust model for Federated Identity Management. The proposed model relies on fuzzy cognitive maps for modelling and evaluating trust relationships between the involved entities in federated identity management systems. This trust mechanism facilitates the creation of trust relationships between prior unknown entities in a secure and dynamic way and makes Federated Identity Management systems more scalable and flexible to deploy and maintain in cloud computing environments. In addition, we pro- pose a set of trust features for Federated Identity Management, which serves as a basis for modelling and quantifying the trust level of unknown entities. The effectiveness of the proposed trust model is proven through performance analysis and experimental results.
... The proposed work in [36] provides a taxonomy of the attribute aggregation models discussed in the work of [35], and categorizes different requirements in a systematic manner. The results have been presented in tabular form to compare all models side-by-side. ...
Article
Full-text available
Several countries have invested in building their identity management systems to equip citizens with infrastructures and tools to benefit from e-services. However, current systems still lack the interoperability requirement, which is the core issue that could lower the wide benefits of having an identity management system. In fact, in the existing systems, the user is allowed to choose only one partial identity from an identity provider (IdP) during a single session with a service provider (SP). However, in some scenarios, an SP needs to retrieve information about user’s identities managed by multiple IdPs. The potential method to tackle these shortcomings is attribute aggregation from multiple identity providers. A number of initiatives and projects on attribute aggregation have been explored. Nevertheless, these constructions do not fulfill some identity management requirements. This paper describes a new flexible model that aims to provide the necessary mechanisms to ensure attribute aggregation in order to meet the interoperability challenges of current identity management systems. The proposed scheme is a scalable solution, based on identity federation technologies, that introduces a new IdP called an account linking provider (ALP). The purpose of this ALP is to link together different accounts, holding end users’ attributes, whenever more than one source of data is needed to grant access to the requested web resource in a single session. Furthermore, the proposed identity federation system is based on a streamlined, cost-effective, and interoperable architecture, which makes this model suitable for large-scale identity federation environments.
... In the FIM context, there is no unified standard to select trust factors. There are only few research projects dealing with analyzing and identifying trust factors in FIM such as [20], [21], [22] and [23]. Based on these works, we have proposed the following trust factors ( Table 2). ...
Conference Paper
With the proliferation of Cloud-based services, Federated Identity Management (FIM) has gained considerable attention in recent years. It is considered as a promising approach to facilitate secure resource sharing between collaborating partners in the Cloud. However, current FIM frameworks such as OpenID, SAML, Liberty Alliance, Shibboleth and WS-Federation do not define a suitable trust model to allow dynamic and agile federation establishment. Hence, they cannot be deployed in dynamic and open environments like Cloud Computing. In this paper, we address this issue by presenting a new dynamic trust model that fulfils Cloud requirements. The proposed model introduces the theory of Fuzzy Cognitive Maps (FCM) into modelling and evaluating unknown entities trustworthiness in FIM systems.
Article
Full-text available
In the last decade or so, we have experienced a tremendous proliferation and popularity of different Social Networks (SNs), resulting more and more user attributes being stored in such SNs. These attributes represent a valuable asset and many innovative online services are offered in exchange of such attributes. This particular phenomenon has allured these social networks to act as Identity Providers (IdPs). However, the current setting unnecessarily imposes a restriction: a user can only release attributes from one single IdP in a single session, thereby, limiting the user to aggregate attributes from multiple IdPs within the same session. In addition, our analysis suggests that the manner by which attributes are released from these SNs is extremely privacy-invasive and a user has very limited control to exercise her privacy during this process. In this article, we present Social Anchor, a system for attribute aggregation from social networks in a privacy-friendly fashion. Our proposed Social Anchor system effectively addresses both of these serious issues. Apart from the proposal, we have implemented Social Anchor following a set of security and privacy requirements. We have also examined the associated trust issues using a formal trust analysis model. Besides, we have presented a formal analysis of its protocols using a state-of-the-art formal analysis tool called AVISPA to ensure the security of Social Anchor. Finally, we have provided a performance analysis of Social Anchor.
Chapter
Identity management is a fundamental component in securing online services. Isolated and centralized identity models have been applied within organizations. Moreover, identity federations connect digital identities across trust domain boundaries. These traditional models have been thoroughly studied with regard to trust requirements. The recently emerging blockchain technology enables a novel decentralized identity management model that targets user-centricity and eliminates the identity provider as a trusted third party. The result is a substantially different set of entities with mutual trust requirements. In this paper, we analyze decentralized identity management based on blockchain through defining topology patterns. These patterns depict schematically the decentralized setting and its main actors. We study trust requirements for the devised patterns and, finally, compare the result to traditional models. Our contribution enables a clear view of differences in trust requirements within the various models.
Article
Full-text available
This paper presents the results of a survey of requirements for attribute aggregation in authorisation systems, gathered from an international community of security professionals. It then analyses these requirements against 4 generic models for attribute aggregation and makes some recommendations for future implementations. Before embarking on developing a solution to the attribute aggregation problem, we first thought it would be beneficial to determine a set of system requirements. We realised that determining end user (i.e. consumer or customer) requirements directly from the end users would be difficult at this stage, since most end users would not be sufficiently conversant with the problem space or terminology to present us with their considered requirements. Consequently the people we surveyed were security professionals who are already working in the general area of network authorisation and virtual organisations, and who are already aware of this problem space. We designed a questionnaire to explore the requirements for a new ABAC system that can be used to query multiple attribute authorities and return a set of aggregated attributes based on the multiple sets returned from the AAs. The methodology we employed, and the results of the questionnaire responses are presented in Section 2. In Section 3 we describe 4 generic models for attribute aggregation and analyse these requirements against those models. Section 4 concludes with our future plans for work in this area.
Conference Paper
Full-text available
With a view to provide more effective, enhanced and accessible services to their citizens, Governments around the globe have started different web services under the initiative of e-Government. Many such services extensively utilise the Federated Identity framework due to its huge number of benefits. This paper analyses how different e-initiatives in Bangladesh can take advantage of this technology by illustrating use-cases in two different domains. As the online service and the e-Governance paradigm in Bangladesh are relatively new and evolving rapidly, we believe that this is the high-time to consider the benefits this technology can bring for the Government as well as the citizen.
Conference Paper
Full-text available
In this paper, we present a comparative analysis of a few popular Identity Management Systems against a set of requirements. Identity Management and Identity Management Systems have gained significant attention in recent years with the proliferation of different web-enabled and e-commerce services leading to an extensive research on the field in the form of several projects producing many standards, prototypes and application models both in the academia and the industry. We have collected and compiled different requirements from different sources to profile an extensive set of requirements that are required for a Privacy-Enhancing Identity Management System and presented them in the form of a taxonomy. Then we have compared some Identity Management Systems against those requirements and presented them in a concise way to help readers find out instantly which systems satisfy what requirements and thus help them to choose the correct one to fit into their own scenarios.
Article
Full-text available
The SAML V2.0 Assertions and Protocols specification defines the syntax and semantics for XML-encoded assertions about authentication, attributes, and authorization, and for the protocols that convey this information. This document, known as an "errata composite", combines corrections to reported errata with the original specification text. By design, the corrections are limited to clarifications of ambiguous or conflicting specification text. This document shows deletions from the original specification as struck-through text, and additions as colored underlined text. The "[Enn]" designations embedded in the text refer to particular errata and their dispositions.
Chapter
Full-text available
This paper addresses the topic of federated identity management. It discusses in detail the following topics: what is digital identity, what is identity management, what is federated identity management, Kim Cameron’s 7 Laws of Identity, how can we protect the user’s privacy in a federated environment, levels of assurance, some past and present federated identity management systems, and some current research in FIM.
Article
Full-text available
Most federated identity management systems are limited by users' ability to choose only one identity provider per service session. A proposed linking service lets users securely link their various identity provider (IdP) accounts, enabling the system to aggregate attributes from multiple authoritative sources automatically without requiring users to authenticate separately to each IdP.
Conference Paper
Full-text available
Conference Paper
Federated identity management describes a model to enable users to use their digital identities in collaborating companies regardless of organizational borders. The essential pre-requisite to share the user authentication across different security domains is the establishment of trust between the collaborating partners. Usually, this is done by setting up complex contracts, that describe common policies, obligations and procedures to be followed by each collaboration member. The result is a federation, or Circle of Trust, in which each member is willing to trust on assertions made by someone else. Naturally, federations are no isolated structures and members of one federation might also be part of another one - a constellation possible with current federation technologies. However, whether and how the trust relationships of federations can be used to allow access even across multiple federations is a question which has not been answered yet. In this paper, we investigate trust requirements for identity federation topologies. Starting from the classical structure of a Circle of Trust, we go beyond this and identify more complex patterns such as overlapping federations. For each pattern, we identify risks for identity and service providers as well as the necessary trust requirements that must be met to allow such constellations.
Conference Paper
A principal sometimes needs to present a combination of attributes from multiple identities from distinct organizations to fully identify itself This problem is rarely encountered in non-federated identity transactions because services operate within the context of a single identity domain. Federated identity allows for data about one entity to be scattered across multiple identities throughout the distributed system. These data must be unified through attribute aggregation to fully identify an entity. In order to do so, the identities must be associated in some fashion, the user must have a session with a service, and the service must have all the information it needs to process the attributes it receives
Conference Paper
Identity management refers to the process of representing and recognising entities as digital identities in computer networks. Authentication, which is an integral part of identity management, serves to verify claims about holding specific identities. Identity management is therefore fundamental to, and sometimes include, other security constructs such as authorisation and access control. Different identity management models will have different trust requirements. Since there are costs associated with establishing trust, it will be an advantage to have identity management models with simple trust requirements. The purpose of this paper is to describe trust problems in current approaches to identity management, and to propose some solutions.