ArticlePDF Available

Managing Dynamic Identity Federations using Security Assertion Markup Language

Authors:

Abstract and Figures

Security Assertion Markup Language (SAML, in short) is one of the most widely used technologies to enable Identity Federations among different organisations. Despite its several advantages, one of the key disadvantages of SAML is that it does not allow creating a federation in a dynamic fashion to enable service provisioning (or de-provisioning) in real time. A few approaches have been proposed to rectify this problem. However, most of them require elaborate changes of the SAML and do not provide mechanisms to manage federations dynamically. This paper presents a better approach based on an already drafted SAML Profile and thus requires no change of the SAML, rather it depends on the specific implementation of SAML. Our proposed approach covers all aspects regarding the management of dynamic Identity Federation. It will allow users to create federations dynamically using SAML between two prior unknown organisations and will allow them to manage such federations as long as it is required. Implicit in each identity federation is the issue of trust. Therefore, the trust issues involved in the management of dynamic federations are analysed in details. Moreover, a proof of concept is discussed to elaborate the practicality of our approach for managing dynamic federations. Finally, a few use-cases are outlined to illustrate how federations created dynamically can be used to access online services.
Content may be subject to copyright.
1
Md. Sadek Ferdous
Ron Poet
Managing Dynamic Identity Federations using Security Assertion Markup Language
(SAML)
Accepted for publication at the Journal of Theoretical and
Applied Electronic Commerce Research (JTAER)
Managing Dynamic Identity Federations using Security
Assertion Markup Language (SAML)
Md. Sadek Ferdous1 and Ron Poet2
1 School of Computing Science, University of Glasgow, Glasgow, Scotland, m.ferdous.1@research.gla.ac.uk
2 School of Computing Science, University of Glasgow, Glasgow, Scotland, Ron.Poet@glasgow.ac.uk
Abstract
Security Assertion Markup Language (SAML, in short) is one of the most widely used technologies to enable
Identity Federations among different organisations. Despite its several advantages, one of the key
disadvantages of SAML is that it does not allow creating a federation in a dynamic fashion to enable service
provisioning (or de-provisioning) in real time. A few approaches have been proposed to rectify this problem.
However, most of them require elaborate changes of the SAML and do not provide mechanisms to manage
federations dynamically. This paper presents a better approach based on an already drafted SAML Profile and
thus requires no change of the SAML, rather it depends on the specific implementation of SAML. Our proposed
approach covers all aspects regarding the management of dynamic Identity Federation. It will allow users to
create federations dynamically using SAML between two prior unknown organisations and will allow them to
manage such federations as long as it is required. Implicit in each identity federation is the issue of trust.
Therefore, the trust issues involved in the management of dynamic federations are analysed in details.
Moreover, a proof of concept is discussed to elaborate the practicality of our approach for managing dynamic
federations. Finally, a few use-cases are outlined to illustrate how federations created dynamically can be used
to access online services.
Keywords: Identity Management, Federated Identity Management, Identity Federation, Security
Assertion Markup Language (SAML), Trust.
2
Md. Sadek Ferdous
Ron Poet
Managing Dynamic Identity Federations using Security Assertion Markup Language
(SAML)
Accepted for publication at the Journal of Theoretical and
Applied Electronic Commerce Research (JTAER)
1 Introduction
With the continuous evolution of web-enabled (or online) services in the last decade or so, the way those services
can be accessed has changed considerably. Many of those services require that the users must register themselves
with the Service Provider (SP, in short; organisations that provide online services) to access its services. This is
required to provide users with more personalised services as well as to ensure accountability at the SP. Users are
issued with digital identities consisting of identifiers and related credentials which users need to present while
accessing such services. As the number of web-enabled services as well as the user-base was expanding rapidly,
more and more identities and credentials were issued, and soon their management became challenging, both for
service providers and for users. Identity Management (IdM, in short) was introduced by the industry to facilitate
online management of user identities which resulted in various different Identity Management Systems (IMS, in
short). Initially, these systems were not interoperable, meaning digital identities in one system was not recognised by
others. As a matter of fact, interoperability was not considered to be important as different organisations managed
their own user-bases by themselves in-house.
However, as the landscape for web and web-based services started to change, novel business scenarios started to
emerge. One prominent example of such scenarios was the cooperation between disparate organisations to provide
conglomerated services among business partners. To facilitate such collaborations, organisations felt the necessity
to expand their service bases not only to an ever-growing number of users within the organisation but also to users
from their business partners. This need gave rise to a novel model of Identity Management known as the Federated
Identity Management (FIM, in short) [1], [2]. The FIM offers a flexible and secure way to establish Identity Federation
(also known as Federated Identities or Federation of Identities) among organisations from different security domains.
This allows organisations to reduce complexities in sharing their protected online resources with users of other
organisations that are part of the same identity federation as well as offers much improved user experience by
reducing the number of identifier/credential pairs that the users need to remember. There are several core
technologies available that allow the creation of federations such as Security Assertion Markup Language (SAML) [3],
OpenID [4], WS-Federation [5], etc.
Among them, OpenID is merely an authentication protocol where federations can be achieved in a limited way. With
the use of its Attribute Exchange extension, attributes can be exchanged among different organisations [6]. Even
though OpenID is a very popular authentication protocol for web-enabled services, it is not favoured by many
organisations due to its “trust everyone policy that virtually asks every organisation to trust other organisations [7]. A
new extension called PAPE (Provider Authentication Policy Extension) [8] was proposed in 2008 for enforcing trust
mechanisms in a very limited way. Therefore it is safe to say that trust, security and privacy issues have not been
addressed thoroughly in the OpenID as of yet.
WS-Federation is a federation model with the aim to simplify the cross-domain service access and interaction among
several parties. It is a part of the Web Service Protocol Stack (WS-*) which includes WS-Security, WS-SecurityPolicy,
WS-MetadataExchange, WS-Trust, etc. Utilising these protocols, WS-Federation allows the creation of a federation
that is based on strong trust assumptions and satisfies reasonable amount of security and privacy requirements [9]
Windows CardSpace was based on WS-Federation [10] and was thought to be the driving force for widespread
adoption of the WS-Federation. With the demise of CardSpace, the widespread adoption of WS-Federation is
uncertain and also in reality it has not been widely used to deploy a federation.
On the other hand, SAML has been the most widely used technology for deploying federations in scenarios when
there is a need of a federation that requires strong trust assumptions as well as maintains good security and privacy
properties. This is why it is favoured as the pick of the technologies by many educational institutes and
Governmental web-enabled services all over the world. Despite its several advantages, one major constraint is the
method by which trust is established and maintained in the SAML. To enable federations using SAML, trust among
participating organisations has to be pre-configured by system administrators. Pre-configuring trust before any
interaction hinders the establishment of a federation between two prior unknown parties in a dynamic fashion.
Allowing federations to be created dynamically would open up the door for new business scenarios and novel web-
enabled services. There have been several proposals and drafts to handle this situation. Most of these works either
require a considerable amount of change of the SAML protocol or only provide mechanisms for creating federations
in a semi-automated fashion. And also the trust issues involved while creating federations in a semi-automated
fashion are not thoroughly examined.
To rectify the stated problems a better mechanism was proposed to create federations in a fully automatic dynamic
fashion in our previous work [11]. In that work, the key concepts behind dynamic federation were formally defined,
trust issues in such scenarios were explored and a proof of concept to illustrate the applicability of the proposal was
described.
This paper presents an extension of our previous work. Here, it has not only been considered how a dynamic
federation can be created, but also have been investigated how such federations can be managed dynamically. The
contributions of the current paper over our previous work are:
3
Md. Sadek Ferdous
Ron Poet
Managing Dynamic Identity Federations using Security Assertion Markup Language
(SAML)
Accepted for publication at the Journal of Theoretical and
Applied Electronic Commerce Research (JTAER)
A new Section to introduce the key concept of Identity and Federated Identity Management has been added. The
term Identity Management is not well defined. Therefore, a more concrete definition of Identity Management has
been provided in that section.
The notion of the life-cycle of the traditional SAML federation encompassing the whole spectrum of the
management of federations has been introduced. Then the notion with respect to the dynamic identity federation
has been analysed
It has been discussed how the feature of the life-cycle of identity federation has been incorporated into our
proposal using a few use-case scenarios.
Novel features have been added to allow users to manage dynamic federations where one of the entities may
reside in the local machine from where the user is accessing the service. This feature can be used to federate
locally installed IdPs in dynamic fashion.
With this introduction, this paper is organised as follows. Section 2 provides a brief introduction on some key
concepts of Identity and Federated Identity Management. Some existing works are discussed and heir strengths and
weaknesses are analysed in Section 3. Then, some key concepts of Dynamic Federation are defined and the trust
issues are explored in Section 4. The developed proof of concept is discussed for two different scenarios in Section
5 and in Section 6. The strengths and weaknesses of our implementation as well highlight potential future works are
presented in Section 7. Finally, the paper is concluded in Section 8.
2 Background
In this section a brief introduction on Identity, Identity Management, Federated Identity Management and SAML is
presented. In addition, the trust issues involved in a federation are discussed and how these issues are addressed in
SAML are analysed.
2.1 Identity, Identity Management & Other Related Topics
A physical or logical object with a separate and distinctive existence, physically or logically, can be denoted as an
Entity [12]. It has different interpretations in different disciplines. In the context of this paper it represents a person,
an organisation or a machine (computer) operated by persons or organisations. Identity is the fundamental property
of an entity that declares the uniqueness of that entity and helps to differentiate it from other entities [12]. It is by this
property everything around us physically and virtually are identified. However, an entity can be identified by separate
identities in separate environments or contexts. Each of these identities is usually known as a partial identity. Each
partial identity may consist of a set of characteristics which are known as attributes. Among these attributes, the one
which is used to uniquely identify an entity within a context is known as the Identifier. Social Security Number or
national ID number in a country and a user-id in an application scenario, email addresses, etc. are examples of
Identifiers.
Before looking at different aspects of Identity Management, a definition of the term Identity Managementwould be
useful. Surprisingly, a large variation of definitions of Identity Management exists and can be found in [13], [14], [15],
[16], [17]. These definitions are simple to understand, unfortunately they only focus on the identification,
representation and management of identities and do not cover all the aspects (which will be described shortly) of
Identity Management. The definition provided in the ITU-T X.1250 Recommendation is the closest in spirit to the
definition according to our understanding [18]. Unfortunately, it also fails to capture some other aspects of Identity
Management that have been captured in the definitions mentioned in the beginning. It seems that none of these
definitions can capture the full notion of identity management, however, a comprehensive definition that satisfies all
aspects of Identity Management can be created by combining different previous definitions which is provided next:
Definition 1. Identity Management - Identity Management is a set of functions and capabilities (e.g., administration,
management and maintenance, discovery, communication exchanges, correlation and binding, policy enforcement,
authentication and assertions) used for:
creation and management of identity information (e.g., identifiers, partial identifiers, credentials, attributes);
assurance of identity information;
assurance of the identity of an entity (e.g., users/subscribers, groups, user devices, organisations, network and
service providers, network elements and objects, and virtual objects);
selection of identity information to be used for authorisation and for service provisioning; and
supporting business and security applications.
A system that is used for managing the user identity is called an Identity Management System (IMS). Shibboleth [19],
OpenID [4], Microsoft's CardSpace [10], etc. are examples of different Identity Management Systems which use
SAML, OpenID and WS-Federation technologies respectively. Each of these IMS has three different types of actors
which are described next:
4
Md. Sadek Ferdous
Ron Poet
Managing Dynamic Identity Federations using Security Assertion Markup Language
(SAML)
Accepted for publication at the Journal of Theoretical and
Applied Electronic Commerce Research (JTAER)
Identity Provider (IdP). An IdP is responsible for managing digital identities of users and providing identity
related services to different Service Providers. IdPs are also known as Asserting Parties (AP).
Service Provider (SP). A SP is responsible to provide web-enabled services to the users based on the identity
information (identifiers and/or attributes) received from the IdP. SPs are also known as Relying Parties (RP).
User (Client). A user/client receives services from a SP.
With these three parties, each IMS, generally, follows the following steps to allow any user to manage her identity
which in turn is used to access online services. This set of steps is also known as the Life-cycle of an IMS.
Registration. It is the initial step in which a user registers herself at the respective IdP (or at SP) by providing
different personal information along with an identifier and a credential.
Identification & Authentication. Before any service can be accessed, the user needs to be identified and then
authenticated. The most common form of doing this is to use the identifier (username) and the credential
(password).
Assertion/Claim Exchange. This step is required when the IdP and the SP reside in different security domains
which involves exchanging identity information between the IdP and the SP using a predefined protocol. Different
protocols have different names for identity information, e.g. SAML calls it the Assertion while WS-Federation calls
it a Claim [3], [5].
Authorisation. Authorisation is a process to decide if a certain action is allowed by an entity based on her
identifier or attributes. Once the user is authenticated at an IdP and the assertion/claim regarding the user is
transferred to the SP, the SP has to check if a particular action is allowed by this user.
Service Provisioning. Once the user is identified, authenticated and authorised to access a particular service,
she can access the service. The phase of accessing a service is known as the service provisioning.
De-registration. The final step in the Identity Management is the De-registration process which allows any user
to de-register from a service that the user does not wish to access any more. The de-registration process usually
removes the association between an entity and the identifier as well as deletes any related personal information
from the IdP.
2.2 Federated Identity Management
The Federated Identity Management model is based on the concept of Identity Federation. In the ITU-T X.1250
recommendation, a federation is defined simply as “An association of users, service providers and identity providers
[18]. In other words, a federation with respect to the Identity Management is a business model in which a group of
two or more trusted parties legally bind themselves with a business and/or technical contract [1], [2]. It allows a user
to access restricted resources seamlessly and securely from other partners from different Identity Domains. An
identity domain is the virtual boundary, context or environment in which a digital identifier is valid [2]. Single Sign On
(SSO) is the capability that allows users to log in to one system and then access other related but autonomous
systems without further logins. It alleviates the need to log in every time a user needs to access those related
systems. A good example is the Google Single Sign On service which allows users to log in a Google service, e.g.,
Gmail, and then allows them to access other Google services such as Calendar, Documents, YouTube, Blogs and
so on.
A federated identity domain can be formed consisting of only one IdP in an identity domain and more than one SP
with each SP residing in a separate identity domain (Type 1 in Figure 1). Several identity domains can be combined
to form a larger identity domain where each smaller federated domain is of Type 1 (Type 2 in Figure 1). The issue of
trust is a fundamental concept in FIM as different autonomous participating organisations need to trust each other
inside the federation to allow them to exchange user information and trust that information. Such parties inside a
federation are said to form the so-called Circle of Trust (CoT). The dashed boundary in each figure signifies the
federated identity domain, that is a single Circle of Trust and each solid circle represents a separate identity domain.
That is, IdP1 and other SPs in Figure 1(a) and IdP1, IdP2 and all SPs in Figure 1(b) are part of a single Circle of
Trust respectively. Federated Identity Domain 1 and 2 in Figure 1(b) represent a combined Type 2 federated domain.
(a) Type 1. (b) Type 2.
Figure 1: Federated Identity Domain
5
Md. Sadek Ferdous
Ron Poet
Managing Dynamic Identity Federations using Security Assertion Markup Language
(SAML)
Accepted for publication at the Journal of Theoretical and
Applied Electronic Commerce Research (JTAER)
A detailed analysis of trust requirements for FIM can be found in [20]. From [20], the SP needs to trust that the IdP
will authenticate the user using appropriate security mechanisms and release attributes to the SP as per the
contractual agreement. 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. Based on this trust level, users will be granted to access a service
or rejected.
The FIM offers a good number of advantages to different stakeholders [21], [1]:
The separation of duties among different organisations is the main advantage of FIM. IdPs only concentrate on
managing identities and providing identity information to the SPs and SPs concentrate only on providing services
based on the identity information to authenticated users. Such separation allows SPs to offload the associated
cost of managing and maintaining user identities to trusted IdPs.
FIM provides scalability in the sense that it allows SPs to offer their services not only to their user-bases, but also
to users from other SPs and thus maximising the number of consumers using the same infrastructure.
It is also attractive from the IdP's perspective as it allows IdPs to maintain an association with end users and
enables them to access an array of diversified services with the same identity.
FIM utilises standardised approach to ensure the improved security and privacy of users and make sure that the
personally identifiable information is minimally propagated and thereby reduces the risk of identity theft.
The circle of trust can easily be expanded by integrating new application and service partners into the federation.
It takes a minimal effort for any new partner to be a part of that circle as they need not to worry about managing
user-base.
It gives users the single sign on (SSO) facility which allows them to avail services from different providers without
any further logins. This also reduces the need to maintain personal profiles on different locations. Thus SSO
improves efficiency and enhances user experience.
FIM also alleviates users from remembering different user-ids and their related credentials as only a few
accounts at different IdPs might be enough to access different services from the SPs. In this sense, it also
increases security imperatively as only a very few accounts are managed by a user; a strong password can be
chosen and easily remembered.
2.3 Life-cycle of an Identity Federation
Once an entity joins in a federation, it will remain there as long as the contract allows. During this time it might be
required to update corresponding information of that entity inside the federation. Finally, the entity must be removed
from the federation once the contract ends or the entity wants to leave the federation. These tasks are carried out at
the admin level by the respective administrators and are integrated functionalities of a federation. These tasks can
be combined to introduce the notion of the Life-cycle for an identity federation.
The life-cycle of an identity federation implies the steps that are required to create, revoke, maintain and to utilise a
federation. The steps are:
Association (Federation). The association is the process by which a SP is added to a new or existing federation. At
this step, the metadata of the SP and the IdP are exchanged and then their metadata are stored in the respective
TAL (Trust Anchor List, see below) and thus the trust between these two entities are established.
Provisioning. This is the intermediary step in which the entities (the IdP or SP) utilise the federation to offer services
to the users.
Maintenance. This intermediary step allows the admin to update any information inside the metadata of the
respective entities.
Revocation (Defederation). In this step, the SP is defederated (removed) from the federation. To do this, the IdP
simply removes the metadata of the respective SP from its TAL and the SP removes the metadata of the IdP from its
TAL.
These four steps essentially define the way a federation can be managed and will be used to demonstrate the
applicability of our proposal for managing a dynamic identity federation in the subsequent section.
2.4 Security Assertion Markup Language (SAML)
SAML is an XML-based standard for exchanging authentication and authorisation information between different
autonomous security domains. It is based on the request/response protocol in which one party (generally SPs)
requests for particular identity information about a user and the other party (usually, IdPs) then responds with the
information, so that the user can be identified and authenticated at its end. The whole language comprises of four
key concepts: assertions, protocols, bindings and profiles. A SAML assertion is the declaration about a user asserted
by the IdP for a service provider. In its most general form an assertion states the following [3], [22]: “The assertion A
issued at time T by issuer (IdP) I about the user U as long as conditions C are valid”.'
6
Md. Sadek Ferdous
Ron Poet
Managing Dynamic Identity Federations using Security Assertion Markup Language
(SAML)
Accepted for publication at the Journal of Theoretical and
Applied Electronic Commerce Research (JTAER)
An assertion can contain three different types of statements which the SP uses for providing service to the user: i)
Authentication statement is used to assert that the user has been authenticated by the asserted IdP at the specified
time, ii) Attribute statement is used to specify the attributes of the user and iii) Authorisation statement is used to
assert that the user is permitted a certain action on the specified resource under some conditions. The SAML
protocol is used to define the rules on how to pack the SAML elements inside the request/response packet and on
how to process them on receipt.
SAML binding is used to map the SAML protocol into the 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 previously mentioned 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 [23]. A SAML protocol flow
based on the Web Browser SSO Profile where both the IdP and the SP use the HTTP Post binding is illustrated next
[22]:
1. A user wants to access a service provided by a SP (anyserver.com). The user uses her browser to request to
access the resource.
2. The SAML interface in the SP traps the request and redirects the user to the Discovery Service, also known as
the Where Are You From (WAYF) Service, where a pre-configured list of trusted IdPs are shown to the user. The
user selects one of the IdPs.
3. The SAML interface at the SP builds a SAML Authentication Request element. This element is deflated, base64-
encoded, URL-encoded and then inserted into an XHTML Form and is sent back to the user in response to that
previous request.
4. The browser retrieves a few values from the form and submits a POST request to the chosen IdP using those
values.
5. The SAML interface (in this case the SSO service) in the IdP traps the request and checks using cookies if there
is any security context (Identity information, meaning if the user is already authenticated) regarding the user at
the IdP. If so, Step 6 is ignored.
6. The user authentication takes place. There are many authentication mechanisms supported by the SAML and the
one used depends on the respective IdP.
7. The SSO Service returns an XHTML form that contains the SAML Response.
8. The browser extracts the SAML Response and a few parameters from the form and issues an HTTP Post
Request to the Assertion Consumer Service of the SP with these retrieved values.
9. The Assertion Consumer Service at the SP extracts the Response, validates it and if everything is okay, creates
a security context for the user at the SP. The user is re-directed to the requested resource.
10. The browser again submits an access request to the SP.
11. As there exists a security context this time, the SP checks if the user is authorised to access the resource. If so,
the resource is returned to the user. If not, the resource is not returned and an error message is displayed to the
user.
The concept of trust and trust management on the setting of online services is a widely studied topic. There exists a
numerous amount of work on these topics and the way the concept of trust has been defined or considered vary
considerably on these works. For the purpose of this paper, we prefer the following definition quoted from [24] which
ultimately was inspired from [25] is preferred: “Trust is the extent to which one party is willing to depend on
something or somebody in a given situation with a feeling of relative security, even though negative consequences
are possible". In the setting of identity federation, this definition outlines how much one entity in the federation can
rely upon another entity inside the same federation. This notion essentially exemplifies trust as confidence as
illustrated in [26].
The issue of such trust plays a central role in SAML. Trust in SAML is established by exchanging metadata of the
IdP and the SP and then storing them at the appropriate repositories which helps each party to build up the so-called
Trust Anchor List. This exchange takes place in out-of-bound fashion after a technical contract between the IdP and
the SP is signed and has to be done before any interaction takes place between the said IdP and the SP. A
metadata is an XML file in a specified format that plays the central role in SAML. It contains several information such
as entity descriptor (known as the entity ID, an identifier for each party), service endpoints (the locations of the
appropriate endpoints for IdPs where the request will be sent to and for SPs where the response will be consumed),
certificate, expiration time of metadata, contact information, etc. and serves three purposes. Firstly, it allows each
organisation to discover the required endpoint of another organisation for sending SAML request/response. Secondly,
the embedded certificate can be used by the SP to verify the authenticity of the SAML Assertion. Thirdly, a metadata
behaves like an anchor of trust for each party. During the discovery service at the SP, the list only contains those
IdPs whose metadata can be found in its meta repositories (in other words in the TAL) and thus considered trusted.
Similarly, an IdP will respond only to those requests that are initiated from a SP whose metadata can be found in its
7
Md. Sadek Ferdous
Ron Poet
Managing Dynamic Identity Federations using Security Assertion Markup Language
(SAML)
Accepted for publication at the Journal of Theoretical and
Applied Electronic Commerce Research (JTAER)
metadata repositories (in its TAL). Exchanging and maintaining the repositories of metadata and thus managing trust
becomes extremely difficult as the number of the IdPs and SPs grows up and is a well-known problem of the SAML
[27]. In addition, pre-configuring trust before any interaction hinders to establish a federation between two prior
unknown parties in a dynamic fashion. Allowing to create federations in a dynamic fashion would open up the door
for new business scenarios and novel web-enabled services. In this paper, this issue is addressed.
3 Related Work
There have been several works to tackle the problem of scalability and dynamism of SAML. The most influential
work, called Distributed Dynamic SAML, can be found in [28] where the authors prescribe that to trust any
dynamically exchanged metadata, the metadata must be signed and the X.509 certificate that can be used to verify
the signature must be included within the metadata. Assuming a trusted Certificate Authority (CA) issues the
embedded certificate, each participating organisation will hold the root CA Certificates which can be used to validate
the certificate chain in its TAL. Then, the trust on the metadata can be derived by just verifying the signature in the
metadata using the embedded certificate with the traditional PKI. The result of their proposal is the formulation of a
working draft of a novel SAML Profile called SAML Metadata Interoperability Profile which is a profile for a distributed
SAML metadata management system [29], [30]. Based on the proposal and the working draft, an implementation of
dynamic SAML has been developed by UNINETT (https://www.uninett.no/) in their SimpleSAMLphp project [31], [32].
The SimpleSAMLphp is a native php-based implementation of the SAML protocol stack that can be used to quickly
deploy a SAML IdP or SP. The proposal and the working draft and the SimpleSAMLphp implementation would allow
the establishment of federations more quickly than it would be possible previously. However, several crucial
questions regarding trust assumptions at different parties have not been explored thoroughly. For example, each
party (IdP and SP) validates the certificate of other parties using PKI to establish trust. However, is the established
trust enough for any IdP to release sensitive user attributes to a SP which has been added dynamically since there
may not be any legal contract between them? And also, since there may not be any legal binding, can the IdP trust
that the SP would not abuse the released attribute in any way? Similarly, the SP will need to consider if it can trust
any attributes that have been provided by a dynamically added IdP even though the SAML assertion containing
those attributes are properly verified.
Furthermore, the SimpleSAMLphp implementation requires that the metadata of the IdP is already present at the SP
so that the WAYF (Where Are You From) Service (and IdP discovery service) can display the list of the IdPs to the
user. Once the user selects an IdP, a SAML authentication request will be sent to the IdP. If the IdP has the
capability to add a SP dynamically (e.g. an IdP deployed with SimpleSAMLphp), it can retrieve the metadata of the
SP dynamically and store it temporarily in case the entity ID of that SP is not found in its TAL. To make this possible,
the SimpleSAMLphp requires that the entity ID of the SP has to be a URL from where the metadata can be fetched.
In summary, the SimpleSAMLphp only allows IdPs to retrieve any SP metadata, not the other way around. It can be
regarded as a semi-automatic federation where the IdP has to be pre-configured at the SP and thus does not fully
address the problem of dynamic federation.
There are other existing works that also provide proposals for dynamic federations. In [7], the authors propose a
SAML extension to accommodate reputation data in XML format. According to their proposal, trust has to be
negotiated based on that reputation data before any entity can join the federation. Each entity will maintain a
dynamic list called Dynamic Trust List (DTL), instead of the static TAL, which will contain the list of joined entities in
the same federation with their reputation data and will be updated dynamically as the federation evolves. To realise
their proposal, a novel exchange protocol has to be developed to request and respond with reputation data. The
authors in [33] proposed a dynamic federation architecture, called DFed, based on SAML and Automatic Trust
Negotiation (ATN) to establish trust between participating parties in run time. Each DFed party, known as Dynamic
Federation Service Providers (DFSP), can act as an IdP and a SP. Each DFed consists of different components
such as Gate Keeper (GK), Directory Services, Trusted DFSP Repository, SAML Agent and ATN Agent. GK is
responsible for the SSO Protocol, Directory Service is responsible for storing attributes and policies, DFSP repository
stores the information of federated SPs, SAML Agent is responsible for carrying out the SAML Protocol and ATN
agent is responsible for ATN protocol and trust negotiation. All of them function together to realise the Dynamic
Federation protocol. It is also clear that DFed also requires that SAML are changed extensively to accommodate the
DFed protocols. There is another solution proposed in [34] where the authors propose calculating trust values based
on the modified Dijkstra algorithm and to calculate a distributed reputation based on the PageRank algorithm from
Google and use the trust and reputation value to create dynamic federations. And like before, this also requires a
major change of the SAML Protocol.
Our focus in this work is not to change anything in the core SAML Protocol and therefore our work has been based
on the Dynamic SAML. The existing SimpleSAMLphp implementation will be extended so that a federation can be
established and managed fully dynamically considering different trust issues.
In addition, any discussions on dynamic federations only seem to concentrate on how an entity can join in a
federation and discussions on other aspects (maintenance, provisioning and revocation) are rare. Hence, it is
essential to address all aspects covering the full life-cycle of a dynamic identity federation.
8
Md. Sadek Ferdous
Ron Poet
Managing Dynamic Identity Federations using Security Assertion Markup Language
(SAML)
Accepted for publication at the Journal of Theoretical and
Applied Electronic Commerce Research (JTAER)
4 Dynamic Federation
All previously mentioned works have used the term Dynamic Federation literally without defining them formally. The
lack of any formal definition for Dynamic Federation means that there are scopes for misunderstanding and multiple
interpretations. Before proceeding any further, it is, therefore, essential to define the term Dynamic Federation
formally which is presented next:
Definition 2. A Dynamic Federation with respect to the Identity Management is a business model in which a group of
two or more previously unknown parties federate together dynamically without any prior business and technical
contract with the aim to allow users to access services under certain conditions.
This definition is a stark contrast with the traditional definition of the identity federation based on SAML in which there
exists a legally binding technical and/or business contract between participating organisations before they can join
any federation. The primary advantage here is the ability to join the federation instantly in real time. However, the
lack of any legally binding contract means that organisations must consider that there might be negative
consequences possible since no party is bound to behave as it should and therefore take proper precautions. This
leads us to the topic of trust which will be explored in the following subsection.
The life-cycle of a dynamic federation maintains the same steps involved in the life-cycle of a traditional identity
federation: association, provisioning, maintenance and revocation, however, all such steps must be carried out in a
fully dynamic fashion without any administrator to intervene. Providing the capability to create federations
dynamically in real time will require to enable users to carry out some of these steps such as association,
provisioning and revocation dynamically. This contrasts with the traditional federations where all such steps must be
carried out by the administrators. However, the other task of Provisioning & Maintenance must be carried out by the
respective administrator to ensure that any malicious user cannot update the metadata of the entities in the
federation. Such mechanisms have not been considered in any previous work.
According to our proposed definition, participating organisations may not trust each other entirely since they are
previously unknown and there is no contract to make anyone accountable in case of disputes. The IdPs may not
want to release a few sensitive attributes to the SP that has been added dynamically and the SPs may not trust all
attributes released by the IdP that has been added dynamically. This takes us back to the open trust paradigm of the
OpenID where every organisation (IdP/SP) is assumed to be trusted even though it might behave maliciously.
Such trust issues have not been considered while drafting the Dynamic SAML which allows any SP and any IdP to
be federated with each other without any sort of verification. This is a serious flaw of the Dynamic SAML and a
mechanism must be introduced so that trust can be re-instated for dynamic federation. Remember that, technically
speaking, joining a federation in the Dynamic SAML will just require the parties to exchange and store the respective
metadata with each other. The SimpleSAMLphp implementation based on the Dynamic SAML only allows a SP to
join with an IdP since it requires the pre-configuration of the IdP in the SP TAL to allow any user to choose that IdP.
However, to harness the true potential of dynamic federation, it must be ensured that both parties can be added
dynamically. Moreover, the IdP in SimpleSAMLphp does not distinguish between statically and dynamically added
SPs. This allows the IdP to release the same level of (sensitive) attributes to both types of SPs. In summary, there
are two requirements to fulfil: i) Fully automate the life-cycle in a federation for both parties and ii) Consider trust
issues in a dynamic federation. With these two goals in mind the notion of fully trusted, semi-trusted and untrusted
entities based on how different entities federate with each other are introduced.
Definition 3. Fully Trusted Entities - Fully trusted entities are the IdP and SP in the traditional SAML federation in
which there is a legal contract between the IdP and the SP. They are so called since each IdP (or SP) inside a
federation trusts any SP (or IdP) in the same federation to behave as intended and can be held accountable in case
the other party behaves maliciously.
Definition 4. Semi-trusted Entities - Semi-trusted entities are the SPs in a dynamic federation that have been added
dynamically to an IdP inside the federation under some conditions without the presence of any contract between
them and to whom any user(or users) of the IdP has(have) agreed to release a subset of her(their) attributes. They
are so called since the user wants to release a subset of their attributes to these SPs inside the dynamic federation
even though the IdP in the same federation may not fully trust such SPs to behave as intended. Therefore, such SPs
might not be made accountable by the IdP in cases they behave maliciously with the absence of any contract
between them.
Definition 5. Untrusted Entities - Untrusted entities are the IdP and SP in a dynamic federation in which they have
been added dynamically under some conditions without the presence of any contract between them. They are so
called since each IdP (or SP) inside a dynamic federation may not trust at all any other dynamically added SP (or IdP)
in the same federation to behave as intended.
It is important to understand that a dynamic federation may accommodate as many fully trusted entities as possible.
As such, a dynamic federation is an extension of the traditional federation. Even though, different entities have been
categorised based only on how they federate, these three types of entities have their own effect on other parts of the
life-cycle of the federation which will be explored later on.
Now, the term “some conditions” in the definition of the semi-trusted and untrusted entities require further
explanations. It can be the combinations of several different conditions by which a federation between two entities
can be created, updated or removed dynamically, the conditions for establishing and removing individual trust with
9
Md. Sadek Ferdous
Ron Poet
Managing Dynamic Identity Federations using Security Assertion Markup Language
(SAML)
Accepted for publication at the Journal of Theoretical and
Applied Electronic Commerce Research (JTAER)
each other in such a federation, the condition by which attributes are released to a semi-trusted SP and the condition
by which a SP treats attributes of a user from an untrusted IdP. Semi-trusted and untrusted entities of different
dynamic federations should have different sets of conditions suitable for their business models and service
provisioning scenarios. Here, a set of conditions that have been assumed for developing our proof of concept of
managing a dynamic federation using SAML is presented next.
Only a valid user of an IdP is allowed to add a SP to that IdP dynamically. This is to ensure that only those SPs
that the users want to access for service provisioning are added in a dynamic federation. This is missing in the
current implementation of SimpleSAMLphp.
Once the SP is added to the IdP, the SP must add the IdP to its TAL to ensure that the user can select the IdP
next time. This nullifies the need to pre-configure the IdP in the SP.
Only a valid user of an IdP who has added a SP to that IdP dynamically is allowed to initiate the procedure to
revoke the SP from the federation with that IdP. In this case, the IdP will be removed from the TAL of the SP and
the SP will be removed from the TAL of the IdP. This is to ensure that another user does not accidentally
defederate entities which have been federated by other users and hence might still be used by them.
Only the administrator of each entity is allowed to dynamically update any information in the metadata stored in
the TAL of other entities. This is to ensure that users with malicious intent cannot update or corrupt such
information of the metadata.
Dynamically added SPs must be tagged as untrusted entities in the IdP at the initial stage. Only when a user,
after being authenticated at the IdP, has agreed to release a subset of her attributes to the SP, the SP should be
re-tagged as a semi-trusted entity.
A dynamically added IdP should always be tagged as an untrusted entity for the SP.
IdPs should ensure that they do not release any attributes to an untrusted entity.
IdPs should ensure that some crucial and sensitive attributes are not released to any semi-trusted entity since
there is no guarantee that such attributes will be handled as intended. Therefore, it should allow their
administrators to configure what attributes should not be released to a semi-trusted entity.
It is up to the discretion of each SP how they want to treat released attributes from an untrusted IdP. They could
use the NIST LoA (Level of Assurance or Level of Authentication) guidance of 1 to 4 where Level 1 conforms to
the lowest assurance and 4 conforms to the highest assurance [35]. Usually, the LoA level comes from the IdP
and is embedded inside a SAML assertion to provide the level of assurance for a certain authentication
mechanism at the IdP. However, the SP should consider implicitly that LoA 1 is the maximum that can ever
accompany the SAML authentication and attribute statements from any untrusted IdP. Since, how the released
attributes will be handled depends on the individual SP, it can vary from one SP to another even inside the same
federation.
To summarise, it is proposed that entities have to be federated/defederated in a fully automatic fashion without any
administrative intervention to harness the full potential of dynamic federation and while doing so all entities must
consider trust issues involved. Moreover, our proposal also outlines the conditions for managing such federations in
a fully automated manner. It should be noted that the conditions outlined before are one of the many ways to fulfil our
proposals, other implementations may require different sets of conditions suitable for their use-case scenarios.
5 Proof of Concept: Dynamic Management
In this section the proof of concept that has been developed to illustrate the applicability of our proposals for
managing the dynamic identity federations will be discussed. The SimpleSAMLphp has been used and modified to
meet our requirements. The IdP and one SP deployed with this modified version of the SimpleSAMLphp. The IdP is
configured to use a MySQL database at its end to store user attributes including username and password in a table
called users. In addition, the IdP uses two tables called semitrusted and untrusted to store the entity IDs of semi-
trusted and untrusted SPs respectively. Moreover, the IdP uses two additional tables called idpadmin and spadmin.
The idpadmin stores the SP entity ID and the IdP-generated admin code that can be used to update the metadata of
the IdP stored at the TAL of the SP and the spadmin stores the entity ID of the SP with the SP-generated admin
code to update the metadata of the SP stored at the TAL of the IdP. The purpose of the admin codes and how they
are generated are explained in the appropriate place. Similarly, the SP is also configured to use a MySQL database
at its end where it uses a table called untrusted to store the entity IDs of IdPs that have been federated dynamically.
Likewise, the SP uses two additional tables called idpadmin and spadmin. The idpadmin table at the SP stores the
entity ID of the IdP along with an IdP-generated admin code to update the metadata of the IdP stored at the TAL of
the SP and the spadmin table at the SP stores the entity ID of the IdP along with the SP-generated admin code to
update the metadata of the SP stored at the TAL of the IdP. Note that only admins of the IdP or the SP has access to
the spadmin and idpadmin tables since the general users are not allowed to make any changes to the metadata.
The following subsections will consider three different scenarios: i) dynamic federation, ii) dynamic defederation and
iii) dynamic update of identity federations.
10
Md. Sadek Ferdous
Ron Poet
Managing Dynamic Identity Federations using Security Assertion Markup Language
(SAML)
Accepted for publication at the Journal of Theoretical and
Applied Electronic Commerce Research (JTAER)
5.1 Use-case: Dynamic Federation
The architectural setup for this scenario is that there are one IdP and one SP. At the beginning, the IdP and SP are
not part of a common federation (they individually may be part of separate federations) and they have no prior
knowledge of the other party whatsoever. With this setup, the protocol flow, illustrated in Figure 2, for federating the
IdP and the SP dynamically while trying to access a service from the SP is given next.
1. A user visits the SP for the first time to access one of its services. Since there is no security context (e.g. no
cookie) of the user at the SP, the user needs to be authenticated at an IdP and therefore she is redirected to the
WAYF service to discover her IdP and a list with federated IdPs with the SP is shown.
Figure 2: Protocol Flow for dynamic federation
2. Since the IdP and SP are not part of a common federation, the IdP list at the SP does not contain the IdP.
However, since the SP (more precisely the SimpleSAMLphp that has been used to deploy the SP) supports our
proposal of dynamic federation, it contains two additional text fields (Figure 3) which allow the user to enter the
entity ID of her IdP and a code to ensure that only the valid users of the IdP have the ability of federating a SP
with the IdP.
11
Md. Sadek Ferdous
Ron Poet
Managing Dynamic Identity Federations using Security Assertion Markup Language
(SAML)
Accepted for publication at the Journal of Theoretical and
Applied Electronic Commerce Research (JTAER)
Figure 3: Additional Text Fields at the WAYF
3. Since the user does not have the code, she logs in to her IdP and generates a code using the Generate button at
the Generate IdP Code page. This page also checks the semitrusted table to see if there is any dynamically
added SP. Since there is none now, it says so (Figure 4). This page also shows the entity ID of the IdP which the
user needs to enter at the WAYF page (Figure 4). Once the Generate button is clicked, a 4 digit random number
is generated and displayed (Figure 5). This random number is also stored temporarily in a database table called
code along with the user identifier. The code is used during metadata exchange for verification (see the following
steps). Here, a 4-digit code has been used in our implementation, other implementations may opt for other type
of codes according to their own requirements.
Figure 4: Code generate page at the IdP
Figure 5: Generated Code at the IdP
4. After generating the code, the user notes the entity ID of the IdP and the generated code. Then she inserts the
entity ID and the code to the WAYF page of the SP (Figure 6) and clicks the Add button.
12
Md. Sadek Ferdous
Ron Poet
Managing Dynamic Identity Federations using Security Assertion Markup Language
(SAML)
Accepted for publication at the Journal of Theoretical and
Applied Electronic Commerce Research (JTAER)
Figure 6: Entering values at the WAYF
5. Once the Add button is clicked, it is verified that entity ID field or code is not null and that the inserted entity ID is
not already part of the federation (dynamically or statically). If any part of the verification process fails, an
appropriate error message is displayed and the user is redirected to the WAYF page where she can insert valid
values again.
6. Assuming there is no error during verification, the SP generates a unique 4 digit random code which is then
stored at the spadmin along with the entity ID of the IdP. Then a request to retrieve metadata from that entity ID
with some specific values is posted. The request contains the entity ID and the code that the user has entered
and three hidden fields called MetaAdd, ReturnTo & AdminCode. The values of the MetaAdd & ReturnTo fields
contain the entity ID of the SP and the URL of the services that the user has requested at the first place which
initiated the SAML flow whereas the AdminCode field contains the SP generated random admin code.
Remember that SimpleSAMLphp implementation of dynamic SAML requires that entity ID be the endpoints from
where the metadata can be fetched. This approach has been extended by adding a verification mechanism.
7. Once the Appropriate end point of the IdP receives this request, it checks if there is any field called MetaAdd. If
found, it knows that this is a special request for exchanging metadata with the requested SP. If not found, it
assumes that it is normal metadata fetch request and returns its metadata. Since the request contain a MetaAdd
field, it, then, checks for a code field and retrieves its value and verifies if the same value can be found at the
code table of its MySQL database. If found, it indicates that this request for exchanging metadata is valid. If not
found, an error message is returned to the SP.
8. Assuming that the code field contains a valid code, the IdP retrieves the value of the MetaAdd & AdminCode
fields which contain the entity ID of SP and the 4 digit SP-generated admin code. The IdP stores this admin code
at the spadmin table at the IdP along with the entity ID of the SP and sends an HTTP GET request to that
location. GET has been used since there is no other parameters to pass during the metadata fetch process from
the SP.
9. When the SP receives this request, it returns its metadata.
10. Once the metadata is retrieved, the IdP goes thorough the specified verification process for a dynamic SAML
(verifying the embedded certificate, verifying the signature on the metadata using that certificate, etc.). If the
verification is correct, the metadata is stored in its repository and the SP is added to its TAL list. In addition, the
user identifier for that code is retrieved from the code table and the entity ID of the SP is added into the untrusted
table of the database along with the code and the user identifier. Then the used code is removed from the code
table to ensure that it cannot be reused again. If the metadata verification is not correct, the respective entry from
the spadmin is removed and an error message is returned to the SP.
11. If everything goes right at the IdP, it generates a 4-digit random admin code which is then stored at the idpadmin
table of the IdP along with the entity ID of the SP. Then the metadata of the IdP along with the ReturnTo field and
its value, a code field containing the previously generated value and the AdminCode containing the recently IdP-
generated 4 digit admin code are returned to the requesting endpoint of the SP, where the metadata, ReturnTo,
code and AdminCode values are separated. Like before, the SP goes thorough the specified verification process
for a dynamic SAML. If verification is correct, the metadata is stored in its repository and the IdP is added to its
TAL list. In addition, the entity ID of the IdP along with the code is added into the untrusted table of its database
and thus the IdP is tagged as an untrusted IdP. Moreover, the entity ID of the IdP along with the value of the
AdminCode parameter are stored at the idpadmin table.
12. Then, the user is redirected to the URL retrieved from the ReturnTo field (the URL of the service requested
initially) which in turn takes the user back to the IdP selection page of the WAYF. However, as the IdP has
already been added, the list contains the list of the IdP and it is tagged as an untrusted IdP (Figure 7). Moreover,
it is shown to the user that the IdP has already been added as an untrusted IdP so that no other user tries to add
it once again which will result in an error.
13
Md. Sadek Ferdous
Ron Poet
Managing Dynamic Identity Federations using Security Assertion Markup Language
(SAML)
Accepted for publication at the Journal of Theoretical and
Applied Electronic Commerce Research (JTAER)
Figure 7: Added IdP at the WAYF
The usage of codes while creating dynamic federations requires further explanations. Allowing arbitrary users to
create federations, in general, does not impose any threats. However, if an arbitrary user can create federations
between an IdP and SP in which she does not have any account, she will not be able to use that IdP, or the
federation, for any use-case scenario. It means that the federations between that said IdP and SP will be of no use
and the storage of metadata in the respective TAL will be wasted for nothing. That is why this particular choice has
been opted. And also if a particular setup requires that such a federation can only be created by the admin, it can be
easily adopted using our preferred option where only the admin can generate the required code at the IdP and hence
only the admin is allowed to create such federations.
In the traditional SAML scenario, it is assumed that both IdP and SP are visible to each other as they are expected to
be online. This assumption does not hold for SAML IdPs which might be installed locally inside the user's computer
from where she is trying to access a service. One example of such an IdP is the Portable Personal Identity Provider
(PPIdP in short) as introduced in [36]. The PPIdP is a special type of SAML IdP, based on the SAML HTTP Post
binding, that is hosted in a mobile device owned and/or used by the user and allows the user to use the PPIdP while
accessing services using a browser in that mobile phone. Firstly, the user has to federate the PPIdP with the SP
using the steps described previously. However, the problem occurs during the metadata exchange period since the
SP at the SimpleSAMLphp is designed to communicate with the IdP directly. The implementation of the SP at the
SimpleSAMLphp has been modified so that the SP can communicate with the local IdP. This has been done by
embedding a JavaScript into an XHTML form which is submitted automatically at the entity ID of the IdP. Since the
JavaScript runs inside the browser and the local IdP (PPIdP) is visible to the browser, it can properly submit these
requests. The SP, on the other hand, is assumed to be online. Therefore it is visible to the IdP and no special
treatment is required.
5.2 Use-case: Dynamic Defederation
The setup for this scenario is that an IdP and a SP have been federated dynamically using the steps described
previously. Now, the user wants to defederate them dynamically. A user is only allowed to defederate those entities
that she federated previously. This is to ensure that another user does not accidentally defederate entities which
have been federated by other users and hence might still be used by them. Unlike the federation, the protocol for
defederating starts at the IdP.
With this setup, the protocol flow, illustrated in Figure 8,for defederating the IdP and the SP dynamically is given next.
1. The user logs in to the IdP and then clicks the Remove SP link at the IdP.
2. If the user has not federated the IdP and a SP dynamically, a message will be shown to the user. Assuming, the
user has already federated the IdP and the SP(s), a list of SPs are retrieved from the untrusted/semitrusted
tables using the user identifier to ensure that only the SP that has been federated dynamically by the user is
retrieved. The reason for checking both the tables will be explained in the Section 6. Then a list of check boxes
containing the entity ID of these dynamically added SPs is shown (Figure 9).
3. The user selects one of the SPs and clicks the Remove button.
4. The IdP uses the entity ID of the selected SP to retrieve the code from the untrusted/semitrusted table.
5. Once the code is retrieved, the corresponding entry is removed from the respective table. The IdP also removes
the corresponding SP entry from the idpadmin & spadmin tables.
6. Then, a request to remove the IdP entry from the TAL of the SP is sent to the entity ID of the SP. The request
contains three parameters: i) the remove parameter containing the entity ID of the IdP, ii) the code parameter
containing the code retrieved in Step 4 and iii) the ReturnTo parameter containing the link of the Remove page at
the IdP where the user will return later.
7. The SP validates if there exists the entity ID of an IdP along with the code containing the respective value in its
untrusted table. If such an entry is found, the entry is removed from the table, otherwise, an error message is
shown. Moreover, the SP also removes the respective entry from the idpadmin & spadmin tables.
14
Md. Sadek Ferdous
Ron Poet
Managing Dynamic Identity Federations using Security Assertion Markup Language
(SAML)
Accepted for publication at the Journal of Theoretical and
Applied Electronic Commerce Research (JTAER)
8. Then the user is redirected to the location retrieved from the ReturnTo parameter and the user is informed about
the successful defederation.
Figure 8: Protocol flow for dynamic defederation
Figure 9: Removing a SP at the IdP
As described in the previous use-case, the same approach has been adopted to defederate any locally installed IdP
using a JavaScript embedded into an XHTML form which is submitted automatically to the entity ID of the IdP and
like before the SP is assumed to be online.
Please note that general users might not be motivated to defederate entities since they do not gain anything doing
this. However, this use-case will be useful in the setup where the admin has federated the entities and there is no
need to maintain that federation.
5.3 Use-case: Dynamic Update
The setup for this scenario is that an IdP and a SP have been federated dynamically using the steps described in
Section 5.1. The idpadmin table at the IdP contains the entity ID of the SP along with the IdP-generated 4 digit
AdminCode and the idpadmin table at the SP contains the entity ID of the IdP with the same IdP-generated 4 digit
AdminCode. Now, the admin of the IdP has made some changes (let's assume the changed entries are the Binding
& Location entries of the SingleSignOnService entry of the IDPSSODescriptor field of the metadata) into the IdP's
metadata locally and the admin wants to propagate these changes into the metadata stored at the SP in a dynamic
fashion. It is assumed that the IdP has provided an interface to allow the admin to propagate these changes.
With this setup, the protocol flow, illustrated in Figure 10, for updating metadata dynamically is given next.
1. The admin of the IdP visits the admin interface of the IdP and logs in there.
2. The admin clicks the Update Metadata link at the interface and the update page is shown to the user (Figure 11).
15
Md. Sadek Ferdous
Ron Poet
Managing Dynamic Identity Federations using Security Assertion Markup Language
(SAML)
Accepted for publication at the Journal of Theoretical and
Applied Electronic Commerce Research (JTAER)
Figure 10: Protocol flow for dynamic update
Figure 11: Metadata update page
3. The update page contains a dropdown list containing the entity IDs of all (dynamically or statically) SPs federated
with the IdP (Figure 8).
4. The admin selects the entity ID of the SP to which she wants to propagate these changes.
5. The selected entity ID of the SP is used to retrieve the respective entries of the metadata and those entries are
displayed using check boxes to the admin. The admin selects the Binding & Location (SSO-Binding and SSO-
Location entries in Figure 8) entries and clicks the Submit button. The IdP restores the AdminCode from the
idpadmin table using the selected entity ID of the SP.
6. Then a request is sent to the entity ID of the SP. The request contains several parameters: the update parameter
containing the entity ID of the IdP, the AdminCode parameter containing the code, the name of the entries of the
metadata that need to be updated and their respective updated values and the ReturnTo parameter containing
the location of the Update page at the IdP where the admin will return. The following steps take place only if the
SP is online and is able to receive the request. In case the selected SP is offline, the request times out after a
period and an appropriate error message is displayed to the admin.
16
Md. Sadek Ferdous
Ron Poet
Managing Dynamic Identity Federations using Security Assertion Markup Language
(SAML)
Accepted for publication at the Journal of Theoretical and
Applied Electronic Commerce Research (JTAER)
7. Once the SP receives this request, all values of the parameters are retrieved. The update parameter informs the
SP that the IdP with the entity ID in that parameter wants to update its metadata. The AdminCode parameter is
used to authorise the request by matching them with the values stored at the idpadmin table at the SP.
8. If they match, the metadata is updated with the requested values and an appropriate message is returned to the
location retrieved from the ReturnTo parameter. If no match is found, an error message is returned to that IdP
location.
This similar approach can be used to update the metadata of the SP stored at the TAL of the IdP. As described in
the previous use-case, the same approach has been adopted to update metadata of any locally installed IdP using a
JavaScript embedded into an XHTML form which is submitted automatically to the entity ID of the IdP and like before
the SP is assumed to be online.
6 Proof of Concept: Service Provisioning
In this section the proof of concept that has been developed to illustrate how users can access services using the
federations created in dynamic fashion will be discussed. The following subsections will consider two different
scenarios: i) IdP-SP Scenario to illustrate our concept for Type 1 Federation and IdP-IdP-SP Scenario to illustrate
the concept for Type 2 Federation.
For the first use-case, it is assumed that the IdP and the SP have already been federated dynamically where the IdP
is tagged as an untrusted entity at the SP and the SP is tagged as an untrusted entity at the IdP. Before discussing
the protocol flow, the effect of trust issues discussed previously needs to be analysed.
A mechanism has been provided to ensure that an admin of the IdP can configure which attributes to release to a
semi-trusted SP. A configuration parameter called semitrusted.sp has been used which can be added to the
configuration file (called config.php) in the SimpleSAMLphp. A sample configuration parameter could be
‘semitrusted.sp’ => array (‘username’, ‘name’, ‘telephone’, ‘age’, ‘position’, ‘org’) which will configure the IdP to
release only these attributes by excluding all other attributes such as salarygrade & email attributes, which the IdP
normally releases to all trusted SPs but assumes to be too crucial and sensitive, to release to a semi-trusted SP. The
admin can add as many or as less attributes as needed as per the requirements. This configuration parameter works
like an attribute release policy. SimpleSAMLphp does not have the concept of an Attribute Release Policy, however,
it has something similar called an Authentication Processing Filter (AuthProc) SSPHPAuthProc [37]. An AuthProc
allows the system to do additional activities once the user authentication is done. For example, among other things, it
can be used for filtering out attributes once the authentication is done. There are several authentication processing
filters bundled with the SimpleSAMLphp implementation. One of them is the Consent module that is used to display
the list of attributes to the user just before they are released. This module has been modified to allow the IdP to show
only those attributes that can be found in the semitrusted.sp parameter. From the displayed list, the user can choose
which attributes she wants to release to the SP. Note that the illustrated use-cases are applicable for any locally
installed IdPs as well as for any traditional IdPs using the mechanisms discussed previously.
6.1 Use-case: IdP-SP Scenario
With this setup, the protocol flow, illustrated in Figure 12, for the scenario is given next.
1. A user visits the SP for the first time to access one of its services. Since there is no security context (e.g. no
cookie) of the user at the SP, the user needs to be authenticated at an IdP and therefore she is redirected to the
WAYF service and a list of federated IdPs with the SP is shown. The list also contains the untrusted IdP that has
been federated in the previous use-case.
2. Now, if the user selects the IdP, the usual SAML flow will take place. A SAML authentication request will be sent
to the selected IdP and if the user is not already authenticated at the IdP, she will be prompted for login.
3. Once the user is logged in, the Consent module is called internally. It reads the semitrusted.sp configuration
parameter and displays the attributes automatically. Figure 13 shows the consent form. The consent page also
states which attributes are filtered out from the full set and why. At this point, the user can choose which
attributes she wants to release to the SP.
4. If the user has chosen to release any attribute(s) by clicking the ‘Yes, continue’ button, the entity ID of the SP is
removed from the untrusted table and inserted into the semitrusted indicating that the SP will be tagged as a
semi-trusted entity hereafter and the chosen attributes would be released to the SP. If the user chooses not to
release any attribute, the entity ID of the SP will remain in the untrusted table.
At this point, the SP knows from the untrusted table of its database that these attributes have been released by an
untrusted IdP. Therefore, the respective SP will treat these attributes coming from an IdP having LoA of maximum 1
and authorise the user accordingly.
17
Md. Sadek Ferdous
Ron Poet
Managing Dynamic Identity Federations using Security Assertion Markup Language
(SAML)
Accepted for publication at the Journal of Theoretical and
Applied Electronic Commerce Research (JTAER)
Figure 12: Protocol for IdP-SP service provisioning
Figure 13: Attributes to be released at the Consent page
18
Md. Sadek Ferdous
Ron Poet
Managing Dynamic Identity Federations using Security Assertion Markup Language
(SAML)
Accepted for publication at the Journal of Theoretical and
Applied Electronic Commerce Research (JTAER)
6.2 Use-case: IdP-IdP-SP Scenario
The described protocol flows will allow the users to access services using a dynamically federated (untrusted) IdP.
However, the main problem is that the SP may not trust all attributes coming from the untrusted IdP even though the
IdP is honest. The problem can be resolved if it is possible to link the untrusted IdP with an IdP which is fully trusted
by the SP. In such a case, the fully trusted IdP would act like a Proxy IdP as described in [38]. The SP would think
that it is interacting with the fully trusted IdP while in fact the proxy IdP would delegate the authentication service to
the untrusted IdP which is hidden from the SP. The untrusted IdP would release the user attributes to the fully trusted
IdP once the user is authenticated which will be then retrieved and returned to the SP in such a way that the SP will
think that the attributes have been released by the fully trusted IdP. Another advantage is that the SP no longer
needs to support dynamic federations, since the proxy IdP can, in a trustworthy manner, add new IdPs indirectly.
As before, SimpleSAMLphp has been used to demonstrate this scenario. The SimpleSAMLphp allows multiple
authentication sources (including another SAML IdP) for authenticating a user. This can be enabled by the MultiAuth
module of SimpleSAMLphp. This feature has been used to add the untrusted IdP as one of the authentication
sources for the fully trusted IdP. To the untrusted IdP, the fully trusted IdP would be treated as a normal SAML SP,
however, the fully trusted IdP would treat the untrusted IdP as the SAML IdP. To enable this configuration, it needs
the authentication source to be pre-configured by exchanging metadata just like a federation. Like the previous
scenario, the SimpleSAMLphp has been modified to automate this procedure so that two prior unknown SAML IdPs
can be linked (in other words federated) in a fully dynamic fashion. However, this approach introduces an
inconsistency which a malicious user might abuse for escalation of privileges. Since the SP would think that the
attributes from the linked IdP have come from a trusted source (the proxy IdP), they might be tricked in trusting them.
To ensure that it does not happen, the trusted IdP must add a LoA value of maximum 1 into the assertion in cases it
has received any attributes from a dynamically linked IdP and return the assertion with that lower LoA. This would
help the SP to decide how much trust they can put in those attributes.
With this setup, the protocol flow, illustrated in Figure 14, for the scenario is given next.
1. The user logs in to the untrusted IdP and generates a code just like the previous one. This code will be used to
link the proxy IdP with this IdP. The page also shows the entity ID of the untrusted IdP.
2. Now, the user needs to log in to the proxy IdP. Since the IdP has enabled the MultiAuth module, the IdP shows
all authentication sources (Figure 15). As there is no other authentication sources, it only shows the example-
userpass source (an authentication source based on locally stored username/password in a database) which
allows the user to log in to the IdP by using Username/password. The user selects this source and logs in using
her username and password. After login, the user clicks the Link Another IdP' option.
3. The user is presented with a page which has three fields: IdP ID field for entering the entity ID of the untrusted
IdP, Code field to enter the generated code from step 1 and a Name field to enter a Nick Name for the untrusted
IdP. This Nick Name will help the user to remember the IdP once it is added as one of the authentication sources.
This field is not needed at the SP because each IdP is listed using its entity ID, whereas at the proxy IdP the IdPs
are listed as authentication sources using a user-friendly name. After entering all this information, the user clicks
the Submit button.
4. Once the Submit button is clicked, it is checked to make sure that all information has been entered in the three
fields. If not, an appropriate error message is displayed. If yes, a request to retrieve metadata from that entity ID
is submitted with some specific values just like the way discussed in the previous scenario.
5. At this point, code is verified, metadata between two IdPs are exchanged, verified and stored just like the
previous scenario. At this point, the two IdPs are linked.
6. Now, the user visits the SP to access one of the services. Assuming there is no security context, the user is
redirected to the WAYF Service where the list of federated IdPs is shown. The user selects the fully trusted IdP
(proxy IdP) and a SAML Authentication request is submitted to that IdP.
7. The IdP displays the list of authentication sources. As the untrusted IdP is already linked, the user can see the
nick name (My IdP) of the untrusted IdP which was given during the linking phase (Figure 16).
8. Once the user selects the untrusted IdP, she is redirected to the IdP where the user logs in and the consent page
with attributes are shown. As the proxy IdP is not tagged as the semi-trusted SP, all attributes that the user
chooses will be released to the Proxy IdP.
9. Once the user clicks the ‘Yes, continue’ button, a SAML assertion with chosen attributes is sent back to the proxy
IdP where all attributes are retrieved. The proxy IdP builds a SAML assertion with these attributes with a LoA
value of 1 and it is sent back to the SP.
What the SP will do with all these attributes is not further explored here.
One might question the incentive for the fully trusted IdP to act as a proxy IdP for the untrusted IdP. The incentive
here for the trusted IdP is that this service will allow it to attract more users since the user will be able to choose
attributes from different linked IdPs via a single interface provided by the trusted IdP. With a little effort this single
interface can be used to aggregate attributes from multiple IdPs in a single SP session which is not possible in the
current settings of FIM.
19
Md. Sadek Ferdous
Ron Poet
Managing Dynamic Identity Federations using Security Assertion Markup Language
(SAML)
Accepted for publication at the Journal of Theoretical and
Applied Electronic Commerce Research (JTAER)
Figure 14: Protocol for IdP-IdP-SP service provisioning
Figure 15: Initially, only one authentication
source (Username/password) at the IdP
Figure 16: Linked untrusted IdP as the
authentication source in the proxy IdP
20
Md. Sadek Ferdous
Ron Poet
Managing Dynamic Identity Federations using Security Assertion Markup Language
(SAML)
Accepted for publication at the Journal of Theoretical and
Applied Electronic Commerce Research (JTAER)
7 Discussion & Future Work
Our approach offers several key advantages:
Users can create federations just in time and whenever required. Even though it has not been considered in our
implementation, any IdP or SP can decide on how long it would allow the other party that has been added
dynamically to remain in the federation by using a time threshold. Once the threshold is reached, the respective
entry can be removed automatically from the TAL list, thus defederating the entity.
By using separate trust domains inside the same federation for fully trusted, semi-trusted and untrusted entities, a
federation can host all types and leverage the advantages of all in the same configuration. However, one must
keep in mind that the types of treatments semi-trusted entities will receive will fully depend on a particular
implementation since the behaviour is not standardised.
One of the requirements for an ideal Identity Management System is the Segregation of power which is required
to ensure that no single entity will have dominant position over other entities and users have the ability to choose
a specific entity for a specific scenario [39], [9]. Since the traditional SAML enforces users to use only those IdPs
that can be in the TAL, segregation of power is not fully exercised [9]. Allowing to create federations dynamically
would allow the users to choose a specific IdP for a specific scenario and thus segregation of power can be
ensured.
Our proposal illustrates how the life-cycle of any identity federation can be managed dynamically in a fully
automatic fashion. This approach can be extremely useful to automate the task of federation management which
now has to be done manually.
Allowing users to link two of their IdPs would enable them to use their own IdPs (e.g. a locally installed IdP) via a
trusted IdP. This would help to aggregate attributes from different sources. For example, the local IdP may
provide some dynamically created attributes (e.g. location data etc.) which would be difficult to provide for the
fully trusted IdP. However, this should be treated with cautions as it might escalate privileges as discussed
previously. In such cases, the LoA value should used as suggested previously.
Currently, the implementation only deals with one level of trust for linking IdPs: IdP-IdP. It will be interesting to see if
it can be extended for multi-levels so that the trust hierarchy looks something like this: IdP-IdP-IdP-...-IdP. Technical
challenges for exchanging metadata might be not very difficult, however, establishing the transitive trust between all
these IdPs could be challenging. Also the current model is currently based only on the SimpleSAMLphp
implementation of the SAML. It is necessary to investigate how our proposals can be implemented in other SAML
implementations as well to ensure its widespread adoption. The best way to achieve this is by converting our
proposals into specifications and then integrating them with the official specifications to ensure consistent
implementations. Also it will be beneficial for the users if they can utilise the IdP-IdP-SP setting to aggregate
attributes from multiple IdPs in a single SP session. It is needed to explore how it can be achieved using this setting.
The developed mechanism and the proof of concept are not currently available online and there are plans to make
them available online soon.
8 Conclusion
In this paper, the avenue of the dynamic federation has been explored: how the life-cycle of such a federation can be
fully managed in an automatic fashion and how such federations can be used to provide services to the user.
Managing an identity federation, especially when it is very large, can be a laborious job if it is done manually. Our
proposed approach can be beneficial in such aspects as our proposal can be used for creating, removing and
updating federations dynamically and in a fully automatic fashion. Also, our approach offers a better solution and can
be easily adopted to any SAML implementation and requires no modification of the SAML Protocol.
The trust issues involved in such scenarios have been examined and several use-cases with detailed protocol flow
have been illustrated. Using our use-cases as the foundation, different other use-cases can be created which can be
applied for enterprise scenarios as well as for general online service provisioning scenarios. However, it should be
noted that the issues of trust are very complex. The way the trust issues have been outlined may not be suitable for
all scenarios. For example, an IdP may be reluctant to trust any SP which is not pre-configured in the traditional way
and thereby hesitant to release any attributes to it. In such cases, it will be difficult to create federations in a dynamic
way. It is our understanding that IdPs and SPs will need to relax the trust requirements if they want to allow their
users to take advantage of dynamic federations. However, how much relaxation it will require will depend entirely on
a specific use-case.
References
[1] 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.
[2] 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.
21
Md. Sadek Ferdous
Ron Poet
Managing Dynamic Identity Federations using Security Assertion Markup Language
(SAML)
Accepted for publication at the Journal of Theoretical and
Applied Electronic Commerce Research (JTAER)
[3] 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.
[4] OpenID Authentication 2.0 - Final. 5 December, 2007. http://openid.net/specs/openid-authentication-2_0.html.
[5] OASIS Standard. Web Services Federation Language (WSFederation) Version 1.2. 22 May, 2009. http://-
docs.oasis-open.org/wsfed/federation/v1.2/os/ws-federation-1.2-spec-os.pdf.
[6] OpenID Attribute Exchange 1.0 - Final. 5 December, 2007. http://openid.net/specs/openid-attribute-exchange-
1_0.html.
[7] Patricia Arias Cabarcos, Florina Almenárez Mendoza, Andrés Marín-López and Daniel Díaz-Sánchez. Enabling
SAML for Dynamic Identity Federation Management. In Jozef Wozniak, Jerzy Konorski, Ryszard Katulski, and
Andrzej Pach, editors, Wireless and Mobile Networking, volume 308 of IFIP Advances in Information and
Communication Technology, page 173-184. Springer Boston, 2009.
[8] OpenID Provider Authentication Policy Extension 1.0. 30 December, 2008. http://openid.net/specs/openid-
provider-authentication-policy-\extension-1_0.html.
[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] Microsoft Windows CardSpace. http://www.microsoft.com/windows/products/winfamily/cardspace/default.mspx.
[11] Md.Sadek Ferdous and Ron Poet. Dynamic Identity Federation Using Security Assertion Markup Language
(SAML). In Simone Fischer-Hübner, Elisabeth Leeuw, and Chris Mitchell, editors, Policies and Research in
Identity Management, volume 396 of IFIP Advances in Information and Communication Technology, page 131-
146. Springer Berlin Heidelberg, 2013.
[12] Md. Sadek Ferdous. Identity Management with Petname Systems. Master’s thesis, 2009.
[13] Audun Jøsang, Muhammed Al Zomai and Suriadi Suriadi. Usability and privacy in identity management
architectures. In ACSW ’07: Proceedings of the fifth Australasian symposium on ACSW frontiers’, page 143-
152, 2007.
[14] 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.
[15] Andreas Pfitzmann and Marit Hansen. A terminology for talking about privacy by data minimization:Anonymity,
Unlinkability, Undetectability, Unobservability, Pseudonymity, and Identity Management. V0.34, August 10 2010.
http://dud.inf.tu-dresden.de/literatur/Anon_Terminology_v0.34.pdf.
[16] Jamie Lewis. Enterprise Identity Management: It’s About the Business. The Burton Group Directory and
Security Strategies Report, v1, July 2nd 2003.
[17] ISO/IEC International Standard 24760-1. Information technology - Security techniques - A framework for
identity management, 15 December 2011. http://standards.iso.org/ittf/PubliclyAvailableStandards/-
c057914_ISO_IEC_24760-1_2011.zip.
[18] ITU-T. Baseline capabilities for enhanced global identity management and interoperability, September 2009.
http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=X.1250.
[19] Shibboleth. http://shibboleth.internet2.edu/.
[20] 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.
[21] Liberty Alliance Whitepaper: Benefits of Federated Identity to Government, March 2004. http://-
projectliberty.org/liberty/content/download/388/2723/file/Liberty_Government_Business_Benefits.pdf.
[22] Wikipedia entry on SAML. Accessed on 12 September, 2011. http://en.wikipedia.org/wiki/-
Security_Assertion_Markup_Language.
[23] OASIS Standard. Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0. 15 March, 2005.
http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf.
[24] Audun Jøsang and Elizabeth Gray and Michael Kinateder. Simplification and Analysis of Transitive Trust
Networks. Web Intelli. and Agent Sys. , 4(2):139-161, April 2006.
[25] D Harrison McKnight and Norman L Chervany. The meanings of trust. 1996.
[26] S. Marsh. Formalising Trust as a Computational Concept. Ph.D. Thesis, University of Stirling, 1994.
[27] Mortaza S. Bargh, Bob Hulsebosch, and Hans Zandbelt. Scalability of trust and metadata exchange across
federations, December 2010. https://tnc2011.terena.org/getfile/693.
[28] P. Harding, L. Johansson, and N. Klingenstein. Dynamic Security Assertion Markup Language: Simplifying
Single Sign-On. Security Privacy, IEEE, 6(2):83-85, March-April 2008.
[29] OASIS Standard. A profile for distributed SAML metadata management. 22 October, 2007. https://-
spaces.internet2.edu/display/dsaml/A+profile+for+distributed+SAML+metadata+management.
[30] OASIS Standard. SAML V2.0 Metadata Interoperability Profile, Working Draft 01. 1 August, 2008. https://-
spaces.internet2.edu/download/attachments/11275/draft-sstc-metadata-iop-
01.pdf?version=2&modificationDate=1217876016355.
[31] Andreas Solberg. Dynamic SAML. 18 February, 2010. https://rnd.feide.no/2010/02/18/dynamic_saml/.
[32] SimpleSAMLphp. http://simplesamlphp.org/.
[33] Yicun Zuo, Xiling Luo and Feng Zeng. Towards a Dynamic Federation Framework Based on SAML and
Automated Trust Negotiation. In Fu Wang, Zhiguo Gong, Xiangfeng Luo, and Jingsheng Lei, editors, Web
Information Systems and Mining, volume 6318 of Lecture Notes in Computer Science, page 254-262. Springer
Berlin / Heidelberg, 2010. 10.1007/978-3-642-16515-3_32.
22
Md. Sadek Ferdous
Ron Poet
Managing Dynamic Identity Federations using Security Assertion Markup Language
(SAML)
Accepted for publication at the Journal of Theoretical and
Applied Electronic Commerce Research (JTAER)
[34] Y. Xiang and J. Kennedy and M. Egger amd H. Richter. Network and Trust Model for Dynamic Federation. In
Proceedings of the Fourth International Conference on Advanced Engineering Computing and Applications in
Sciences, page 1-6, 2010.
[35] NISTWP. Electronic Authentication Guideline: INFORMATION SECURITY, April 2006. http://csrc.nist.gov/-
publications/nistpubs/800-63/SP800-63V1_0_2.pdf.
[36] Md. Sadek Ferdous and Ron Poet. Portable Personal Identity Provider in Mobile Phones. In to appear in the
Proceedings of the 12th IEEE International Conference on Trust, Security and Privacy in Computing and
Communications (IEEE TrustCom-13), pages 736745, 2013.
[37] Authentication Processing Filters in SimpleSAMLphp. http://simplesamlphp.org/docs/stable/simplesamlphp-
authproc.
[38] David W. Chadwick, George L. Inman, Kristy W.S. Siu, and Mohammad Sadek Ferdous. Leveraging social
networks to gain access to organisational resources. In Proceedings of the 7th ACM workshop on Digital
identity management, DIM ’11, page 43-52, New York, NY, USA, 2011. ACM.
[39] WP3, Future of Identity in the Information Society. Study on Mobile Identity Management, May 2005. http://-
www.fidis.net/fileadmin/fidis/deliverables/fidis-wp3-del3.3.study_on_mobile_identity_management.pdf.
... O conceito de federação dinâmica está relacionado com uma associação dinâmica entre Provedores de Identidade (IdP) e Provedores de Serviço (SP), no momento do acesso, sem se conhecerem e sem a necessidade de aceitação de contratos ou existênciad de contratos anteriores [S. Ferdous and R. Poet, 2015] [R. Sanchez, et. ...
... A falta de confiança entre as entidades envolvidas é um problema, porque uma entidade se torna um membro da federação de forma dinâmica, sem um acordo de contrato anterior [S. Ferdous and R. Poet, 2015] [R. Sanchez, et al., 2012]. ...
... Os trabalhos [S. Ferdous and R. Poet, 2015], [R. Sanchez, et al., 2012] e [P. ...
Book
Full-text available
Os principais problemas associados à implementação e uso da gerência de redes e serviços ocorrem devido à grande quantidade de proposições, padrões e de diferentes produtos oferecidos no mercado, dificultando consideravelmente a tomada de decisão no que se refere a utilização da abordagem de gerência de redes e serviços mais adequada. Além disso, novas tendências na área de gerência de redes e serviços vêm sendo pesquisadas, entre estas destacam-se atualmente: gerência de redes sem fio, de sensores, óticas, futura internet, internet das coisas, internet espacial...; áreas funcionais de segurança, configuração, desempenho, contabilidade...; gerência de serviços de multimídia, data centers, grid, cloud, fog, edge virtualização...; e gerência centralizada, autonômica, distribuída, auto-gerência, baseada em políticas... Estas novas tendências vêm sendo pesquisadas no Laboratório de Redes e Gerência (LRG) da UFSC e a partir deste projeto as mesmas poderão ser aperfeiçoadas através das seguintes atividades deste projeto: A - Aperfeiçoamentos na Gerência Autonômica para Fog e IoT; B - Aperfeiçoamentos na Qualidade de Serviço para Aplicações de Tempo Real em IoT e Fog; C Aperfeiçoamentos na Segurança para Fog e IoT; D - Aperfeiçoamentos no Sistema de Resposta de Intrusão Autonômica em Cloud e IoT; E - Aperfeiçoamentos na Privacidade em Gerência de Identidade para Federações Dinâmicas em Cloud e IoT; e F - Aperfeiçoamentos no Controle de Acesso Dinâmico Baseado em Risco para uma Federação de Nuvem e IoT..
... To enable federations using SAML, trust among participating organizations must be established by exchanging the corresponding metadata. This process is static in the sense that such metadata are exchanged in an out-of-bound fashion by the administrators of the respective organizations [8]. Also, this must be done before the entities of these organizations can interact with each other to access any federated services. ...
... Also, this must be done before the entities of these organizations can interact with each other to access any federated services. Binding trust in this static fashion introduces scalability issues when the number of entities within a federation is large [8]. To mitigate this issue, the notion of dynamic identity federations has been introduced [9]. ...
... To mitigate this issue, the notion of dynamic identity federations has been introduced [9]. There have been several works that have explored how dynamic federations could be managed [3], [8]- [12]. However, there are two major disadvantages: i) most of these works require to make significant changes in the core SAML standard and ii) the proposals presented in those works mostly overlooked several security considerations. ...
Conference Paper
Full-text available
Federated Identity Management (FIM) is a model of identity management in which different trusted organizations can provide secure online services to their uses. Security Assertion Markup Language (SAML) is one of the widely-used technologies for FIM. However, a SAML-based FIM has two significant issues: the metadata (a crucial component in SAML) has security issues, and federation management is hard to scale. The concept of dynamic identity federation has been introduced, enabling previously unknown entities to join in a new federation facilitating inter-organization service provisioning to address federation management’s scalability issue. However, the existing dynamic federation approaches have security issues concerning confidentiality, integrity, authenticity, and transparency. In this paper, we present the idea of facilitating dynamic identity federations utilizing blockchain technology to improve the existing approaches’ security issues. We demonstrate its architecture based on a rigorous threat model and requirement analysis. We also discuss its implementation details, current protocol flows and analyze its performance to underline its applicability.
... Caused by real-world problems, new protocols and extensions are evolving. Different research approaches [4,19,54,39,16,33] try to tackle specific issues. Similarly to centralized identity management, DNS is utilized for technical trust establishment [66,29]. ...
Article
Identity and access management (I&AM) plays a crucial role in today’s IT infrastructure. In order to access a service, the user needs to authenticate. I&AM maintains attributes, credentials, roles, and permissions for an identifier, which is, e.g., linked to a human person. The variety of approaches to solve I&AM makes it hard to compare or even combine them. As various protocols are developed to solve real-world problems, it is increasingly difficult to provide secure implementations and configurations. In order to gain an overview and to enable interoperability, this article proposes an identity and access management framework (IAMF). Based on a motivating scenario, different requirements are mapped with identity management models and approaches within. These findings build the foundation for IAMF, consisting of a technical architecture and interfaces for processes. The fundamental difference to existing systems is its integrating, interoperable, and modular approach.
... Developing collaboration between services with different administrative domains has introduced a new method of AAI called Federated Identity Management (FIM). In FIM a Circle of Trust (CoT) is created between two or more domains who have formed an agreement on exchanging and managing of users' credentials [3] [4]. ...
Conference Paper
Generally, methods of authentication and identification utilized in asserting users’ credentials directly affect security of offered services. In a federated environment, service owners must trust external credentials and make access control decisions based on Assurance Information received from remote Identity Providers (IdPs). Communities (e.g. NIST, IETF and etc.) have tried to provide a coherent and justifiable architecture in order to evaluate Assurance Information and define Assurance Levels (AL). Expensive deployment, limited service owners’ authority to define their own requirements and lack of compatibility between heterogeneous existing standards can be considered as some of the unsolved concerns that hinder developers to openly accept published works. By assessing the advantages and disadvantages of well-known models, a comprehensive, flexible and compatible solution is proposed to value and deploy assurance levels through a central entity called Proxy.
... This routine is known as Single Sign-On or SSO. To meet this goal one of the token-based frameworks which help us known as Security Assertion Markup Language (SAML) [16]. SAML is an XML based standard that uses for the exchange of user authentication and authorization across VM domains in a secure manner. ...
Article
Full-text available
In these days all businesses trying to use global applications on cloud computing infrastructure to reduce their costs and also decentralize their application. This movement also causes more security risks over the unbounded cloud environment. Therefore, accessing enterprise information for an unwanted user will be more than other environments. Thus, the proposed Identity Management System (IDMS) tries to preserve security in communication between clients and server over cloud computing. The proposed method suggested token based Identity Management and also enhanced privacy by adding one. Dual Certificate Manager (DCM) block is a replacement for a combination of symmetric and asymmetric cryptography, which is commonly used for SSL/TLS protocol to immune data transmission, uses asymmetric cryptography in both participants. Furthermore, for more privacy and invulnerability DCM uses Elliptic Curve Cryptography (ECC) as asymmetric cryptography algorithm.
Article
Full-text available
An efficient identity management system has become one of the fundamental requirements for ensuring safe, secure, and transparent use of identifiable information and attributes. Federated Identity Management (FIdM) allows users to distribute their identity information across security domains which increases the portability of their digital identities, and it is considered a promising approach to facilitate secure resource sharing among collaborating participants in heterogeneous IT environments. However, it also raises new architectural challenges and significant security and privacy issues that need to be mitigated. In this paper, we provide a comparison between FIdM architectures, presented the limitations and risks in FIdM system, and discuss the results and proposed solutions.
Conference Paper
Efficient identity management system has become one of the fundamental requirements for ensuring safe, secure, and transparent use of identifiable information and attributes. FIdM allows users to distribute their identity information across security domains which increase the portability of their digital identities. However, it also raises new architectural challenges and significant security and privacy issues that need to be mitigated. In this paper, we presented the limitations and risks in Federated Identity Management system and discuss the results and proposed solutions.
Preprint
Full-text available
Efficient identity management system has become one of the fundamental requirements for ensuring safe, secure, and transparent use of identifiable information and attributes. FIdM allows users to distribute their identity information across security domains which increase the portability of their digital identities. However, it also raises new architectural challenges and significant security and privacy issues that need to be mitigated. In this paper, we presented the limitations and risks in Federated Identity Management system and discuss the results and proposed solutions.
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.
Article
Cloud computing is a computing paradigm that provides a set of scalable resources on demand. Mobile clients/users and Internet of Things (IoT) are using cloud resources for their applications. However, it also is a target of cyber-attacks and creates risks for data privacy and protection. Identity management (IdM) has emerged as an important issue for reducing complexity and improving the user experience when accessing services. In addition, nowadays networks and/or security administrators added SAML to authentication services. These service options are available for different uses including a cloud subscriber. In this work, the SAML representation of existing identity management frameworks and its suitability are emphasized. We introduced a new representation of SAML that makes it lightweight, easier to use and easier to parse. This representation is demonstrated using JSON. In this new SAML representation, we enhanced the performance by marshaling the SAML by 28.99%. In this paper, we will go into these challenges to introduce a new representation for the identity and access management by using a markup language. Our results show that the proposed representation is suitable for small processing power devices for faster generation, parsing, and communication.
Conference Paper
Full-text available
This paper analyses the prospect of having a Portable Personal Identity Provider (PPIdP, in short) in the mobile phone. The ubiquitous presence of powerful mobile phones equipped with high speed networks can be utilised to make the mobile phone act as a portable and personal Identity Provider (IdP, in short) on behalf of their users. Such an IdP would be helpful for the user in the sense that it will provide a central location to manage different user attributes which are generally scattered among different service providers in the traditional setting of online services. In addition, the user needs to trust the provider to store those attributes securely which may not be always honoured and crucial user attributes may be abused. Creating a Personal Identity Federation using a personal IdP can tackle many of these stated problems. Moreover, such an IdP may provide additional advantages. We have developed such a Mobile IdP for the Android platform based on the Security Assertion Markup Language (SAML) and OpenID as a proof of concept using the Jetty Web Server. In this paper, we discuss the functionalities of our developed IdP and the technical challenges we have faced. Moreover, we analyse the security, privacy and trust issues involved in having such an IdP and the advantages it offers.
Technical Report
Full-text available
What does the word ‘trust’ mean? Scholars continue to express concern regarding their collective lack of consensus about trust’s meaning. Conceptual confusion on trust makes comparing one trust study to another problematic. To facilitate cumulative trust research, the authors propose two kinds of trust typologies: (a) a classification system for types of trust, and (b) definitions of six related trust types that form a model. Some of the model’s implications for management are also outlined.
Conference Paper
Full-text available
Security Assertion Markup Language (SAML, in short) is one of the most widely used technologies to enable Identity Federation among organisations from different trust domains. Despite its several advantages, one of the key disadvantages of SAML is the mechanism by which an identity federation is established. This mechanism lacks flexibility to create a federation in a dynamic fashion to enable service provisioning (or de-provisioning) in real time. Several different mechanisms to rectify this problem have been proposed. However, most of them require a more elaborate change at the core of the SAML. In this pa-per we present a simple approach based on an already drafted SAML Profile which requires no change of the SAML, rather it depends on the implementation of SAML. It will allow users to create federations using SAML between two prior unknown organisations in a dynamic fashion. Implicit in each identity federation is the issue of trust. Therefore, we also analyse in detail the trust issues of dynamic federations. Finally, we discuss our implemented proof of concept to elaborate the practicality of our approach.
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.
Conference Paper
Full-text available
We describe a federated identity management service that allows users to access organisational resources using their existing login accounts at social networking and other sites, without compromising the security of the organisation’s resources. We utilise and extend the Level of Assurance (LoA) concept to ensure the organisation’s site remains secure. Users are empowered to link together their various accounts, including their organizational one with an external one, so that the strongest registration procedure of one linked account can be leveraged by the other sites’ login processes that have less stringent registration procedures. Coupled with attribute release from their organizational account, this allows users to escalate their privileges due to either an increased LoA, or additional attributes, or both. The conceptual and architectural designs are described, followed by the implementation details, the user trials we carried out, and a discussion of the current limitations of the system.
Article
Full-text available
Based on the nomenclature of the early papers in the fieldprivacy by data minimization, we develop a terminology which is bothexpressive and precise. More particularly, we define anonymity, unlinkability, linkability,undetectability, unobservability, pseudonymity (pseudonyms and digitalpseudonyms, and their attributes), identifiability, identity, partialidentity, digital identity and identity management. In addition, we describe the relationships between these terms, give arationale why we define them as we do, and sketch the main mechanisms toprovide for the properties defined.
Article
Most existing approaches to identity federation are based on static relationships. This leads to problems with scalability and deployment in real-time environment such as mobile networks. This paper introduces an underlying network and trust model for dynamic federation. We present a modified Dijkstra algorithm to calculate the trust value and apply a distributed reputation calculated based on the PageRank algorithm from Google to each entity in order to increase the attack resistance of the system.