ANALYSIS OF SECURITY PROTOCOLS FOR WIRELESS NETWORKS A DISSERTATION
Information Security (Dissertation)
-
Upload
akshat-ratanpal -
Category
Technology
-
view
1.794 -
download
0
description
Transcript of Information Security (Dissertation)
Investigation into Delegation in a Federated Environment
MSc Dissertation (COMM002)
Akshat Ratanpal (URN: 6190741)
Submitted for the Degree of
Master of Science in Security Technologies and Applications
from the
Department of Computing
Faculty of Engineering and Physical Sciences
University of Surrey
Guildford, Surrey, GU2 7XH, UK
August 2012
Supervised by: Dr Helen Treharne
© Akshat Ratanpal 2012
Distributed Board Game Environment
MSc Dissertation COMM002
Peter Helland 1366211
Submitted for the Degree of Master of Science in Internet Computing
from the
Department of Computing
Faculty of Engineering and Physical Sciences University of Surrey
Guildford, Surrey, GU2 7XH, UK
16th August 2010
Supervised by: Dr Roger Peel
Peter Helland 2010
Investigation into Delegation in a Federated Environment August 27, 2012
2
Abstract
Identity delegation is the process of an entity authorizing another entity to use their identity
information. Quite a lot of research of research has been done when dealing with delegation. But
most of the researches cover only a limited scope of delegation. In this thesis we will be looking
into the need for delegation, what are the technologies that support delegation and different types
of delegation. Furthermore, the work will concentrate on person-to-person type of delegation, and
taking that into context, a pre-existing model will be analyzed and evaluated. The work will
concentrate on the architecture and the security protocol within the model. A new model for secure
and dynamic delegation model will be proposed, which will provide secure and dynamic
delegation framework for both within and beyond a Federated environment.
Investigation into Delegation in a Federated Environment August 27, 2012
3
ACKNOWLEDGEMENTS
I take this opportunity to thank my dissertation supervisor, Dr Helen Treharne, for her guidance
and motivation during the course of this dissertation. Without her encouragement and motivation I
would not have been able to achieve such an in-depth understanding of the subject. She was always
there whenever I needed help and guided me through the challenging stages of the dissertation.
I would like to dedicate this dissertation to my parents. Without their continuous support I would
never have the life I have. Their sacrifices for their kids are my biggest motivation to succeed and I
hope to one day make them proud.
I would also like to thank my sister and my dog ‘Gappu’. My sister has always been my pillar of
support and I thank her for being there always.
Lastly, I would like to thank all the people who motivated me and supported me in any way during
my masters and in completion of my dissertation.
Investigation into Delegation in a Federated Environment August 27, 2012
4
Table of Contents
1 Introduction to the Dissertation ................................................................................... 8 1.1 Objectives: ................................................................................................................................. 9 1.2 Structure of the Report ............................................................................................................ 10
1.2.1 Literature Review ............................................................................................................ 11 1.2.2 Overview of AVISPA ...................................................................................................... 11 1.2.3 Problem Analysis ............................................................................................................. 11 1.2.4 Modeling of Protocol ....................................................................................................... 11 1.2.5 Evaluation ........................................................................................................................ 11 1.2.6 Conclusion ....................................................................................................................... 12
2 Literature Review ........................................................................................................ 13 2.1 Online Identity: ....................................................................................................................... 13
2.1.1 What is online Identity? ................................................................................................... 14 2.1.2 How is Online Identity created? ...................................................................................... 14 2.1.3 How many Identities does Bob have? .............................................................................. 15 2.1.4 What is the problem? ....................................................................................................... 17
2.2 Identity Federation .................................................................................................................. 17 2.2.1 What is Identity Federation? ............................................................................................ 17 2.2.2 How does Identity Federation Work? .............................................................................. 17 2.2.3 What is Delegation/Identity Delegation? ......................................................................... 22 2.2.4 How does Identity Delegation work? .............................................................................. 23
2.3 Security Assertion Markup Language (SAML) ...................................................................... 23 2.3.1 What is SAML? ............................................................................................................... 23 2.3.2 When and why was SAML created? ................................................................................ 24 2.3.3 Why SAML? .................................................................................................................... 25 2.3.4 What is SAML made up of? ............................................................................................ 25 2.3.5 Relation between SAML and Identity Federation ........................................................... 36
2.4 SAML and Identity Delegation ............................................................................................... 37 2.4.1 Scenario 1: ....................................................................................................................... 37 2.4.2 Scenario 2: ....................................................................................................................... 39 2.4.3 Scenario 3: ....................................................................................................................... 40
3 Overview of AVISPA ................................................................................................... 42 3.1 Introduction: ............................................................................................................................ 42 3.2 AVISPA architecture and HLPSL: ......................................................................................... 44
Investigation into Delegation in a Federated Environment August 27, 2012
5
3.2.1 On-the-fly Model-Checker (OFMC): .............................................................................. 44 3.2.2 CL based Attack Searcher (CL-Atse): ............................................................................. 45 3.2.3 SAT Based Model-Checker (SATMC): .......................................................................... 45 3.2.4 Tree Automata-based Protocol Analyzer (TA4SP): ........................................................ 45
3.3 HLPSL Syntax: ....................................................................................................................... 46 3.3.1 Basic Roles: ..................................................................................................................... 46 3.3.2 Transitions: ...................................................................................................................... 47 3.3.3 Composed Roles: ............................................................................................................. 48
3.4 Basic Overview of Dolev-Yao Model: ................................................................................... 50
4 Problem Analysis ......................................................................................................... 54 4.1 Introduction: ............................................................................................................................ 54 4.2 Introduction to Scenario: ......................................................................................................... 54 4.3 Conceptual model: .................................................................................................................. 55
4.3.1 Entities: ............................................................................................................................ 56 4.3.2 Working: .......................................................................................................................... 57
4.4 Analysis: .................................................................................................................................. 60 4.4.1 Introduction: ..................................................................................................................... 60 4.4.2 Advantages: ..................................................................................................................... 60 4.4.3 Attack Scenarios: ............................................................................................................. 62 4.4.4 Limitations: ...................................................................................................................... 69
5 A New Conceptual model ............................................................................................ 71 5.1 Introduction: ............................................................................................................................ 71 5.2 Review of Key requirements for a new model: ...................................................................... 71 5.3 Conceptual Model: .................................................................................................................. 72 5.4 New architectural components: ............................................................................................... 73
5.4.1 Privilege authorization directory: .................................................................................... 73 5.4.2 Credential conversion service: ......................................................................................... 74 5.4.3 Reputation framework: .................................................................................................... 74
5.5 Working of the Model: ............................................................................................................ 74 5.5.1 Steps in the model: ........................................................................................................... 75
6 Conclusions: ................................................................................................................. 80 6.1 A look Back: ........................................................................................................................... 80 6.2 Achievements: ......................................................................................................................... 81
6.2.1 Explore Identity Federation: ............................................................................................ 81 6.2.2 Explore SAML: ................................................................................................................ 82 6.2.3 Test and Evaluation of Protocols: .................................................................................... 82 6.2.4 Conceptualization of a new model: ................................................................................. 82
Investigation into Delegation in a Federated Environment August 27, 2012
6
6.3 Conclusion: ............................................................................................................................. 83
7 Bibliography: ............................................................................................................... 84
Investigation into Delegation in a Federated Environment August 27, 2012
7
Figure 1: Structure of the Report ........................................................................................ 10 Figure 2: Online Identity from[5] ........................................................................................ 14 Figure 3: Online information sharing from[6] .................................................................... 15 Figure 4: Online Identity Mapping from [7] ........................................................................ 16 Figure 5: General Single Sign-on Use case from [3] .......................................................... 18 Figure 6: General Identity Federation Use Case from[3] ................................................... 19 Figure 7: Example of Usage of Facebook Connect from [10] ............................................. 21 Figure 8: Timeline of SAML till year 2007 .......................................................................... 24 Figure 9: Primary components of SAML obtained from [3] ................................................ 26 Figure 10: Example of a SAML assertion from [3] ............................................................. 28 Figure 11: Types of SAML Bindings .................................................................................... 31 Figure 12: SAML profiles .................................................................................................... 34 Figure 13: Additional SAML components from[3] .............................................................. 35 Figure 14: Scenario 1 .......................................................................................................... 38 Figure 15: Scenario 2 .......................................................................................................... 40 Figure 16: Scenario 3 .......................................................................................................... 40 Figure 17: Architecture of AVISPA from[15] ...................................................................... 44 Figure 18: Role definition obtained from[25] ...................................................................... 47 Figure 19: Transition for Server (S) obtained from[25] ...................................................... 48 Figure 20: Role session obtained from [25] ........................................................................ 49 Figure 21: Declaration of role environment obtained from[25] ......................................... 50 Figure 22: Motivating Scenario obtained from[4] .............................................................. 55 Figure 23: Delegation Authorization Mediation obtained from[4] ..................................... 57 Figure 24: Delegated access interaction obtained from [4] ................................................ 59 Figure 25: MSC Attack Trace from OFMC tool .................................................................. 63 Figure 26: MSC attack trace from CL-Atse tool .................................................................. 64 Figure 27: MSC attack trace from OFMC ........................................................................... 65 Figure 28: MSC attack trace from CL-Atse ......................................................................... 66 Figure 29: MSC attack trace from CL-Atse ......................................................................... 67 Figure 30: New delegated access interactions .................................................................... 75 Figure 31: Structural overview of the new model ................................................................ 78
Investigation into Delegation in a Federated Environment August 27, 2012
8
1 Introduction to the Dissertation
Online identities refer to the repository of information collected by identity providers or
service provider over time about a user, through a user’s interactions with these systems. A user
once registered with these systems requests for services offered by the services providers, by
authenticating herself to the system. The user identifies itself with the email-id or username and the
challenge that is posted by the system in the form of a password, or one time key. Once a user is
authenticated to these systems, the user is allowed to access the services that are being offered by
the service provider. With the growth in Internet and the exponential increase in the services being
offered online, a user is made or asked to create multiple identities to access these services. A user
could have one identity for a service and a totally different identity for another service. The process
of creating new identities for every different service makes it very difficult for a user to manage
his/her identity. Not just a user, managing so many identities becomes very difficult even for
service provider and identity providers.
The problem of creating and managing multiple identities of a user became a problem for all the
entities involved in the interaction. From the user to the identity provider and to the service
provider who would offer his services once a user has been authenticated and creates an account
for the user on its side. A user would end up having more than six to seven identities for the
different services that a user used. A solution has been devised and is being commonly used these
days, i.e. Identity Federation.
Identity federation is the concept of linking of users various identities and attributes stored across
different system. Identity federation allows a user to use a single or lesser number of identities to
authenticate. One of the early implementation of Identity federation was the single sign on
(SSO)[1].
The open group, the proprietors and creator of single sign on mechanism define SSO as
“mechanism whereby a single action of user authentication and authorization can permit a user to
access all computers and systems where he has access permission, without the need to enter
multiple passwords. Single sign-on reduces human error, a major component of systems failure and
is therefore highly desirable but difficult to implement” [1]. SSO is just a technical part of the
Investigation into Delegation in a Federated Environment August 27, 2012
9
whole concept of Federated identity management (FIdM). FIdM extends not just to the technical
aspect of security, but also to the non-technical aspects.
Federated Identity Management (FIdM) has been described quite excellently by Zuo, Luo, Zeng et
al. as “FIdM allows the use of same users Personal Identification Information (PII) across multiple
organizations within a federation. The PII includes user’s login names, user properties, and user
identity attributes.”[2] The technologies used for federated identity are SAML, OAuth and
OpenID. I will be discussing SAML quite extensively in my dissertation.
SAML (Security Assertion Markup Language)[3] is an open standard that has been managed by
the OSASIS security services technical committee. SAML is an open standard that allows for
identity information like, authentication and authorization across different domains. SAML allows
an identity provider to create a SAML assertion containing the information of a user, and
communicate it to the service provider for the service provider’s authentication requirements.
SAML assertions provide an easy and secure method of communicating user information across
different security domains.
The increase in the number of web services on the Internet has also lead to an increase in the
instances wherein a user has to share her identity information with another entity. The sharing
could be with a service provider wherein; a service provider needs some identity information of a
user before provisioning any services. This identity information sharing is called identity
delegation. Social networks and applications running on those platforms are a good example of
identity delegation being used to provide users the services it needs. Quite a lot of research has
gone into identity delegation between a user, service provider and an identity provider. But not
much has been talked about when a user delegates her identity to another user than a service
provider. The purpose of my dissertation is to study and analyze this form of delegation.
My inspiration to research identity delegation among users, was ignited by a research paper that I
had read. Japanese researcher, Hidehato Gomi, authored the paper. The paper [4], discusses
identity delegation among users. The paper also introduces a real life scenario wherein; a husband
and wife need to share their identity information with a service provider before a service could be
provided. The paper was an interesting read and motivated me further to read about Online
identities, Identity Federation, Identity delegation and SAML. My main motivation was to present
my acquired knowledge of the subject and to come up with a new framework.
1.1 Objectives:
Investigation into Delegation in a Federated Environment August 27, 2012
10
The objectives of the dissertation are as follows:
1. Overview of delegation in a Federated environment
2. Overview of the literature on Federation and Identity delegation.
3. Overview of Technologies that help support delegation in a federated environment
4. Review and analysis of a proposed model for secure and dynamic data access management
using delegation.
5. Evaluating the security and validity of the protocol proposed, by testing it on a security
protocol analyzer.
6. Present a new model or framework for delegation within and beyond the boundaries of
Federation.
1.2 Structure of the Report
Figure 1: Structure of the Report
Introduction
Literature Review
Overview of AVISPA
Problem Analysis
A new conceptual model
Conclusion
Investigation into Delegation in a Federated Environment August 27, 2012
11
This section of the report will talk about how the thesis will be structured and what all will be
covered during the course of this thesis.
1.2.1 Literature Review
The chapter will start with a brief overview of what online identities are and how are they
used. Then the chapter continues in to detailed description of Identity Federation. Apart from that,
we will have a detailed study on Identity delegation and SAML. SAML will be discussed quite
extensively with some examples of how SAML supports Identity Delegation. Then we explore
SAML artifacts that support identity delegation.
1.2.2 Overview of AVISPA
The literature will continue into the security analysis of things. We will have a detailed description
of the technology AVISPA, which is being used to map the protocol and find the possible attacks
on it. AVISPA will be studied along side the language that it uses to map protocols, i.e. HLPSL.
The chapter also contains an analysis of the D. Dolev and A. Yao intruder model that is being used
to plot an attack on the protocol.
1.2.3 Problem Analysis
This chapter will contain a thorough and detailed study of Hidehato Gomi’s paper on
Dynamic Identity Delegation Using Access Tokens in Federated Environments. A detailed analysis
will be done of the conceptual model proposed by the author. Key points and assumption from the
paper will be prioritized and categorized for a critical study.
1.2.4 Modeling of Protocol
In this chapter we will model the proposed model in to HLPSL, and run the protocol on
AVISPA. AVISPA will be used to find possible attacks on the protocol.
1.2.5 Evaluation
The chapter will evaluate the results obtained from modeling of protocol on AVISPA. A
critical analysis of the attacks and possible improvements in protocol will be discussed in this
Investigation into Delegation in a Federated Environment August 27, 2012
12
chapter. A new and improved conceptual model will be proposed. A critical analysis will be
performed of the newly proposed model. The next part of the chapter will include a review of
previous research on identity delegation and how concepts from those researches can be
incorporated in to the original or new model to extend the model across security domains.
1.2.6 Conclusion
The chapter summarizes the work done from the research and gives a short concluding
remark on the results obtained.
Investigation into Delegation in a Federated Environment August 27, 2012
13
2 Literature Review This chapter covers the theoretical background of the dissertation. In the section 2.1 we will start
off by discussing online identities and the problem associated with multiple identities. In section
2.2 we will look into how the previous problem is solved using Identity Federation. This section
will also cover the basic idea of Federation and how it is implemented using few examples. Within
this section we will touch upon delegation but will not dwell into more details. In section 2.3, we
will look at how SAML helps provide a framework for Identity Federation. We will look at the
structure and components of SAML that provide features that enable entities to share credentials
securely within a federated environment.
2.1 Online Identity:
Investigation into Delegation in a Federated Environment August 27, 2012
14
2.1.1 What is online Identity?
Online Identity as the name suggests is the identity a user uses to identify itself to different
online services.
Figure 2: Online Identity from[5]
So what really is Online Identity? Online identity is basically the repository of information
collected about a user over time through the user interaction with various systems.
2.1.2 How is Online Identity created?
The following example will help understand about how and what really comprises as
online identity.
For example, a user Bob has an account on the social networking site Facebook1. Bob authenticates
itself to access Facebook by giving his username or email-id and then a password. These two
elements, email ID or password form just the base of user bob’s online identity. Once Bob has
logged in to Facebook and adds more information to his account for instance, his phone number,
1 http://www.facebook.com
Investigation into Delegation in a Federated Environment August 27, 2012
15
address, date of birth, place of birth, favorite color etc. forms the core of Bob’s identity. It’s the
collection of this information and other information, like bank account details, social security
numbers; passport; number; height; weight etc. form the crux of Bob’s online identity. It’s this
collection or repository of information that is known as the online identity of a user.
A user shares his information with various different systems that it interacts with on a regular
basis. With each interaction, some data is generated about a user. This data is collected over time
by these systems and accumulated to form users Online Identity.
Figure 3: Online information sharing from[6]
2.1.3 How many Identities does Bob have?
So we continue with our example of Bob; Bob does not just have a Facebook account. In
fact, Bob uses many different web services. For paying his electricity bills, bob has signed up for
online billing by creating an identity at the electricity company. For his emails and chats Bob uses
Gmail services. Before Bob could use Gmail’s services, Bob has to create an account and share his
information with Gmail too. To pay his telephone and mobile bills, Bob has signed up online with
his service provider. The service provider has asked Bob to create an account at the SP’s web
Investigation into Delegation in a Federated Environment August 27, 2012
16
application and input his personal information. For travel, hotel and transport booking, Bob has
created another account with a different portal. The portal asks the same thing as previously
discussed web applications, i.e. Bob shares his personal information with the application before
Bob is allowed to access any services. As we can see, Bob has to create multiple identities at
multiple service providers to be allowed to access any of the services. An aggregation of the
different online identities that we create and how they are mapped to different services will helps
us understand the problem that we are dealing with;
Figure 4: Online Identity Mapping from [7]
Investigation into Delegation in a Federated Environment August 27, 2012
17
2.1.4 What is the problem?
The problem is that Bob or User has to share his personal information with multiple
service providers. The user has to create a unique identity with each service provider. The task can
be tedious. Above all, there are security implications to information sharing with so many different
service providers. First, not all service providers have a standardized security policy on how to
manage a user’s information. Secondly, some service providers outsource their data management
process to third parties. Which may or may not follow the strict security policies of the service
provider that the user has trusted with his personal information. So how does a user avoid the
tedious task of creating multiple identities and be able to trust the service provider with his
personal information. The solution is Identity Federation.
2.2 Identity Federation
2.2.1 What is Identity Federation?
“A federated identity in information technology is the means of linking a person's
electronic identity and attributes, stored across multiple distinct identity management systems” [8].
Identity Federation allows a user to use the same identity information across multiple systems. This
helps the users to reduce the effort of creating multiple identities for each service rendered. It also
allows Identity management systems and service provider to make Identity management easier.
Identity Federation or commonly known as Federated Identity Management has been excellently
defined by Zuo et al.. as “FIdM allows the use of same users Personal Identification Information
(PII) across multiple organizations within a federation. The PII includes user’s login names, user
properties, and user identity attributes.”[2]
2.2.2 How does Identity Federation Work?
The system revolves around the two primary entities i.e. IdP (Identity provider) and the SP
(Service provider/providers). IdP is the identity storage, whereas SP is the provider of services that
a user may require. Due to the nature of the design of the system, there is pre-established trust
between the SP and IdP, which allows quick and easy access of services to the user. This concept
Investigation into Delegation in a Federated Environment August 27, 2012
18
allows the user not to register or login at different web services, instead, use the same identity
across different web services. A user could be registered with only one IdP or SP and if the there is
a pre-established trust between these entities then user can be allowed to authenticate himself
through a single identity across multiple systems. The working of the Identity federation and how
IdP and SP share user identity information in Single Sign-On (A sub domain of Identity
Federation) is show in figure 4:
Figure 5: General Single Sign-on Use case from [3]
In the figure above it can be seen how a user has to authenticate at the IdP, which in this case is
airline.example.com, and the IdP then shares the users information with the SP, which in this case
is cars.example.com, from whom the user has requested for some restricted resources or services.
It is to be noted that this type of information sharing is only possible if there has been a previous
business agreements between the two parties involved in the user’s information sharing.
The previous example demonstrated how a users information is shared between two entities that
have pre-established trust relationship. But, Identity Federation Management goes much beyond
This high-level description indicated that the user had first authenticated at the IdP before accessing a protected resource at the SP. This scenario is commonly referred to as an IdP-initiated web SSO scenario. While IdP-initiated SSO is useful in certain cases, a more common scenario starts with a user visiting an SP site through a browser bookmark, possibly first accessing resources that require no special authentication or authorization. In a SAML-enabled deployment, when they subsequently attempt to access a protected resource at the SP, the SP will send the user to the IdP with an authentication request in order to have the user log in. Thus this scenario is referred to as SP-initiated web SSO. Once logged in, the IdP can produce an assertion that can be used by the SP to validate the user's access rights to the protected resource. SAML V2.0 supports both the IdP-initiated and SP-initiated flows.
SAML supports numerous variations on these two primary flows that deal with requirements for using various types and strengths of user authentication methods, alternative formats for expressing federated identities, use of different bindings for transporting the protocol messages, inclusion of identity attributes, etc. Many of these options are looked at in more detail in later sections of this document.
3.3 Identity Federation Use Case
As mentioned earlier, a user's identity is said to be federated between a set of providers when there is an agreement between the providers on a set of identifiers and/or identity attributes by which the sites will refer to the user.
There are many questions that must be considered when business partners decide to use federated identities to share security and identity information about users. For example:
• Do the users have existing local identities at the sites that must be linked together through the federated identifiers?
• Will the establishment and termination of federated identifiers for the users be done dynamically or will the sites use pre-established federated identifiers?
• Do users need to explicitly consent to establishment of the federated identity?
• Do identity attributes about the users need to be exchanged?
• Should the identity federation rely on transient identifiers that are destroyed at the end of the user session?
• Is the privacy of information to be exchanged of high concern such that the information should be
sstc-saml-tech-overview-2.0-cd-02 Mar 25,2008Copyright© OASIS® 2008. All Rights Reserved.
Figure 2: General Single Sign-On Use Case
Business agreement
Source web site:airline.example.com
Authenticate
1
Accessprotectedresource
2
Identity
info
rm
atio
nDestination web site:cars.example.co.uk
SSO-usecase
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
Investigation into Delegation in a Federated Environment August 27, 2012
19
that. The next scenario that I have considered in my research on Identity federation involves
multiple service providers, and how identity information is shared among them.
2.2.2.1 Example 1:
A user John Doe has registered and created unique identities of johndoe, jdoe and johnd
at airlines.example.com, cars.example.com and hotels.example.com respectively. The three service
providers have come to an agreement and allow a user to use the same identities across the three
service providers. The user John Doe hasn’t yet federated his identities across these three service
providers.
Figure 6: General Identity Federation Use Case from[3] The processing sequence is as follows:
1. John books a flight at airline.example.com using his johndoe user account.
2. John then uses a browser bookmark or clicks on a link to visit cars.example.co.uk to reserve a car. This site sees that the browser user is not logged in locally but that he has previously visited their IdP partner site airline.example.com (optionally using the new IdP discovery feature of SAML V2.0). So cars.example.co.uk asks John if he would like to consent to federate his local cars.example.co.uk identity with airline.example.com.
3. John consents to the federation and his browser is redirected back to airline.example.com where the site creates a new pseudonym, azqu3H7 for John's use when he visits cars.example.co.uk. The pseudonym is linked to his johndoe account. Both providers agree to use this identifier to refer to John in subsequent transactions.
4. John is then redirected back to cars.example.co.uk with a SAML assertion indicating that the user represented by the federated persistent identifier azqu3H7 is logged in at the IdP. Since this is the first time that cars.example.co.uk has seen this identifier, it does not know which local user account to which it applies.
5. Thus, John must log in at cars.example.co.uk using his jdoe account. Then cars.example.co.uk attaches the identity azqu3H7 to the local jdoe account for future use with the IdP airline.example.com. The user accounts at the IdP and this SP are now linked using the federated name identifier azqu3H7.
6. After reserving a car, John selects a browser bookmark or clicks on a link to visit hotels.example.ca in order to book a hotel room.
7. The federation process is repeated with the IdP airline.example.com, creating a new pseudonym, f78q9C0, for IdP user johndoe that will be used when visiting hotels.example.ca.
sstc-saml-tech-overview-2.0-cd-02 Mar 25,2008Copyright© OASIS® 2008. All Rights Reserved.
Figure 3: General Identity Federation Use Case
airline.example.com
Book flight logged inas johndoe
Prepare to rent car logged inas jdoe; accept offer of
federation with airline.example.com
cars.example.co.uk hotels.example.ca
Prepare to book hotel logged inas johnd; accept offer of
federation with airline.example.com
Agree on azqu3H7 for referring to John(neither knows the local ID used on the other side)
Agree on f78q9c0 for referring to John(neither knows the local ID used on the other side)
No correlation of John'sactivities across these sites
IDFed-usecase
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
Investigation into Delegation in a Federated Environment August 27, 2012
20
1) John first logs in at airline.example.com and books his flights.
2) Now John decides to book a car for his travel. So he follows a link on the
airline.example.com page and gets to the page of cars.example.com. The cars.example.com site
sees that the user hasn’t logged in, but has come from a site that is a federated partner. So the site
asks the user to use his airline.example.com identity to access the resources at the website.
3) The user is taken back to the previous site and this time airline.example.com acts as an
identity provider than a service provider. It creates a pseudonym for John Doe and sends it to
car.example.com. This ensures that the information provided by the user to cars.example.com
comes from a trusted source. Secondly, it lays down the foundation for user being allowed to link
his local identity with his identity provider identity.
4) The aforementioned scenario happens once the IDP (airline.example.com) creates a
pseudonym and sends it to SP (cars.example.com) to identify the user. The SP still has no way of
knowing for sure that the user requesting the services is a registered user or not, and to which
identity does the particular pseudonym link to.
5) The user is asked to log in at the SP and then the pseudonym issued by the IDP is linked to
the user’s account at the SP. This allows the user to be able to use just a single login session at the
IDP to be able to use the services offered by the IDP’s federated partners.
6) The same scenario takes place at hotels.example.com. The user once clicked on
hotels.example.com is taken back to airline.example.com and a pseudonym is created linking the
users local identity to the users identity at the IDP (i.e. airline.example.com).
So for any future booking the user has to login just once at the IDP (airline.example.com) and
would able to use the services offered by both hotels.example.com and cars.example.com without
having to login at each service provider.[3]
The previously mentioned scenario is just one type of identity federation wherein the user already
has local accounts and is then allowed to link those accounts with his main account at the identity
provider. This example is an important example in understanding federation as well as delegation.
The user can have an account at an IdP say, airline.example.com. The user now wants to delegate
the task of booking of hotels and renting cars to this IdP, which would act as a service provider in
the new scenario. More about delegation would be discussed in section 2.2 and 2.3. Another
Investigation into Delegation in a Federated Environment August 27, 2012
21
scenario that we are going to discuss is wherein the user does not even have to have local accounts
previously established at service providers. Instead, the user can just use his unique identity created
at an Identity Provider to authenticate himself at the service providers that are in federation with
the identity provider. The next example is very similar to the issues we will be discussing in
chapter 4 of problem analysis.
2.2.2.2 Example 2:
In 2008, Facebook came up with an excellent use of its platform as the identity provider
called Facebook Connect [9]. Facebook connect allows users to use their Facebook identity or the
information shared with Facebook as a means of identifying themselves to a service provider.
Facebook connect allows users to visit a site and not have to do a new registration at the site.
Instead, the user can just click on the Facebook Connect button on the site to allow the site to use
the users Facebook identity as the means to identify the user. Facebook connect is available on
thousands of websites. The user can have control over the information it shares with these sites by
changing his privacy settings at his single Facebook account. The change in settings is then applied
at all the sites where the user has used his Facebook identity as a means of authentication. [6]
Figure 7: Example of Usage of Facebook Connect from [10]
Investigation into Delegation in a Federated Environment August 27, 2012
22
Facebook Connect helps reduce the work of a user, by completely eliminating the tedious job of
registering at each site to access the services offered. It also gives the user more control over the
type of information that it shares with a service provider. Also, Identity federation using Facebook
Connect greatly reduces the identity management tasks of the service provider. The service
provider can focus on offering services based upon the users information obtained from Facebook,
rather than managing every user’s personal information. It also reduces the chances of
mismanagement of users information like, stealing of personal data, theft of username and
password, and accidental or intentional modification of users identity information, and sharing of
users personal information with an un-trusted third party.
After reviewing identity delegation we have realized that a single authentication session can allow
a user to have access to various services offered by multiple service providers that are in federation
with the identity provider.
With the growing number of services shifting online has made the job of a user easier and difficult
at the same time. Services like voter registration, income tax filing, events registration, registering
for health or motor insurance, employment services, pensions or funds tracking can all be done
online these days. But, there are times where a user does not have the knowledge or the time to
perform these tasks. So a user needs to hire a third party that would do these tasks on the users
behalf. So how does that happen in a federated or a non-federate environment? What is such a
process called?
2.2.3 What is Delegation/Identity Delegation?
“Delegation is the process whereby an identified entity confers a mandate to another
identified entity”[11]. It is basically the process wherein, an entity known as the delegator gives the
authority to another entity known as the delegatee to perform some actions on his behalf at a
service provider [12].
The three primary entities in identity delegation procedure according to Peeters et al. [12] are as
follows:
- Delegator: It is the entity that gives the right to another entity to perform privilege actions
on his behalf.
- Delegatee: It is the entity that receives the right from a delegator to perform some privilege
actions on the behalf of the delegator.
Investigation into Delegation in a Federated Environment August 27, 2012
23
- Service Provider: Is the entity that provides the services to the delegatee on the behalf of
the delegator.
Another entity that plays a crucial role in the delegation process is:
- Token Authority: Is the entity that is responsible for creations of assertion tokens that are
passed to the delegatee via the delegator as a form of proof for the delegation process.
2.2.4 How does Identity Delegation work?
Before we see how Identity delegation works. We need to understand the background and
details of the technology that helps support identity delegation and Identity federation in a secure
way.
2.3 Security Assertion Markup Language (SAML)
2.3.1 What is SAML?
SAML is an XML-based framework designed by the security services technical committee
of Organization for the Advancement Structured Information Standards (OASIS). SAML allows
for entities to share information regarding a user’s permissions, attributes, and identity with other
entities in a secure and seamless manner. SAML is a flexible protocol that can be extended or
customized for other existing secure communications standards like the liberty alliance, the
shibboleth project, and OASIS web services security [13]. Most of these standards have already
incorporated SAML as a technology in some way or the other in their standards
Investigation into Delegation in a Federated Environment August 27, 2012
24
2.3.2 When and why was SAML created?
Figure 7 gives a historic timeline of SAML
Figure 8: Timeline of SAML till year 2007
2001 Jan • OASIS SSTC committe meet for the Pirst time
2002 Nov
• SAML v1.0 was announced as an OASIS standard
2003 Apr • Liberty releases ID-‐FF 1.1
2003 Sep • SAML v1.1 is Introduced
2003 Sep • Liberty contributes ID-‐FF to OASIS
2003 Nov • Liberty ID-‐FF v1.2 is Pinalized
2005 Mar • SAML v2.0 is announced
2007 Jul • Errata approved for SAML v2.0
Investigation into Delegation in a Federated Environment August 27, 2012
25
Quite a few improvements and additions have been made to SAML since its inception. This has
offered SAML great flexibility, and has been widely accepted as a security standard.
2.3.3 Why SAML?
The OASIS SAML executive review [11] gives some really good reasons for the adoption
and popularity of SAML:
1. Certain implementations of SAML can make the Identity Provider more responsible for
identity management than the service provider.
2. SAML enables Single Sign-on for users. It also allows for information customization when
sharing with various service providers, so as to maintain a certain level of privacy.
3. It also reduces the effort and cost of service providers in maintaining and managing
identity information.
4. Above all, SAML is platform neutral. So it can be implemented by different services with
different architectures. For example, SAML has been implemented to enable Single Sign-on and
delegation efficiently in both IBM’s WebSphere 2, and also in Microsoft’s cloud services3.
2.3.4 What is SAML made up of?
SAML consists of four primary components and two additional components that add
further functionality to SAML.
2 http://www-‐01.ibm.com/software/websphere/ 3 http://www.microsoft.com/en-‐gb/directory/cloud.aspx
Investigation into Delegation in a Federated Environment August 27, 2012
26
Figure 9: Primary components of SAML obtained from [3]
4 SAML ArchitectureThis section provides a brief description of the key SAML concepts and the components defined in the standard.
4.1 Basic Concepts
SAML consists of building-block components that, when put together, allow a number of use cases to be supported. The components primarily permit transfer of identity, authentication, attribute, and authorization information between autonomous organizations that have an established trust relationship. The core SAML specification defines the structure and content of both assertions and protocol messages used to transfer this information.
SAML assertions carry statements about a principal that an asserting party claims to be true. The valid structure and contents of an assertion are defined by the SAML assertion XML schema. Assertions are usually created by an asserting party based on a request of some sort from a relying party, although under certain circumstances, the assertions can be delivered to a relying party in an unsolicited manner. SAML protocol messages are used to make the SAML-defined requests and return appropriate responses. The structure and contents of these messages are defined by the SAML-defined protocol XML schema.
The means by which lower-level communication or messaging protocols (such as HTTP or SOAP) are used to transport SAML protocol messages between participants is defined by the SAML bindings.
Next, SAML profiles are defined to satisfy a particular business use case, for example the Web Browser SSO profile. Profiles typically define constraints on the contents of SAML assertions, protocols, and bindings in order to solve the business use case in an interoperable fashion. There are also Attribute Profiles, which do not refer to any protocol messages and bindings, that define how to exchange attribute information using assertions in ways that align with a number of common usage environments (e.g. X.500/LDAP directories, DCE).
Figure 4 illustrates the relationship between these basic SAML concepts.
Two other SAML concepts are useful for building and deploying a SAML environment:
• Metadata defines a way to express and share configuration information between SAML parties. For instance, an entity's supported SAML bindings, operational roles (IDP, SP, etc), identifier information, supporting identity attributes, and key information for encryption and signing can be
sstc-saml-tech-overview-2.0-cd-02 Mar 25,2008Copyright© OASIS® 2008. All Rights Reserved.
Figure 4: Basic SAML Concepts
ProfilesCombinations of assertions, protocols,
and bindings to support a defined use case
BindingsMappings of SAML protocolsonto standard messaging and
communication protocols
ProtocolsRequests and responses for
obtaining assertions and doingidentity management
AssertionsAuthentication, attribute, and
entitlement information
MetadataConfiguration data for
identity and service providers
Authentication ContextDetailed data on types
and strengths of authentication
SAML-concepts
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
483
484
485
486
Investigation into Delegation in a Federated Environment August 27, 2012
27
2.3.4.1 Assertions:
Assertions can be defined as the means of an entity to convey security information about
another entity. SAML does it in the form of statements that are part of the message. The statements
contain information like an entity’s name, group, ID, and any other relevant information. For
example, if an entity, like an identity provider wants to convey information about one of its user’s
named John Doe, to a service provider. Then the identity provider can use SAML assertions, which
may include user’s information like his name John Doe, email-ID as [email protected] and
group “engineers”. In the previous scenario John Doe is the subject of the assertion. Every
assertion contains a subject of assertion, conditions for assertion and assertion statements.
There are primarily three types of statements in a SAML assertion:
2.3.4.1.1 Authentication Statements:
These statements contain information regarding how and when the subject of the
assertion was authenticated.
2.3.4.1.2 Attribute Statements:
Contain or convey the attribute information about a subject of the assertion. For
example, name ‘John Doe’ is part of the ‘engineering’ group.
2.3.4.1.3 Entitlement Information:
They define the ‘if’ and ‘what’ the subject of the assertion is entitled to do.
An example of how a SAML assertion looks like is given in figure 10:
Investigation into Delegation in a Federated Environment August 27, 2012
28
Figure 10: Example of a SAML assertion from [3]
4.4.2 Assertion, Subject, and Statement Structure
1: <saml:Assertion xmlns:saml=”urn:oasis:names:tc:SAML:2.0:assertion” 2: Version="2.0" 3: IssueInstant="2005-01-31T12:00:00Z"> 4: <saml:Issuer Format=urn:oasis:names:SAML:2.0:nameid-format:entity> 5: http://idp.example.org 6: </saml:Issuer> 7: <saml:Subject> 8: <saml:NameID 9: Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">10: [email protected]: </saml:NameID>12: </saml:Subject>13: <saml:Conditions14: NotBefore="2005-01-31T12:00:00Z"15: NotOnOrAfter="2005-01-31T12:10:00Z">16: </saml:Conditions>17: <saml:AuthnStatement18: AuthnInstant="2005-01-31T12:00:00Z" SessionIndex="67775277772">19: <saml:AuthnContext>20: <saml:AuthnContextClassRef>21: urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport22: </saml:AuthnContextClassRef>23: </saml:AuthnContext>24: </saml:AuthnStatement>25: </saml:Assertion>
Figure 6: Assertion with Subject, Conditions, and Authentication Statement
Figure 6shows an XML fragment containing an example assertion with a single authentication statement. Note that the XML text in the figure (and elsewhere in this document) has been formatted for presentation purposes. Specifically, while line breaks and extra spaces are ignored between XML attributes within an XML element tag, when they appear between XML element start/end tags, they technically become part of the element value. They are inserted in the example only for readability.
sstc-saml-tech-overview-2.0-cd-02 Mar 25,2008Copyright© OASIS® 2008. All Rights Reserved.
Figure 5: Relationship of SAML Components
Transport protocol
Transport protocol header
Transport protocol payload
SAML response
AssertionAssertion
Authenticationstatement
Otherstatements
SAML-component-nesting
625
626
627
628
629
630
631
Investigation into Delegation in a Federated Environment August 27, 2012
29
The figure shows idp.example.com as the issuer of the assertion. The subject of the assertion that is
given by NameID is [email protected] and the conditions for the assertion are stated under the
Conditions section in line 13. It gives the validity time of the assertion.
2.3.4.2 Protocols:
SAML defines a number of request/response protocols:
2.3.4.2.1 Authentication Request Protocol:
It defines the protocol used when a service provider redirects a user to an identity
provider to confirm the user’s identity in a Single Sign-on scenario.
2.3.4.2.2 Single Logout Protocol:
Allows for a simultaneous logout for any number of active sessions for a particular
user.
2.3.4.2.3 Assertion Query and Request Protocol:
It defines the protocol that is used for requesting and delivery of an assertion.
2.3.4.2.4 Name Identifier Mapping Protocol:
This defines for the protocol used to map identity of a user across different SP’s
with the consent of the issuing authority, i.e. the IdP.
2.3.4.2.5 Name Identifier Management Protocol:
This defines the way names and format of the subject or the issuer can be changed
during the communication process.
2.3.4.2.6 Artifact Resolution Protocol:
Defines how a SAML message would be requested and retrieved using an SAML
Artifact. An Artifact is defined as “A 42-byte, hex-encoded ID that references an assertion stored
with the session server at the producer. The artifact enables the SAML Affiliate Agent to retrieve
an assertion document from the producer.”[14]
Investigation into Delegation in a Federated Environment August 27, 2012
30
2.3.4.3 Bindings:
SAML bindings as the name suggests determine the bindings of SAML messages to
different transport protocols. Bindings determine how SAML messages are carried over various
transport protocols. There are six different types of bindings defined.
2.3.4.3.1 HTTP Redirect Binding:
Defines how SAML messages are carried in HTTP redirect request.
2.3.4.3.2 HTTP POST Binding:
Defines how SAML messages can be transported in an HTTP POST request.
Investigation into Delegation in a Federated Environment August 27, 2012
31
Figure 11: Types of SAML Bindings
HTTP Redirect
HTTP Post
HTTP Artifact
SAML SOAP
Reverse SOAP
SAML URI
Investigation into Delegation in a Federated Environment August 27, 2012
32
2.3.4.3.3 HTTP Artifact Binding:
Defines how an SAML artifact is transported in an HTTP request.
2.3.4.3.4 SAML SOAP Binding:
Defines how SOAP messages are used for communicating SAML messages.
2.3.4.3.5 Reverse SOAP (PAOS) Binding:
Defines the communication within an HTTP/SOAP message that allows for role
reversal. For example, in a request, the client could play the role of the service provider and the
service provider as that of the client.
2.3.4.3.6 SAML URI Binding:
Defines how a SAML message would be resolved from a URI (Uniform Resource
Identifier).
2.3.4.4 Profiles:
OASIS’s SSTC have defined eight different SAML profiles. These profiles define how
SAML’s assertion, bindings and protocols combine for a particular scenario. Profiles offers sort of
interoperability of the previously discussed components of SAML for a particular use case or
scenario. For example, one of SAML’s profiles, i.e. Web Browser SSO profile defines how a
SAML profile is created to incorporate different components of SAML to ensure single sign-on.
The following figure states the different SAML defined profiles:
2.3.4.4.1 Web Browser SSO Profile:
Defines how SAML authentication request/ response protocol messages are
combined with SAML assertions and different combinations of SAML bindings like HTTP
Redirect, HTTP artifact and HTTP POST bindings to achieve single sign-on.
2.3.4.4.2 Enhanced Client and Proxy (ECP) Profile:
Investigation into Delegation in a Federated Environment August 27, 2012
33
Defines a unique scenario wherein, the client may or may not be part of the
communication. Instead, there could be a proxy filling up the role of client in the communication
process. Hence, a browser might not even be needed in such type of communication.
2.3.4.4.3 Identity Provider Discovery Profile:
It provides a way for service provider to discover the identity provider that a user
might have visited previously. An example of where such a profile might be created and used has
been previously discussed in the second example of identity federation use cases. Where the
service provider cars.example.com discovers that the user’s request or the user had visited its
federation partner and identity provider airline.example.com previously.
2.3.4.4.4 Single Logout Profile:
Defines how single logout is used with other SAML components.
2.3.4.4.5 Assertion Query/Request Profile:
As the name suggests, it defines a profile that is used to obtain SAML assertions
using unique identifiers. The process basically involves the process of first checking for an existing
of an assertion based upon an identifier. If it exists, then send an appropriate response to the
sender.
2.3.4.4.6 Artifact Resolution Profile:
The profile defines how artifact resolution is done over a SAML SOAP binding to
retrieve the message referred to by the artifact.
Investigation into Delegation in a Federated Environment August 27, 2012
34
Figure 12: SAML profiles
Web Browser SSO
ECP
Identity Provider Discovery
Single Logout
Assertion Query/ Request
Artifact Resolution
Name IdentiPier Mapping
Name IdentiPier
Management
Investigation into Delegation in a Federated Environment August 27, 2012
35
2.3.4.4.7 Name Identifier Management Profile:
Defines how the protocol name identifier management protocol, is used with
various SAML bindings.
2.3.4.4.8 Name Identifier Mapping Profile:
“Defines how the name identifier mapping protocol uses a synchronous binding
such as SOAP”[3].
The SAML components discussed above are also supported by two other SAML components that
support, and are useful in implementing a SAML environment are Authentication Context and
Metadata.
Figure 13: Additional SAML components from[3]
2.3.4.5 Authentication Context:
Authentication Context is a component of SAML. But it has its separate XML format to
convey the information within it. Authentication Context is basically used to convey information
regarding the authentication mechanism used by a SAML entity. For example, if a service provider
4 SAML ArchitectureThis section provides a brief description of the key SAML concepts and the components defined in the standard.
4.1 Basic Concepts
SAML consists of building-block components that, when put together, allow a number of use cases to be supported. The components primarily permit transfer of identity, authentication, attribute, and authorization information between autonomous organizations that have an established trust relationship. The core SAML specification defines the structure and content of both assertions and protocol messages used to transfer this information.
SAML assertions carry statements about a principal that an asserting party claims to be true. The valid structure and contents of an assertion are defined by the SAML assertion XML schema. Assertions are usually created by an asserting party based on a request of some sort from a relying party, although under certain circumstances, the assertions can be delivered to a relying party in an unsolicited manner. SAML protocol messages are used to make the SAML-defined requests and return appropriate responses. The structure and contents of these messages are defined by the SAML-defined protocol XML schema.
The means by which lower-level communication or messaging protocols (such as HTTP or SOAP) are used to transport SAML protocol messages between participants is defined by the SAML bindings.
Next, SAML profiles are defined to satisfy a particular business use case, for example the Web Browser SSO profile. Profiles typically define constraints on the contents of SAML assertions, protocols, and bindings in order to solve the business use case in an interoperable fashion. There are also Attribute Profiles, which do not refer to any protocol messages and bindings, that define how to exchange attribute information using assertions in ways that align with a number of common usage environments (e.g. X.500/LDAP directories, DCE).
Figure 4 illustrates the relationship between these basic SAML concepts.
Two other SAML concepts are useful for building and deploying a SAML environment:
• Metadata defines a way to express and share configuration information between SAML parties. For instance, an entity's supported SAML bindings, operational roles (IDP, SP, etc), identifier information, supporting identity attributes, and key information for encryption and signing can be
sstc-saml-tech-overview-2.0-cd-02 Mar 25,2008Copyright© OASIS® 2008. All Rights Reserved.
Figure 4: Basic SAML Concepts
ProfilesCombinations of assertions, protocols,
and bindings to support a defined use case
BindingsMappings of SAML protocolsonto standard messaging and
communication protocols
ProtocolsRequests and responses for
obtaining assertions and doingidentity management
AssertionsAuthentication, attribute, and
entitlement information
MetadataConfiguration data for
identity and service providers
Authentication ContextDetailed data on types
and strengths of authentication
SAML-concepts
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
483
484
485
486
Investigation into Delegation in a Federated Environment August 27, 2012
36
requires to know from the identity provider the method of authenticating a user. Then the identity
provider can provide the information in form of an XML message to convey information like
simple username-password authentication or two-factor authentication. It is used as an assertion to
share information regarding the means or ways used to authenticate a user.
2.3.4.6 Metadata:
Metadata as the name suggests is defined as data about data. In case of SAML entities, the
metadata components are used to convey information regarding certain aspects of a SAML entities
implementation of its SAML environment. It basically gives the information regarding
configuration of SAML entities like an SP or an IDP. For example, if in a message some sort of
hashing has been used then metadata is used to communicate the type of hashing algorithm used
for hashing the data.
2.3.5 Relation between SAML and Identity Federation
Now, after looking at all the components of SAML, we look back at section 2.2.2 where
we introduced identity federation with an example of single sign-on. We can see that SAML
components like Web Browser Single sign-on profile with a protocol like Authentication request
protocol and HTTP redirect and HTTP POST bindings can be used together to form a single sign-
on SAML environment. Also, inclusion of SAML’s single logout protocol ensures an almost
complete SAML Single Sign-On (SSO) environment. Hence, different SAML components can be
combined together in different ways to form a SAML based environment depending on a particular
use case. Similar to the Single Sign-On example of Identity federation, we implement the example
1 discussed in the section 2.2.2 using SAML. In that example we can use different combinations of
SAML assertions with SAML protocols like Authentication request, Name Identifier Mapping,
Name Identifier Management, and Assertion Query and Request protocols, with SAML profiles
like Identity provider discovery profile or Name Identifier Management profile or Name identifier
mapping profile to enable identity federation in the example discussed. In the scenario, SAML
assertions would contain information regarding the user, SP, IDP. They would also contain
pseudonym information communicated across by the IDP (airline.example.com) to a SP
(cars.example.com). An SP would use something like Identity provider discovery profile to learn
about the IDP that a user might have previously visited. All of this could be done very easily using
simple a browser and regular HTTP POST request. Hence, we see how SAML can be used to
enable a secure and privacy ensuring Identity Federation Environment. Now in the next part we
will discuss more about Identity Delegation and how SAML can be used and has been used to
enable Identity Delegation in an Identity Federation environment.
Investigation into Delegation in a Federated Environment August 27, 2012
37
2.4 SAML and Identity Delegation
This section of the documents will be dedicated to discussing the different types of
commonly adopted delegation models. These models will be analyzed with SAML as the
underlying technology.
2.4.1 Scenario 1:
This scenario basically involves four entities. They are; the client, service provider 1,
service provider 2 and a token generation service. The client wants to use the service provided by
service provider number 2. But due to lack of knowledge of how to perform the particular task, the
client delegates the task to service provider 1 that has expertise in performing tasks on behalf of
clients on service provider 2. So, the client needs to delegate its task to a service provider.
Investigation into Delegation in a Federated Environment August 27, 2012
38
Figure 14: Scenario 1
2.4.1.1 Working:
2.4.1.1.1 Step 1:
The delegator sends a request to the Security Token service to generate a SAML token
for delegation purposes.
2.4.1.1.2 Step 2:
The token generation service generates a token for the task of delegation, with the
subject as the ‘Delegator’. The token may contain other attributes about a subject like the group
name, email-ID etc. The token generated may or may not be signed by the issuer of the token. In
most cases, the token is signed.
2.4.1.1.3 Step 3:
The token generated is passed on to the service provider 1.
2.4.1.1.4 Step 4:
In this step there can be two scenarios. In the first scenario the original token may
contain all the information required and the SP1 does not have to send the token to the token
generation service for further processing. In the second scenario, the token received is sent to the
Investigation into Delegation in a Federated Environment August 27, 2012
39
token generation service to allow SP1 to authenticate itself and subsequently be allowed to act as
the delegator for the particular action. The original token and the newly generated token may both
have some conditions defined in the token. The conditions may state the time of assertion, the task
to be done, or the allowed privilege level.
2.4.1.1.5 Step 5:
The newly generated token for SP1 can now be forwarded to SP2 to allow SP1 to act on
the behalf of the Delegator. The SP1 performs the specified tasks on SP1 and passes on the result
to the Delegator.
2.4.1.1.6 Note:
<saml:condition> element is used as part of the assertion to state the conditions for
assertion. Conditions in this case are that the assertion is being used for the purpose of delegation.
Also, it may contain the type of delegation in the particular scenario. In our scenario, it is direct
delegation to a delegatee and the delegatee performs the task on the behalf of the delegator.
2.4.2 Scenario 2:
The second scenario that we consider to explain another use case of delegation is where a
user needs to use a service offered by a service provider. For example, the service provider offers
users to able to check their credit record and advice them on the type of insurance or loans a user
can go for depending on their economic records. The service provider asks the user to allow it to
have access to users personal information like, past loan, current loans, credit limit, bank account
information, investments made, etc. The scenario is quite similar to scenario 1 previously
discussed. The only difference being, that the user will create an assertion consisting of delegation
of the task to the service provider to have access to user personal information stored with the IdP.
The steps performed in the scenario are similar to the scenario previously discussed. Hence, I wont
be going in to the detail of the communication process. It is important to note that in this scenario,
the service provider will act on the behalf of the delegator and delegation token will be for the
purpose of accessing information at the issuer of the SAML token, i.e. IdP. In this scenario, the IdP
may put extra conditions and restriction on the allowed access to user personal information by the
service provider depending upon the user’s privilege level. This is done to restrict the chances of
any malicious activity on the part of the service provider. The transaction can also be monitored by
the IdP to keep a record of the transaction for future use, if there is a dispute of any kind.
The following figure will give a sketch of the communication that would take place.
Investigation into Delegation in a Federated Environment August 27, 2012
40
Figure 15: Scenario 2
2.4.3 Scenario 3:
Figure 16: Scenario 3
Investigation into Delegation in a Federated Environment August 27, 2012
41
The scenario above, scenario 3 hasn’t been much discussed and researched when it comes to
delegation. The above scenario is what we will be analyzing and discussing in the remaining
sections of this dissertation.
The scenario represents the situation where, a user 2 request for a service from the service provider
(SP). For the request, the SP requires information of both the user 1 and user 2. So user 2 needs to
request user 1 to hand over his information to user 2 in a form of delegation, as user 2 needs it for a
service at the SP. The user 1 authenticates itself and request for a delegation token to be generated
which will be passed to the SP via the user 2 for access to user 1’s personal information at the
identity provider (IdP). The scenario above will be looked into great detail, analyzed, evaluated
and solution on how to make this feasible and secure will be discussed in the next sections of this
dissertation.
Investigation into Delegation in a Federated Environment August 27, 2012
42
3 Overview of AVISPA
3.1 Introduction:
According to the AVISPA package user manual [15], AVISPA (Automated Validation of
Internet Security Protocols and Applications) is a tool designed to automate the procedure of
validating the security of Internet security protocols and applications. AVISPA offers tools and
applications for users to design their own security protocols or applications and validate them as
well.
Apart from AVISPA, there are quite a few other excellent security protocol analysis tools available
to a designer. The following is a list of some of the tools available:
1. CASPER4[16] was designed by Gavin Lowe at Oxford University Computing Laboratory,
Oxford University. It is an easy to use tool that uses text input in the form of a .spl file and
returns a textual output of attacks found by the tool. The input program is very easy to write
and understand. The tool compiles the input programs into CSP mode, which are then used as
input for FDR[17]. As FDR can only deal with finite states or instances, this tool is used for
only limited number of instances of the entities participating in the communication. Also, FDR
is software that requires a license. It is an infeasible solution if the tool is used just once for a
limited period of time.
2. ProVerif 5[18], is an excellent tool that like AVISPA uses the DY model to test the
security of protocol specified by the user. It is slightly more complicated to write input
programs in ProVerif as compared to AVISPA or CASPER. The tool tests security for the
same parameters as AVISPA. For example, it can test the protocol based upon secrecy,
4 http://www.cs.ox.ac.uk/gavin.lowe/Security/Casper/ 5 http://www.proverif.ens.fr
Investigation into Delegation in a Federated Environment August 27, 2012
43
authentication, strong secrecy, etc. The program to describe the protocol is slightly more
complex, and needs a thorough understanding of the protocol syntax before a user can describe
a protocol for ProVerif. A ProVerif output gives an excellently detailed output report. The
report describes in detail about the attack trace if there is any.
3. Another excellent tool that can be used for security analysis of protocols is Maude-
NPA6[19]. It is an excellent easy to use tool with a Graphical User Interface (GUI). The GUI
allows for easy loading and execution of security protocols. It also allows users to generate
attack trace tree. The user can then select the particular node of the attack tree to get further
details on the weakness and attack trace. The tools offers the designer to specify some
algebraic properties regarding entities and their relationships, to narrow down the possibilities
of the type of attack a designer is looking for. It is a good tool if a designer is looking for
specific attacks, but for general attack descriptions, it works similarly to any other tool.
All the tools offer good results in evaluating the security of protocols. Some of them have easy to
program protocol description like, AVISPA and CASPER. And some offer excellent graphical
description of the attack trace, for example, AVISPA and Maude-NPA. But none of the above tool
except AVISPA incorporate four different other tools as part of the analysis process. The four tools
of AVISPA will be discussed in section 3.2. These tools give AVISPA a much broader analysis
framework, as the validation on the protocol can be done on four different conditions of the
communication process. These conditions or states are defined within the tool, so during the
analysis process, they all consider the same input file but test for four separate conditions of the
protocol run. AVISPA also offers a free to use Web-Interface7, which allows users to simply
upload their protocols defined in HLPSL format and then test it for all the tools or select any tool
that the user wants to test the security of their protocol against. The web tool also gives users a
textual and visual attack trace for a protocol. Hence, simplicity of use of AVISPA and features
offered by the tool made it the tool of choice for the dissertation. In the following sections we will
look at AVISPA in much detail.
AVISPA requires that security protocol to be written in HLPSL (High-Level Protocol
Specification Language). AVISPA has been created by the joint efforts of Information Security
group at ETHZ (Zurich, Switzerland), Siemens AG (Munich, Germany), Artificial Intelligence
Laboratory at DIST (University of Genova, Genova, Italy), and the CASSIS group INRIA
Lorraine (LORIA, Nancy, France).
6 http://maude.cs.uiuc.edu/tools/Maude-‐NPA/ 7 http://www.avispa-‐project.org/web-‐interface/basic.php
Investigation into Delegation in a Federated Environment August 27, 2012
44
3.2 AVISPA architecture and HLPSL:
Figure 17: Architecture of AVISPA from[15]
The figure above shows the architecture of the AVISPA tool. The protocol written in
HLPSL is translated by the tool into an Intermediate Format. IF is a lower-level language, that is
fed directly to the back-end applications for analysis and validation. The four Back-end systems
used to analyze a protocol are, OFMC, AtSe, SATMC, and TA4SP.
3.2.1 On-the-fly Model-Checker (OFMC):
David basin et al. [20] and his team of three comprising of himself, Sebastian
M ̈odersheim, and Luca Vigan`o from the Department of Computer Science, ETH Zurich, Zurich,
Switzerland designed the OFMC tool. The motivation and purpose of the tool was to design a tool
that would check security protocols for infinite number of state spaces and consider the intruder
2 USER SECTION 9
2 User Section
This section describes the easiest way to use the AVISPA tool: to specify protocols in HLPSL,then to run the avispa script for analysing it.
Output Format (OF)
Intermediate Format (IF)
TranslatorHLPSL2IF
High!Level Protocol Specification Language (HLPSL)
Model!CheckerCL!based SAT!based
SATMC TA4SP
Tree Automata!based
OFMC
On!the!flyModel!Checker Attack Searcher Protocol Analyser
AtSe
avispa script file
Figure 1: Architecture of the AVISPA tool v.1.1
2.1 Specifying Protocols: HLPSL
Protocols to be studied by the AVISPA tool have to be specified in HLPSL (standing for HighLevel Protocols Specification Language), and written in a file with extension hlpsl.This language is based on roles: basic roles for representing each participant role, and compositionroles for representing scenarios of basic roles. Each role is independent from the others, gettingsome initial information by parameters, communicating with the other roles by channels.
In this section, we present the syntax of HLPSL and some guidelines for HLPSL beginners.
2.1.1 HLPSL Syntax The syntax of HLPSL is detailed in the following, using the standardBNF.Before describing the syntax, we list the lexical entities used in the grammar, keywords andexpressions being written as strings (i.e. arbitrary sequences of characters enclosed by two "characters).
AVISPA Tool v1.1 User Manual
Investigation into Delegation in a Federated Environment August 27, 2012
45
based upon Dolev-Yao model [21] that is not collecting specific values. Instead, the intruder could
be collecting and injecting any number of values during the protocol’s run. So the tool was
designed to consider a large number of data set, even infinite to be able to test the validity of a
security protocol.
3.2.2 CL based Attack Searcher (CL-Atse):
The tool CL-Atse[22] was conceived and designed by Mathieu Turuani, Lori-INRIA,
Nancy, France. The tool takes the input security protocol in its Intermediate Format and analyses
the protocol for all the entities involved in the communication. The tool models all the reachable
states of an entity and compares them with the states of other entities with a set of rules to
determine if an attack on the protocol is possible based upon the Dolev-Yao model [21].
3.2.3 SAT Based Model-Checker (SATMC):
SATMC[23] was conceived and designed by Alessandro Armando and Luca Compagna at
AI-Lab, DIST, University Of Genova, Genova, Italy. SATMC takes the input from the front-end in
the form of the Intermediate Format and analyzes the security of the protocol based upon finite
number of sessions. The consideration for the intruder that might have control over the sequence of
communication is the intruder based upon the Dolev-Yao model[21]. SATMC basically checks if
certain states could be reached within the protocol and analyze the security for those
communication path and states.
3.2.4 Tree Automata-based Protocol Analyzer (TA4SP):
A.Armando et al. [24] describes Tree Automata-based Protocol Analyzer (TA4SP) as a
tool that “approximates the intruder knowledge by using regular tree languages and rewriting”.
The tool can analyze the protocol for security flaws by considering only part of the communication
or for multiple sessions for a single protocol. This allows the tool to analyze the protocol for
security issues in the communication sequence irrespective if it’s a complete session or for
multiple sessions.
Investigation into Delegation in a Federated Environment August 27, 2012
46
3.3 HLPSL Syntax:
There are three major components of an HLPSL program. Basic roles, composed roles and
transitions. It is important to remember that while designing a protocol message sequence the user
needs to clear about the roles that each entity will play. Also, it is important to first create a
protocol communication sequence using A and B notation. Then translate it to the names of entities
that are participating in the communication.
3.3.1 Basic Roles:
Basic roles help define individual entity in a communication process. Basic roles allow the
programmer to define the local variables, initial values, known variables, constants, and transitions.
From[25] we consider the Wide Mouth Frog protocol[26]:
A -> S : {Kab}_Kas
S -> B : {Kab}_Kbs
It is a simple protocol that shows that A wants to set up a secure connection with B. A wants to
share a new session key with B. Both A and B have a shared secret key with the Server S. So, A
creates a new session key for B named Kab. A sends this key encrypted with her shared key with
S, i.e. Kas. S decrypts the message and re-encrypts with its shared secret key with B, i.e. Kbs. Then
S sends this message (new shared key) encrypted with its shared secret key Kbs to B. After
receiving the message, B decrypts the message and retrieves the new-shared session key, i.e. Kab.
Now, both A and B can communicate securely through their new shared key of Kab.
In the communication process, there are basically three basic entities, i.e. A, B and S. A (Alice), B
(Bob) and S (Server).
So each role is defined first considering its parameters, initial state and transitions. For example the
following figure will show how role of Alice (A) will be defined in HLPSL:
Investigation into Delegation in a Federated Environment August 27, 2012
47
Figure 18: Role definition obtained from[25]
This is a part of role definition of Alice. A, B, and S are the parameter that indicate the agents in
the protocol. Kas is the symmetric key that A and S shares. Important to note, as A does not have
any knowledge of Kbs it is not used as part of parameters in role definition. Also, as Kab hasn’t
been generated yet, it too will not be part of the parameters of A. Parameters are basically those
values that the entity has prior knowledge of. The channel being used in the communication is (dy)
channel from the Dolev-Yao[21] intruder model. A plays the role of Alice in the protocol; hence
we use the command played_by to inform the tool that role Alice is played by the agent A. Under
the played_by section we define the all the constants and variables associated with the particular
role. After values have been defined, we have to define the sequence of communication, known as
the transactions.
3.3.2 Transitions:
Transitions basically represent a set of send and receive message. There can be alternate
activities as part of the transition message like, creation of new variable, or start of the transition or
inclusion of condition on secrecy or authentication of particular variable in a transition. Transition
may start with a start() message or some other trigger. A trigger could be any pre-condition that
has been satisfied before the start of the communication.
An example of a Transition for our example has been taken from [25] to explain transitions much
better.
Investigation into Delegation in a Federated Environment August 27, 2012
48
Figure 19: Transition for Server (S) obtained from[25]
Step1 is declared in the transaction indicating that it is first step to be performed for that particular
role. State is initialized during parameter and variable declaration. The RCV({Kab’}_Kas) is the
trigger for the transactions. Within step1, the transaction jumps from State = 0 to State’:=2. It is
important to note that the State will not change until the start of the next transition. The step1 only
indicates that the next value for State variable will be 2. The transition will go on to the next step
after it has completed all the actions to be performed in that particular step.
3.3.3 Composed Roles:
We have seen how basic roles are declared. But the purpose of the protocol is to make
these roles act in parallel or work together. So we need to create roles that present the instance of
all the roles working in parallel. This is where composed roles come in to play. They combine
these roles together to form a session. Session is basically the role where all the basic roles are
usually working in parallel. Figure 19 will give a good overview of how a session role looks like:
Investigation into Delegation in a Federated Environment August 27, 2012
49
Figure 20: Role session obtained from [25]
The role session declares the parameters like that in the basic roles. The difference being it
incorporates those values as parameters that the basic roles have declared within their parameters
values. The channel (dy) is defined local in the case of a session. Channels defined within the role
session are all he channels that are used within a single session of a protocol. Instead of transitions,
the role sessions declare composition. The channel (dy) defined in the role session is basically the
intruder model introduced by Dolev-Yao[21] wherein, the intruder has all the knowledge of the
network and has complete control over the network.
The top most level role declared in HLPSL is the environment role. It is within this role that the
protocol designer declares the knowledge an intruder have for that particular protocol. Like the role
session, environment role has compositions instead of transitions. In case of environment, the
composition is of the different possible sessions with intruder playing the role of any of the entities
that are part of the protocol. The following figure will give an example of how we declare the role
environment:
Investigation into Delegation in a Federated Environment August 27, 2012
50
Figure 21: Declaration of role environment obtained from[25]
3.4 Basic Overview of Dolev-Yao Model:
The Dolev and Yao model or the DY-model[21] was designed by Danny Dolev and Andrew
C. Yao in 1983 to design a model that would analyze and test the security of Public key protocols.
The model has been widely accepted as a baseline to test the security of public key protocols.
Though there have been some reservations on the effectiveness of the model due to the
assumptions made in the model. It has been found to be an effective baseline for security protocols
designer to test their protocols against.
As seen in our previous discussion on AVISPA, all the tools designed to test validity of a protocol
use the DY intruder as the adversary to test the security and validity of a security protocol.
Investigation into Delegation in a Federated Environment August 27, 2012
51
Unlike previous models, the DY model considers the presence of an active adversary, rather than a
passive adversary. A passive adversary is an entity that listens to messages communicated across
without interfering or manipulating the communication. Whereas, an active adversary is an entity
that can steal a message, break, re-route, initiate a communication and even abruptly end it. The
model demonstrates the security of two different types of security protocols that implement public
key security systems, i.e., cascading protocols and Name-Stamp protocols.
1. Cascading Protocols: These protocols use straightforward implementation of encryption
and decryption of a message. These protocols can also have multiple layers of encryption or
decryption as part of the protocol. The Wide Mouth Frog Protocol[26] is a simple example of
cascading protocol.
2. Name-Stamp Protocols: As the name suggests, are protocols that allow entities part of the
communication, to include some type of identifier as part of the message in the protocol.
Kerberos protocol[27] is a type of Name-Stamp protocol.
The model makes the following assumptions about the participants, adversary and the type of
protocols described under the model:
1. The participants for example A and B are two parties that want to share a secret message.
A, B are stateless entities that are not allowed to have any information relating to previous
communications that they might have had with any entity. They can only start a
communication based upon the current message that they hold and not based upon some past
data.
2. The adversary can participate in any communication and send can any message to any
party that is part of the network. The adversary can initiate or stop a communication as and
when it likes. The adversary is all-powerful.
3. It is assumed that the information about an entity’s name and encryption key (Ex) is
publicly available. The Decryption key, lets say Dx, is kept secure.
4. The adversary is not restricted to just a single run of a protocol with limited number of
participants. The adversary can initiate multiple runs of a protocol with different participants,
be part of n-number of protocol runs and study the actions of participants.
5. The security of a message ‘M’ is the secrecy goal of a protocol. If the message is exposed
within its communications part to an intruder, the protocol is presumed to be insecure.
Investigation into Delegation in a Federated Environment August 27, 2012
52
Let us consider an example of how insecure protocols can be from an example given in [21],
Original Sequence:
A -> B: {M}_Kb
B -> A: {M}_Ka
Attack sequence:
Z intercepts the first message of the protocol.
A -> Z: {M}_Kb %Message intercepted
Z -> B: {M}_Kb %Message replayed
B -> Z: {M}_Kz %Secret Message derived
Z -> A: {M}_Ka %Protocol continued to avoid detection
The method used to describe protocols and attack in DY-model is explained as follows:
1. A sender S and receiver R are participants of the communication. They want to share a
secret message M between them. The receiver is willing to listen to any sender.
2. Each step of the protocol is mapped as function with arguments and output for the function
as the last received message and sent message respectively. An entity X can choose any
number of functions from a set of functions Fx available to the entity to progress with each
step of the protocol.
3. An entity X can perform Dx (Decryption with its key), Ey (Encryption with Y’s public
key), depending upon the protocol used and the use of identifiers. An entity X can either delete
an identifier or append an identifier.
4. If two parties are involved in the protocol then the protocol can be described as a sequence
of strings f[1], f[2], f[3] ……, f[k]. Where, f[2i+1] represents the actions of a sender and f[2i]
is the actions of the receiver. For example, from our previous example the first step of the
protocol, i.e., A ->B: {M}_Kb can be described as the function of type f[2i+1] and second
step, B -> A: {M}_Ka, can be described as function of type f[2i].
Investigation into Delegation in a Federated Environment August 27, 2012
53
5. The attacker or an intruder has full control over the network and can initiate or be part of
any communication within the network. The attacker has the power to inject messages within
the network to break the security of the protocol. The attacker has all the publicly available
information. It also has the power to append and delete identifiers from the end of the
messages. It also has its own decryption key that it can use to decrypt messages encrypted with
it’s public key.
6. The goal of the attacker is to break the security of the protocol and extract the secret
message M. The attacker can also compromise the security, by creating a sequence of steps (or
functions) to nullify the effect of encryption and decryption performed in a protocol between
two parties having an honest communication.
For further reading and mathematical proofs, readers are suggested to reference [21].
Investigation into Delegation in a Federated Environment August 27, 2012
54
4 Problem Analysis
4.1 Introduction:
Hidehato Gomi et al [3] in his paper proposed a not so unique but quite often overlooked
fact about identity delegation. Gomi in his paper presents the scenario and presents a solution for
dynamic identity delegation within a federated environment. It was this paper and scenario
discussed in it, that motivated me to consider this paper as the cornerstone of my dissertation. This
chapter will revolve around the review and analysis of the idea presented by Gomi for dynamic
identity delegation. The problem considered is basically the problem of indirect delegation. Where,
a user delegates it to a delegatee and the delegatee then passes on the task of delegation to a service
provider. That then may act as a delegatee to perform some task on users information retrieved
from the Identity provider.
4.2 Introduction to Scenario:
Investigation into Delegation in a Federated Environment August 27, 2012
55
Figure 22: Motivating Scenario obtained from[4]
Bob and Alice is a married couple. They both plan to get their finances in order so that they
can repay their loans, reduce their taxes, reduce their expenditure and plan for a better future. Both
Alice and Bob work for different organizations. Alice comes across Financial Planning Center
(FPC) that provides financial consultancy and services. For FPC to offer their services to Alice,
they would need financial records of both her and her husband, Bob. Alice can provide her
financial and personal information easily as she is in charge of it and has the authority over that
information. But Alice does not have access to Bob’s financial and personal information. An
Internet Service Provider (ISP) safely stores Bob’s personal and financial information. So Alice
needs to send a request to Bob, asking him to authorize access to Bob’s pension records stored at
the ISP for FPC to have access. In the scenario, as Bob and Alice are married, we assume that there
is some trust between the two. As Alice does not have an account at the ISP, Bob needs to
authenticate himself and inform the ISP that who all will be accessing his information and what
information. The request has to go through the ISP for verification purposes as it has its own
access control policies that it has to abide by. Hence, ISP will have to monitor any request coming
from any third party. The ISP will only grant a request when Bob giving her a certain privilege
level has authorized Alice.
4.3 Conceptual model:
There are primarily four entities participating in the communication process.
Delegation
Financial Planning
Request
Bob (husband)
Internet Service Provider
(ISP)
Financial Planning Center
(FPC)
Alice (wife)
Records
Bob’s
Pension
Records
Pension Record
Request
Stores Pension Records
Figure 1. Motivating scenario.
proposed in this paper. However, this work differs in that itfocuses on a method and its system design for transferringthe information on delegation authorization beyond securitydomain boundaries from a practical viewpoint.
Another line of research related to delegation is fine-grained access control models [11], [12]. While that researchfocused on conceptual access control models, this workfocuses more on key technologies for dynamical accesscontrol and permission assignment from the viewpoint ofdesign and implementation.
Some emerging technical specifications provide schemesfor exchanging identity information using a token of shortlengths of string, which is relevant to the work proposed inthis paper. SAML [13] specifies a scheme for exchangingidentity information using an artifact, which is a referenceto an assertion containing the information. However, SAMLdoes not deal with access control schemes and the arti-facts are not specifically designed for identity delegation.OAuth [14] provides a method for delegation from user toapplication by means of an access token. In contrast, thiswork focuses on a more generic access model and its designframework for user-to-user identity delegation, which areoutside the scope of OAuth.
III. MOTIVATING SCENARIO
This section describes a scenario that illustrates the mo-tivation behind this work (Fig. 1).
Bob and Alice are a married couple who are workingfor different companies. They are interested in financialplanning in order to reduce their income taxes, repay theirloans, and prepare for their future. Alice considers signingup for a financial planning service publicized by the Finan-cial Planning Center (FPC) on the Internet. Such a servicewould require her to display her and Bob’s current finan-cial status. Bob stores his pension records on his accountmanaged by the Internet Service Provider (ISP) to view theinformation privately. The financial planning service Alice isconsidering requires both Bob’s and Alice’s pension recordsand information about their loans or mortgage in order tooffer an ideal plan for their future lives.
In this case, Bob’s pension records at the ISP need tobe provided to the FPC in a secure and privacy-preserving
manner because the FPC can only provide Alice with theservice at its site. If we assume that the FPC requests accessto Bob’s pension records managed by the ISP, the access re-quest needs to be identified by the ISP in order to determinewhich entity, and what kind of data, is attempting to accessthe ISP in order to ensure an appropriate access control forthe request. In addition, because Alice is the recipient ofthe financial service using Bob’s pension records—in otherwords, one person is accessing and using another person’sdata—Alice’s access needs to be authorized by Bob, eventhough they are married, before the ISP will accept herrequest for his data via the FPC. In order to do so, Aliceneeds to be provided with an appropriate privilege to accessBob’s pension records and receive the service using theinformation at the FPC.
IV. CONCEPTUAL MODEL
This section describes the model for supporting delegationin a distributed environment proposed in this paper.
A. System Entities and FunctionsThe roles of the involved entities are as follows.A user is a person who accesses restricted resources
provided by other entities. A user has his or her intimateusers’ contact addresses (e.g., account identifiers or e-mailaddresses) through which they can interact with each other.In this model, there are two types of users: delegatorsand delegatees. A delegator is a user that has privilegesto access his or her identity information and to delegate theprivileges. A delegatee is a user that is provided privilegesby a delegator to access the delegator’s identity information.A delegator and a delegatee have a prior trust relationshipand share their contact addresses.
A service provider (SP) is an entity that provides accessto restricted resources managed by its site with authorizedusers. An SP supports the delegation of resources containingpersonal information. This means that an SP may grant adelegatee’s access to a delegator’s resource on the basis ofits security policies if an SP verifies the appropriateness ofthe delegated access request by the delegatee.
An identity provider (IdP) is an authentication authoritythat authenticates users by means of particular authenticationmethods and produces an assertion stipulating the comple-tion of the authentication event or the correctness of personalattribute information. In this model, an IdP has an additionaldelegation mediating (DM) capability that supervises thedelegation authorization of a delegator to a delegatee andconveys its information to a corresponding SP.
In this paper, it is assumed that an SP and an IdPare located in different security domains in a distributedenvironment. It is also assumed that they are in a trustrelationship and share their unique identifiers with the otherentity. They have the basic functionalities of identity federa-tion, by which a user’s set of identity information managed
613
Investigation into Delegation in a Federated Environment August 27, 2012
56
4.3.1 Entities:
4.3.1.1 Delegator (Bob):
Delegator is the entity that delegates a task to a delegatee. In Gomi’s, Bob plays the role
of a Delegator. Bob authorizes Alice to grant the FPC access to Bob’s pension records stored at the
ISP. A delegator in the scenario can be identified using a username, email-ID, unique number etc.
In the scenario, the term DelegatorID is used to identify the delegator.
4.3.1.2 Delegatee (Alice):
Delegatee is the entity that receives the delegation token. In Gomi’s scenario, Alice plays
the role of the Delegatee. Alice receives the Delegation token and passes it on to the FPC, and in
return it receives access to services offered by the FPC. In the scenario, the delegatee is identified
by the term DelegateeID.
4.3.1.3 Service Provider (FPC):
Service provider is the entity that provides the services to another entity. In Gomi’s
scenario, Financial Planning Center (FPC) plays the role of the service provider. The FPC can only
offer services at its end. Hence, Alice needs to forward the delegation token to the FPC allowing it
to have access to Bob’s pension records at the ISP. In return, the SP will provide financial planning
services requested by Alice. In the scenario, SP is identified by the term spID.
4.3.1.4 Identity Provider (ISP):
Identity Provider is the entity is responsible for the creation and authorization of
delegation token. In Gomi’s scenario, ISP plays the role of the Identity Provider (IdP). In the
scenario, Bob has to authenticate himself to the ISP and ask for a delegation request for Alice and
FPC, to allow FPC access to Bob’s pension records stored at the ISP. ISP is responsible for
monitoring and controlling access to Bob’s pension records by the FPC. ISP plays the dual role of
creating assertions and also responsible for delegation mediation.
Investigation into Delegation in a Federated Environment August 27, 2012
57
4.3.2 Working:
To explain the working of Gomi’s model I have divide the working section into two parts.
In the first part, we will look into the communication between the delegator and the IdP. This part
will show the delegator requesting for a delegation token from the IdP after it receives a request
from the delegatee access to delegator’s personal information. In the second part, we will look into
the communication between the delegatee, SP and IdP. This step will occur once the delegation has
been passed on from delegator to the delegatee.
4.3.2.1 Part1:
The part1 of the working of Gomi’s model will give a review of all the processes that
take place during the communication between the delegator and the IdP. The communication is
initiated by the request for access, from the delegatee to the delegator as part of the initial request.
Figure 23: Delegation Authorization Mediation obtained from[4]
1. Delegator receives a request from the delegatee.
2. Delegator authorizes himself first at the IdP. The authorization could be a simple username
password or a two-factor authentication mechanism. It depends on the IdP’s local policy.
Delegator
Delegated Access
Request
AssertionPermissions
Association
Access control Assignment
Assignment
Issuance
Assertion
Delegation
Access control
Access control
Delegation
Authorization
Mediation
permission
Delegation
Delegatee
Delegation Authorization
Mediation Request
DAT
constraint
DAT
DAT
Assignment
IdP
SP
DATAssertion Request
permission
permissionPermissions
Delegation Authorization
Mediation Response
Delegated Access
Response
Figure 2. Data and access management model.
by each entity is linked with each other. When an IdPauthenticates a delegator, the SP that federates his or heridentity information with the IdP indirectly authenticates himor her by receiving from the IdP the information about anauthentication result regarding the delegator using identityfederation mechanisms.
If an SP does not confirm the identity of a user whenit receives the user’s access request, the SP requests anauthentication assertion on the user from an IdP in afederated relationship with the SP to make a decision forauthorizing the above request appropriately. If an SP doesnot confirm the identity of a delegatee but knows onlylimited information about the delegatee such as his or heridentifier or contact address, the SP can grant the delegatee’saccess depending on the risk involved with the requestedoperation.
This model does not consider a chain of delegations inwhich multiple delegations successively occur from delega-tor to delegatee but rather focuses on the examination ofdata and access management for a delegation involving adelegator, a delegatee, an IdP, and an SP.
B. Data and Access Management Approach
This work proposes introducing a delegation access to-ken (DAT), which is a randomized string representing areference to a delegated permission to be transferred by adelegator to a delegatee based on the above assumptions.In this proposed framework, there are two phases in theoverall procedure for completing identity delegation. Here,each phase is briefly introduced from the viewpoint of dataand access management, which is depicted in Fig. 2. Thesolid and dotted lines represent data flows and relationsbetween entities or data, respectively.Phase 1 (Delegation Authorization Mediation). An IdPaccepts a delegator’s delegation authorization mediationrequest and issues to the delegator a DAT, which is then
5. DlgAuthZMedResponse (OK, DAT/NG)
1. DlgAuthZMedRequest
(delegateeID, spID, attrTypes)
Delegator
2. Access Control
3. DAT, Authorization
Information Generation
IdP
4. Permission Assignment
Figure 3. Delegation authorization mediation procedure.
given to a delegatee. This interaction is performed betweenthe delegator and the IdP.Phase 2 (Delegation Service Provisioning). A delegateewho has a DAT obtained from a delegator sends a delegatedaccess request containing the DAT for a delegation serviceof an SP. The SP retrieves an assertion from an IdP to makea decision on the above delegatee’s request.
The following sections describe the details of the proce-dure in each phase.
V. DELEGATION AUTHORIZATION MEDIATION
This section describes the procedure for mediating dele-gation authorization from a delegator to a delegatee at anIdP. An interaction flow of exchanging a DAT between adelegator and an IdP is shown in Fig. 3. Here, it is assumedthat the delegator has authenticated at the IdP. Next, theprotocol and each operation will be described in order.
A. Delegation Authorization Mediation ProtocolA delegator authenticated by an IdP requests delegation
to a delegatee at the IdP (step 1 in Fig. 3). The requestDlgAuthZMedRequest consists of a triple !delegateeID,spID, attrTypes" as the core elements in this context:
• delegateeID: This element indicates the identifier ofa delegatee to whom a delegator wishes to delegate aprivilege.
• spID: This is the identifier of an SP at which thedelegator would like the delegatee to receive a serviceusing the delegator’s personal information. The dele-gator obtains spID through some GUI shown by theIdP or contained in the SP’s request that triggered thismessage.
• attrTypes: An attrType is a type of personal infor-mation attribute of the delegator that he or she wouldlike to provide to the SP.
When the IdP grants the above request (step 2 in Fig. 3),it generates and registers a DAT that represents an accessticket for the specified delegatee performing the delegation(step 3 in Fig. 3), assigns a permission for the SP to obtainthe above information about the delegator (step 4 in Fig. 3),and returns a response, called DlgAuthZMedResponse, whichcontains an OK indication and the generated DAT if theabove request is successful and an NG indication if it endsin failure (step 5 in Fig. 3). Next, the details of the IdPprocedure in steps 2–4 in Fig. 3 are described.
614
Investigation into Delegation in a Federated Environment August 27, 2012
58
3. After the authentication process, the delegator sends the IdP a message
DigAuthZMedRequest that contains the delegateeID, spID and attrTypes. DelegateeID is a
basic identifier used to identify a particular delegatee. In this case, Alice. spID is used as an
identifier for the service provider, i.e. FPC. ‘attrTypes’ is used to identify the personal
information stored at the IdP that the user wants to grant access to.
4. After IdP receives the message containing the information, it performs some access
control on the user’s request based upon a user’s privilege levels and on IdP’s local policies. It
performs this action to check if a user should be allowed to delegate his personal information.
But, as the information at the IdP is personal to the delegator, it has most of the control over
the information. But the IdP is bound by its local policies and has to perform some checks
before allowing access.
5. The IdP then generates a token DAT. Before the generation of DAT, the IdP generates a
unique string authzID based upon the user’s authorization. The authzID is concatenated with
the IdP’s private key and then hashed to form a DAT. DAT = Hash (Kidp || authzID)
6. The IdP at its end creates a Delegation Authorization Assertion (DAA). DAA is stored
locally at the identity provider. The DAA contains seven different values to identify the
assertion as a mediating authority. DelegatorID, DelegateeID, spID, issuer (i.e. IdP),
issuedTime (Time of issuance of the DAA), validPeriod (Validity time of the DAA), attributes
(Delegators personal information). DAA is later used by the IdP to confirm to the SP, that the
delegator grants permission to the delegatee to use delegator’s personal information to access
services at the SP.
7. The IdP just plays the role of a mediation party in this scenario so it does not authorize the
delegation. It just helps the delegator encode his delegation for the delegatee, to be passed on
to the SP. Thus, it performs authorization mediation.
8. The DAT created by the IdP is the token that represents the particular delegation request.
9. After all the previous steps are done, IdP can sends back an OK if the request has passed
through all the conditions. Otherwise, it sends a NG to the delegator indicating a failure in the
request.
Investigation into Delegation in a Federated Environment August 27, 2012
59
4.3.2.2 Part 2:
In Part 2 of Gomi’s conceptual model, we will consider the communication between the
delegatee, SP and the IdP. The communication takes place once the delegatee has received the
DAT from the delegator. The following diagram will give and overview of the communication
procedure.
Figure 24: Delegated access interaction obtained from [4]
1. The delegatee sends a message to the SP containing three values. Opr is operation that the
delegatee intends to perform at the SP. DAT obtained from the delegator and the identity of the
service provided received from the delegator represented as idpID.
2. Once SP receives the request it extracts the DAT from the request and concatenates it with
its spID and forwards it to the IdP as an assertion request.
3. The assertion request generated by the SP is known as the DAA request.
4. Once the IdP receives the DAA assertion request it calculates the assertion key. Assertion
key is calculated by the following formula;
daaKey = Hash (DAT || spID)
The daaKey is then used to find the particular assertion saved at the IdP.
4. Assertion Response
(OK,Assertion/NG)
2. Assertion Request (DAT, spID)
3. Access
Control
SP IdPDelegatee
1. Delegated Access Request
(opr, DAT, idpID)
6. Delegated Access Response5. Access Control
Figure 4. Delegated access interactions.
is described. The interactions among the three entities areshown in Fig. 4. It is assumed that the delegatee alreadyholds a DAT that has been securely provided by a delegator.
A. Delegated Access ProtocolA delegated access request and response is an interaction
between a delegatee and an SP (steps 1 and 6 in Fig. 4) inthe application level resulting in the delegatee performingthe delegation authorized by his or her delegator. The requestconsists of a triple !opr, DAT, idpID" as core elements:
• opr: The type of operation that the delegatee requeststo execute at the SP.
• DAT: The DAT that is given by the delegator to the del-egatee needed to access the delegated service providedby the SP.
• idpID: The identifier of an IdP that the delegatee spec-ifies based on the knowledge given by the delegator.
B. Delegation Authorization Assertion ProtocolA DAA protocol specifies the communication protocol
for exchanging a DAA between an SP and an IdP (steps 2and 4 in Fig. 4). When an SP receives a delegated accessrequest from a delegatee, it produces a DAA request usingthe information contained in the above request. The DAArequest includes a pair !DAT, spID":
• DAT: The DAT that the SP receives from a delegatee ina delegated access request.
• spID: The SP’s identifier to be identified by the IdP.
C. Access Control for Assertion IssuanceWhen an IdP receives a DAA request from an SP, the IdP
executes the access control procedure in which it decides togrant or deny issuing the requested DAA to the SP (step 3in Fig. 4). The main procedure is the verification of thereceived DAT presented in the DAA request. Algorithm 3shows the procedure of an IdP for verifying a received DAT.
First, the IdP receives DAA request req from an SP(step 1). Since this request needs to include a DAT and theidentifier of an SP, the IdP obtains and stores the valuesin variables dat for DAT and spID for the SP’s identifierby calling functions getDAT(·) and getSPID(·), respectively(steps 2 and 3). Because DAT and spID are both mandatoryin this protocol, the algorithm returns false, indicating thatthe access is denied if either element is missing or the SPis not trusted (steps 4-6). Then, the IdP generates a DAA
Algorithm 3 DAT Verification (at IdP)Require: IdP authenticates SP sending DAA request1: req ! receiveDAARequest()2: dat! getDAT(req)3: spID! getSPID(req)4: if dat = null or spID = null or trusted(spID) = false, then5: return false6: end if7: daaKey ! generateDAAKey(dat, spID)8: result! assertions.containsKey(daaKey)9: return result
search key by calling function generateDAAKey(·), whichis the same one used for generating a key to store a DAA inAlg. 1. The difference in this algorithm is that the argumentvalues given to the function as input are obtained from thereceived DAA request (step 7). Then, the IdP gets a booleanindication of whether there is an assertion correspondingto the generated search key daaKey in the assertion DBby calling function assertions.containsKey(·) (step 8).The return value result contains true if the assertion isappropriately stored and is false otherwise (step 9). If theabove verification is successful, a DAA is obtained bysearching in the assertion DB using the verified key daaKey.
Since key daaKey is originally generated using a spIDintended by a delegator, the above procedure securely returnsfalse if a unintended SP maliciously attempts to requesta DAA presenting a DAT obtained by some means, evenif the SP is regarded as trusted by the IdP. Hence, thisscheme enables the limited distribution of DAA to only theauthorized SP at which a delegator grants identity delegationand reflects the delegator’s preference in a user-centricfashion how to handle his or her identity information.
Please note that the above procedure for verifying a DATdoes not use extra memory or disk space for managing theinformation on the association between the DAT and itscorresponding DAA. In addition, the procedure is efficientlylimited to only the hash calculation.
Although the above procedure describes only the DATverification, the overall procedure for access control can bestrengthened by adding other constraints to the permissionthat is assigned in the phase 1. For example, more bodyrules can be added into the access control policy shown inSec. V-F as constraints for providing the permission.
Access control for delegated access at an SP after receiv-ing a DAA is also a topic, but it is omitted in this paper forlack of space.
VII. DESIGN AND IMPLEMENTATION
This section describes a design example of implementingthe proposed framework.
A. System Architecture
Figure 5 shows an example of system architecture con-sisting of three entities (a user, an IdP, and an SP), and
617
Investigation into Delegation in a Federated Environment August 27, 2012
60
5. If the IdP finds the particular assertion associated with the key and confirming that the
particular assertion hasn’t been granted before or is being currently used, grants the SP, the
DAA. Otherwise, rejects the request.
6. It’s this assertion that allows the SP to have access to delegator personal information
stored at the IdP.
7. After receiving the DAA, the SP performs its own access control procedure where it may
or may not ask the delegatee to authenticate herself before being allowed the service.
8. Once the SP has performed its access control procedures it allows the delegatee to have
access to the services being offered by the SP.
4.4 Analysis:
4.4.1 Introduction:
Gomi’s paper highlights a form of delegation that hasn’t really been looked into. It
highlights a scenario that is common both domestically and also in businesses. Gomi manages to
produce a very well thought of conceptual model that would ensure dynamic delegation in a
federated environment.
4.4.2 Advantages:
1. Dynamic creation of assertions.
2. Concept of DAT, that is just a randomized string that refers to a delegated permission.
DAT being a randomized string does not contain any user sensitive information. This allows
parties to communicate DAT across even open channels, without the fear of exposing any
sensitive information.
3. The concept of creation of DAA allows the SP to confirm through the IdP that a genuine
delegation request has been initiated by the delegator that grants access to his personal
information/privileges to the delegatee to use it for a service at the SP.
Investigation into Delegation in a Federated Environment August 27, 2012
61
4. The creation of a unique random string identifying a user’s authorization, i.e. authzID
allows the IdP to distinguish requests from different users. It also allows the IdP to identify
different requests from the same user.
5. The conceptual models emphasis on access control policy of entities like the IdP and SP,
determining their actions on whether or not to grant access allows the entities to have more
control. It allows the IdP to have more control on whom, how, what and when is someone
trying to access some information at the IdP. Similarly, allowing SP to determine granting or
rejecting a request based upon its own security policies allows the SP to restrict malicious use
of its services and allows it to authenticate the authenticity of a request. For example, if there is
a repeated request by a delegatee to use some information of the delegator beyond the privilege
level of the delegatee, then, local access control policies allow both IdP and SP to flag such an
event.
6. The dynamic nature of the model allows the SP to allow access to its services to the
delegatee without the need to authenticate a delegatee. Though, this could also be a serious
security issue.
7. The model allows two entities in different security domains to share assertions without any
intermediary services. This too adds to the dynamic nature of the model. This allows the
entities to share information in a secure way without having to conform to some security
specifications set by either of the entity.
8. The one-to-one relation between DAT and the DAA allows the IdP to reject any request if
there are any discrepancies in the values. For example, if an intruder tries to change the value
of DAT and pass it on to the IdP as the service provider. IdP will reject such a DAT, as it’s the
product of DAT and spID that the IdP uses a key to generate a daaKey that will be used to find
the particular assertion in the assertion database. But the IdP creates a daaKey when the
delegator initiated the request for delegation. Thus, if the value of key generated by the IdP
does not match the value of the key generated after receiving the DAA request from the SP, the
IdP can term such a request for assertion as a failure.
9. The length of DAT being small as compared to the DAA, allows entities as part of the
communication to share the DAT easily without consuming too much memory and bandwidth.
It also allows entities to use their mobile client to propagate or receive requests for delegation.
Investigation into Delegation in a Federated Environment August 27, 2012
62
10. Concept of assertion not being passed around and only shared in the final stage of the
communication offers security over leak of metadata that can be collected by a passive intruder
from the requests. This metadata collected over a period of time could help an intruder create a
profile about a user. This profile can then be used to mount phishing attacks on the user by
offering services similar to the service offered by a genuine SP.
The conceptual delegation model designed and conceived by Gomi gives an excellent perspective
and solution to Identity delegation in a federated environment. The use of small tokens referring to
an assertion allows for creating a dynamic identity delegation environment. Making entities
responsible for their own security policies offers freedom and flexibility in how the delegation
process is performed and assertions are shared. But, the model does have quite a few drawbacks
that may affect the security of the communication.
Before we get into the ‘cons’ section of Gomi’s model. We will demonstrate some of the possible
attacks on protocol designed based on Gomi’s specifications.
4.4.3 Attack Scenarios:
4.4.3.1 Bob to Alice Scenario:
The lack of clarity on security in the communication of DAT between the two entities,
i.e. Alice and Bob is evident in the model. The author does give two ideas for solving the issue, but
it still does not ensure that the DAT might not be stolen from a malicious intruder, and replayed as
a SP at later stages of the protocol. The two ideas presented by the author are; if the delegatee has
an account with the IdP, then IdP can store the DAT at the delegatee’s secure account. The second
solution being, secure communication of DAT between the two entities.
The following scenario considers two entities and a trusted server that both entities share secret
keys with. The entities want to set up a secure session prior to exchanging DAT. They share a new
secret key with the help of a server.
A -> S: {Kab}_Kas
S -> B: {Kab}_Kbs
When we analyzed the security of the protocol using AVISPA, these were the results:
The OFMC tool gives the following attack:
Investigation into Delegation in a Federated Environment August 27, 2012
63
Figure 25: MSC Attack Trace from OFMC tool
The attack takes place by the intruder (‘i’) starting a communication with A and stealing, then
forwarding the message received to s (secure server) pretending to be A. The server responds back
with a message encrypted with the public key of the intruder. Intruder breaks the encryption and
extracts the secret session key. Now, the intruder can snoop upon any further communication.
Investigation into Delegation in a Federated Environment August 27, 2012
64
The CL-Atse tool shows a similar attack:
Figure 26: MSC attack trace from CL-Atse tool
4.4.3.2 Attack on delegated access interaction:
Next, I considered the message flow/protocol considered by the author for DAT sharing
between the delegatee, SP and the IdP. In the scenario following assumptions are made;
1. DAT is considered as just a message that is to be passed securely across the channel.
2. The protocol uses arbitrary values to refer to SP and IdP.
3. Authentication of a delegatee is based upon the value of the DAT received and sent by the
delegatee. If the DAT received by the IdP at the end of communication is not the same as
original, then it can reject a request and return a request failure command to the SP.
4. Local access control policies are ignored in this scenario, as they cannot be designed on
the protocol.
5. Also, we assume that DAT has been transferred directly by the IdP to the SP through some
means.
The protocol is as follows:
IDP -> A: ({DAT}_Ka)
Investigation into Delegation in a Federated Environment August 27, 2012
65
A -> SP: ({opr.DAT.IdpID}_Ksp)
SP -> IDP: ({DAT.spID}_Kidp)
Following will give and overview of the results obtained from validating the security features of
the protocol on AVISPA:
Figure 27: MSC attack trace from OFMC
This attack highlights the weakness of the communication between A and IDP. This attack can be
extended to assume that the intruder is also a malicious SP. The intruder can recover the DAT from
this stage and then replay it at a later stage as the SP, but cutting off the presence of a delegatee.
This will enable the malicious SP to have un-limited and un-restricted access to a delegator’s
personal information without the delegatee having any means to know of the attack.
A similar result is obtained from analyzing the protocol in CL-Atse. In this case too, an intruder is
able to authenticate itself as a genuine participant of the communication by clearing the
authentication procedure.
Investigation into Delegation in a Federated Environment August 27, 2012
66
Figure 28: MSC attack trace from CL-Atse
4.4.3.3 Attacks on Improved delegated access interaction:
In the next step, some changes were made to improve the security of the author’s original
conceptual delegated access interaction. These basic changes have been included to improve the
security of the protocol without affecting the integrity of the original protocol. These
changes/assumptions were made to test the validity of the protocol by adding some layers of
security.
The following assumptions were made when making improvements in the protocol:
1. We assume that a resource is the link to the actual information that is to be obtained by the
SP. It could also be interpreted as the actual assertion.
2. The DAT initially sent to the delegatee (Alice) is encrypted with the private-key of the
IDP. This is done to avoid anyone in the middle of the transaction getting access to the DAT.
Investigation into Delegation in a Federated Environment August 27, 2012
67
3. The encryption of DAT with IDP’s private key is done to add a layer of security over the
sharing of DAT. But it does not eliminate the chances of intruder to replay the encrypted DAT
itself.
4. As local access control policies cannot be included as part of the protocol on AVISPA,
they are ignored.
5. We are trying to ensure the secrecy of the resource that is to be shared between the entities
and also, a delegatee is authenticated if it is able to produce the same DAT that was issues to
the delegatee.
6. We also assume that the DAT has been hashed to add another level of security.
IDP -> A: ({{DAT}_inv(Kidp)}_Ka)
SP -> IDP: ({C.SP.URI.{DAT}_inv(Kidp).IDP}_Kidp)
IDP -> SP: ({Resource(URI)}_Ksp)
SP -> A: ({Resource(URI)_Ka)
The following were the results when the protocol was analyzed in AVISPA:
Figure 29: MSC attack trace from CL-Atse
The attack above demonstrates the weakness in the communication between the SP and the IDP.
Hence, this can be assumed as an attack on the SP. The author has documented the attack of a
malicious SP possibly impersonating a genuine SP. With the protocol above and the attack, we
Investigation into Delegation in a Federated Environment August 27, 2012
68
have demonstrated the weakness of the SP in the protocol. The attack highlights the weakness in
the authentication process.
4.4.3.4 Weakness of the IDP:
In the previous scenarios we have covered the weakness in communication between Bob
and Alice. How an intruder can impersonate either of the two entities to compromise the secret
shared between them. We have also looked at the weakness at Alice’s end by examining the
communication that may take place between IDP and Alice. The previous argument can be
ignored, as the sending of DAT to Alice through Bob has already proven insecure. Hence, it is safe
to presume that an intruder can perform a man-in-the-middle attack first between Alice and Bob,
then use the information collected to impersonate a genuine SP. We have also seen how an intruder
can perform an attack on the authentication mechanism in place, and extract any information from
the communication between Alice and SP, and between SP and the IDP. The information collected
passively by an intruder can then be used to impersonate a genuine SP.
The following scenario that is considered is to examine the security of the IDP. In most of the
previous scenarios it is assumed that the intruder does not play the role of the IDP. In this section
we present a theoretical possibility of a malicious IDP.
1. An IDP issues genuine request token but has been compromised and is stealing
information regularly from SP’s and drawing information out regularly, from the information
saved by client on the IDP.
2. A malicious IDP in such a scenario can analyze the information flow first hand as part of
the communication process. The IDP can analyze the communication flow very closely and
understand its working. In a way, an IDP is compromising the integrity of the communication
flow. A malicious IDP can use the information collected over time to pinpoint the weakness in
the protocol. This would then allow the IDP to attack the weakest link in the protocol. An IDP
by being an integral part of the communication can attack the weakest link in lesser time and
with reduced processing requirements.
3. Of course, there is possibility that over time the trust of users on the particular IDP will
reduce exponentially, and they will start deactivating their accounts with the particular IDP.
But it will still give IDP enough time to extract enough important information about a user and
later use it for malicious purposes.
4. The information collected by a malicious IDP can also be used to profile users, and
compromising their security at a secure IDP.
Though the compromise of an IDP is unlikely. It is not impossible. If an IDP is compromised, it
can have serious repercussions and pose serious question marks over security.
Investigation into Delegation in a Federated Environment August 27, 2012
69
The following section discusses the Cons/ limitations of Gomi’s model and gives a summarized
view of the possible vulnerabilities that have been discussed in the previous section. The section
also introduces some new vulnerabilities that have not previously been discussed.
4.4.4 Limitations:
1. Having flexibility in security policies helps in making the environment for delegation more
dynamic. But it also has some serious security issues. If two entities do not have similarly
strong security policies, then the attacker can try to target communication at the entity that has
weaker security policies. Weak security policy may neutralize the good security of the model,
where the attacker tries to extract information by targeting the weakest link.
2. The SP is allowed to grant access to the delegatee irrespective if the delegatee has
authenticated herself at the SP or not. This allows the intruder to impersonate a delegatee once
the delegatee has passed on the DAT. It also allows the delegatee to reject the claim that it ever
made a particular request if an SP does not have any way of confirming at it’s end that a
particular user with a particular id used a certain service at a particular time. Thus, this model
does not ensure no-repudiation, which should be an integral part of any security framework.
3. The sharing of DAT in a secure way is not mandatory in the environment can lead to some
serious security issues. It allows for a malicious SP to take control of a genuine DAT and
assume the role of a genuine SP. This allows the SP to access the delegator’s personal
information without actually having to provide any services in return to the delegatee. The
delegatee even if she is genuine and has made a genuine request, has no way to confirm her
request as she hasn’t set up a session with the SP requesting for a particular service by logging
in. This scenario can be quite fatal if the information being shared with the SP is of the security
level type ‘Secret’ or above.
4. The model assumes a level of trust between IdP and SP, but does not really state how that
trust was established. This allows for misinterpretation of trust with security assurances. As
trust might be established through business agreements. But, a business agreement may or may
not stipulate the need for the type of security infrastructure to be implemented by an entity.
5. The model does not state the values that are to be used as delegatorID, delegateeID, spID
and the IdP ID, allows for misrepresentation and wrong implementation of these values by an
entity that intends to implement the framework.
Investigation into Delegation in a Federated Environment August 27, 2012
70
6. The model does not specify specific rules regarding the communication of the DAT
between the delegator and the delegatee. This could be exposed as a weak link in the
communication process by the intruder that can maximize the vulnerability by stealing the
DAT and reproducing it as the delegatee at the SP.
7. The model puts quite a lot of control regarding assertions in the hands of the SP. This is a
good technique for the IdP to transfer responsibility on to the SP, but it can also be exposed as
a security flaw. The scenario can be exposed as a security flaw if an SP has been compromised
for over a long period with the intruder creating a backdoor within the SP’s communication
process. This could allow the intruder to use the SP’s backdoor to his advantage by stealing
information and manipulating the SP’s policies.
8. Extending into the previous vulnerability an SP could establish trust relationship with the
SP, allowing it to be part of the framework irrespective of its security policies and reputation.
This creates an opportunity for a trusted SP to perform malicious activities. In such a
framework, all the steps part of a single session will conclude except the final step where the
SP offers the services to the delegatee. The SP could use the assertion to collect data for the
period of time assigned in the assertion without actually offering any services in return to the
delegatee. An SP may or may not be held liable for its actions depending upon the business
agreements it has with the IdP. Also a weak trust setting up mechanism at the part of any IdP
implementing the framework, creates vulnerability in the whole environment. Exposing it as
the weak link when the framework is extended to involve greater number of entities.
The delegation model presented by Gomi has some vulnerability, which can have serious impact
on the security of the framework. Overall though, the model presents an excellent solution for
dynamic identity delegation. The model with few modifications can be implemented practically to
provide entities an environment for secure communication of delegation requests. The model can
also be extended to go beyond the federated environment. In the following section, I am going to
discuss the improvements and modifications that can be made in Gomi’s model that will allow the
delegation process presented by Gomi to be made more secure and extended beyond a federated
environment.
Investigation into Delegation in a Federated Environment August 27, 2012
71
5 A New Conceptual model
5.1 Introduction:
After looking at the problem that a delegation framework could have, it is ideal to suggest a
new conceptual model that will try to incorporate the best features of the available delegation
frameworks and present a model that will provide a balance between dynamicity and flexibility.
Later in the chapter I will also present ideas based upon past research, how the delegation
framework can be implemented in SAML and extended beyond a federation environment.
The idea for a new conceptual model has been derived by combining the best features presented in
the papers [4], [2], and [28].
5.2 Review of Key requirements for a new model:
The idea of a delegation token encoding the delegator’s intentions for delegation is an
excellent way to give power to the delegator to control the task of delegation. But remember that it
is also important to have some control over how a delegator performs the task of delegation. An
uninformed delegator can be as dangerous adversary as a malicious intruder. It’s also a very good
idea to allow a delegatee to use services without having to register at any service or identity
providers. It is a good way to offer dynamicity, but it also creates a window of opportunity for a
malicious outsider. The service provider in most if not all the scenario has been given the power to
make the final decision on the validity or acceptance of a delegations task. The service provider
has the authority to reject a delegation request even if the process has been validated and verified
Investigation into Delegation in a Federated Environment August 27, 2012
72
by the identity provider. Though this provides a good security measure, it does give an opportunity
for a malicious SP to misuse the power. Also, the idea of tokens not carrying any sensitive
information, but being used as means to confirm that a particular delegator has created an assertion
at the IDP with the help of the IDP, and allowing a particular delegatee to use the delegator’s
identity information to perform task at a specific SP is an excellent way to have a balance between
dynamicity and flexibility. But except the model discussed in [28], the other delegation model do
not really address the problem of uniquely and properly identifying the entities that are part of the
communication process. Also, incorporating SAML and taking complete advantages of its
architecture and flexibility will allow for a much secure and yet dynamic delegation framework.
The DAT from Gomi’s model discussed in [4] performs a dual role. It is used as a token to identify
an assertion created at the IdP on behalf of the delegator, and it is also used as a token to
authenticate the participants of the communication. It’s based on the information received within
the token and other information with it that an IdP can link a DAT to its DAA and issues a DAA to
the SP. But as we have seen in the previous chapter, there are various attacks that are possible in
compromising the security of the DAT shared, leading to an authentication failure. Also, it is
important in any communication sequence to identify every entity that is part of the
communication. This allows for proper tracking of the communication process for auditing
purposes. Such a mechanism should also ensure that if an entity has participated in the
communication process then that entity should not be able to repudiate their participation. The
problem of repudiation is quite possible in the Gomi’s model as there is no mechanism to ensure
that the delegatee participating in the communication is a genuine delegatee. Whereas, the model
proposed in [28] does give a very good mechanism of ensuring non-repudiation, by introducing
proxy certificates. In the case of delegation, proxy certificates allow for being able to identify a
user uniquely. As proxy certificates are generated from a user’s real certificates. So my model is
based on similar lines. A model that should ensure that a user participating in the communication is
uniquely identified and it should ensure non-repudiation.
5.3 Conceptual Model:
The key areas that I will be addressing with this conceptual model is as follows:
1. Ensuring that any entity part of the communication process is identified uniquely.
2. An entity if participating in the communication and has performed any processing on the
message received then it should be made to sign and then forward the message.
Investigation into Delegation in a Federated Environment August 27, 2012
73
3. A delegatee should not be provided any service till the delegatee has been identified in
some way by a trusted third-party. The trusted third-party cannot be the entity that plays the
role of delegator in the communication.
4. SP and IdP should be responsible for making some policy changes that will ensure better
security of the delegation process.
5. An IDP should be responsible for assigning privilege levels to a particular user’s request.
6. A delegatee using a delegator’s information should be given a privilege lower privilege
level than that of the delegator.
7. There should logging of any request created at the IdP or created for the SP at both the IdP
and the SP.
8. Ensuring that a secure channel only should exchange the DAT or the delegation token.
9. As discussed in [28] a delegation revocation directory should be created.
10. The model should allow for flexibility in trust establishment procedure.
5.4 New architectural components:
Before getting into the working of the conceptual model. There are three new entities that
have been introduced as part of the working of the model. A brief overview of how these entities
function within the framework is given. In the later sections it will be seen how these new entities
play a vital role as part of the working of the framework is concerned.
5.4.1 Privilege authorization directory: A privilege authorization directory as the name suggests, list the different privilege levels
on information that a user can choose. This list would then be used to inform users on the privilege
level it can assign to a delegatee as part of the delegation process. Once a value for privilege level
assignment is made, the IdP that is managing such a directory will give the delegator information
regarding the data associated with a particular privilege level. It will inform the users on how much
information a delegatee can have access to for a particular privilege level. This feature allows the
delegator to make informed decisions, and it also allows the IdP to offer flexibility to a user
depending upon the particular delegation request. It also allows the IdP to have some control over
the information a delegator shares with the delegatee.
Investigation into Delegation in a Federated Environment August 27, 2012
74
5.4.2 Credential conversion service: A credential conversion service is loosely inspired from [29]. In the new model, it is an
intermediary service between different identity providers that allows for credentials conversion.
Credential conversion is essential in the model as it offers flexibility to users to use their
credentials from different identity providers to authenticate themselves at the service provider that
is not in federation with the same identity provider as the users.
5.4.3 Reputation framework: The idea for reputation framework has been inspired from[30]. The framework will allow
users to rate their experience with the particular service provider. Users can then rate their
experience depending upon the different parameters set for rating. A service provider would be
rated against, security, easy of use, types of service, etc. Higher the rating for a service provider,
more likely it is to get users. The result of reputation framework would be available to any user and
entity part of any environment. This too will help users take more responsibility for their actions
and allow users to make informed decisions. This would also be an incentive for service providers
to make an effort into improving their infrastructure.
5.5 Working of the Model: Protocol for communication will be something like this:
IDP -> A: ({DAT}_inv(Kidp)}_Ka)
A -> SP: ({({DAT}_inv(Kidp)).opr.IdpID}_inv(Ka)}_Ksp)
SP -> IDP: ({{(DAT}_inv(Kidp)}.spID}_inv(Ksp}_Kidp)
Where, Ka, Kidp and Ksp are the public keys of the entities A (Alice), SP (service provider), IDP
(Identity provider).
Investigation into Delegation in a Federated Environment August 27, 2012
75
Figure 30: New delegated access interactions
The scenario above is the modified conceptualization of the model discussed in Gomi’s paper and
presented in Figure 24 of this dissertation. The figure represents the basic idea behind the new
model. One of the changes introduced into the model from the Gomi’s model is introduction of
signatures. Where each entity has to sign the message received before it can be passed on to the
next entity. PL represents the privilege level other values in Figure 30 are same as discussed in
section 4.3. More on that, and details of how the new model works is discussed in the next section
5.5.1 Steps in the model:
1. The delegator receives a request from the delegatee for delegation.
2. The delegator first logs in at his IdP and requests the IdP to create an assertion token.
3. The IdP requests for information about all the entities that will be participating in the
communication process. Very similar to the DAT produced in model discussed in [4], a similar
token will be created in SAML.
4. The IdP should be responsible for maintaining a privilege level directory for a user. A user
can then select the privilege level it wants to assign the delegatee for a particular delegation
request. This allows the delegator to have more control the information that is being shared
with any other party. Also, it allows a particular delegator to alter privilege level depending
Investigation into Delegation in a Federated Environment August 27, 2012
76
upon the trust level it has with the delegatee. For example, if a delegatee is related to the
delegator then it is expected that the delegator will have a higher mutual trust in them as
compared to an office colleague. So the delegator should be allowed to alter their privilege
level they want the delegator to have, depending upon the trust a delegator has on the
delegatee. In the case of person-person delegation, trust cannot really be quantized. Hence,
mutual trust should be left to the best judgment of a delegator.
5. The IdP creates a directory of the privilege level a user has and what information it can
access and modify depending upon the particular privilege level. This will also allow a
delegator to have an overview of the information that will be at a delegatee’s or an SP’s
disposal for a particular privilege level. This allows for delegator to make a more informed
decision.
6. The IdP then creates a delegation assertion on the behalf of the delegator and stores it
locally. It issues a Token that is a random string. This token is just a pointer to the assertion
created and stored at the IdP.
7. The token could be part of a SAML assertion request that is communicated across the
model.
8. The message transmitted to the delegator by the IdP, should specify the privilege level that
a particular request has been sent with. For example, a delegator giving full control of his
identity to a delegatee could send a token with privilege level of ‘AA’. But if a delegator
selects a lower privilege level, then the request could contain a value like ‘BA’. The privilege
level will be a very short string just to uniquely identify a privilege level.
9. The IdP before sending the request should be made to sign the token or the message before
forwarding it to the delegator. This allows the delegator to be sure that the request has
originated from the IdP.
10. After the delegator receives the message, it will not be allowed to do any further
processing and should only be responsible for forwarding the message to the delegatee.
11. Before sending the message, the delegator has to ensure that a secure connection is
established between him and the delegatee. Once a secure connection is established the
delegator signs the message and forwards it to the delegatee.
12. The delegatee once it receives the signed message adds the operation it wants to perform at
the SP signs the message and forwards it to the SP.
Investigation into Delegation in a Federated Environment August 27, 2012
77
13. The SP now can decide to add information to the message and just forward it, or it may ask
the delegatee to authenticate herself at an IdP. It is important to note that a single SP may be in
federation with multiple IdP and vice versa. For example, a user can login to
www.huffingtonpost.com using either their Facebook identity or twitter identity.
14. So if a delegatee is requested to provide identity credential from any of the IdP that the SP
is in federation with, the delegatee logs in with the particular IdP and sends back the
credentials information to the SP via the IdP. It is important to note, that the IdP considered in
this case is assumed to be a different IdP than the one that is being used by the delegator. It is
assumed that the delegatee has an account set up at some IdP, but not at the IdP that the
delegator has his account. This credential sharing allows the SP to be sure of the identity of the
particular delegatee and allows serving a delegatee’s request within the same session that has
been created using the credentials obtained from the second IdP. It is important to note that this
restriction put by the SP on the delegatee, may affect the dynamic nature of the framework.
Also, the SP may not be in federation with the IdP where the delegatee has registered her
online identity. A theoretical solution the problem is implementation of credential validity and
conversion service. The service could provide for a mechanism wherein it can act as a
mediator or conversion service that allows for credentials from one IdP to be accepted by any
of the IdP that the SP is in federation with, and then forward those credentials via the trusted
IdP to the SP. This would allow for the delegatee to still be able to authenticate herself without
creating a new identity.
15. Once the SP has performed the task of verifying the identity of the delegatee, it can
forward the request to the IdP by signing the message.
16. Once the IdP receives the message it verifies the message received. Logs the message and
the entities that signed it, then it creates a key using the token within the message to search for
the particular assertion that they key refers to.
17. Once, IdP performs all the verification procedures, it issues the SP an OK or request
failure response depending upon the result of IdP’s local processing of the request.
18. After the IdP sends the response to SP, the SP has to grant the service to the delegatee.
This is made mandatory as all the previous steps are used to authenticate and validate the
request made by the delegatee. Allowing the SP to deny a request based upon its local policies
may lead to lack of trust and confidence in the SP. Making granting of service mandatory is a
hard step to achieve. But establishing a type of reputation framework can attain it. The idea of
reputation framework is another theoretical idea that will give powers to the user to rate their
Investigation into Delegation in a Federated Environment August 27, 2012
78
experience with a particular service provider. The higher the rating points are for a service, the
more it is likely to get users. So ensuring that once a user has gone through all the previous
steps, it should be granted the service that was requested.
19. After all the previous steps are completed, the delegatee gets the services requested from
the SP.
The framework/ new model will have a mesh like structure that can be seen in the following figure:
Figure 31: Structural overview of the new model
After seeing the working of the model, a new model can be visualized from the Figure 31. The new
model will then be incorporated within a larger framework, i.e. a reputation framework.
The new conceptual model is just a theoretical model that has been conceptualized after combining
different ideas from various researches and my own understanding of identity delegation in a
federated environment.
Investigation into Delegation in a Federated Environment August 27, 2012
79
The delegation framework discussed above and other frameworks discussed previously can be
extended beyond the boundary of framework that uses SAML for identity federation and
delegation. The model presented by Canovas, Lopez and Gomez-Skarmeta [29] presents a model
that would allow non-SAML based entities to request for resources from SAML based entities,
without having to adopt SAML. The new conceptual model discussed could be extended beyond
the realms of SAML, and incorporate even non-SAML based entities to provide user dynamic and
secure services. Also, as discussed in [2], and automated trust negotiation could be an integral part
of the new model being made even more flexible and dynamic. It would allow entities to form
dynamic trust relationship, rather than the pre-established trust that is commonly applicable to
most of the existing protocols.
There are quite a few models and research presented for delegation in a federated environment, but
most of the studies cover only a limited scope. The model discussed and the ideas of extension
presented, introduces the idea of extensively integrating delegation as an integral part of identity
management.
Investigation into Delegation in a Federated Environment August 27, 2012
80
6 Conclusions:
The main aim of the dissertation was to investigate delegation in a Federated environment.
But before delegation could be discussed it was important to talk about online identities, Identity
Federation, and then move on to delegation.
During the planning stages of the dissertation it was realized that, it wasn’t possible to discuss all
the frameworks for Identity delegation that have been presented by esteemed authors and
researchers. Hence, it was important to categorize different types of delegation models. After
categorization, it was realized that most of the models researched dealt with a similar issue of
delegation to service provider as delegatee. As quite a lot of research had already been done in that
field it was critical to choose a type of delegation that hadn’t been that extensively researched. A
model presented by Hidehato Gomi stood out from the rest, as it discussed a delegation scenario
that is very common and also very much ignored. The paper presented a model for a secure and
dynamic person-to-person delegation model in a federated environment. During the course of
planning for the dissertation, it was also realized that once an analysis is done on Gomi’s model, it
would be ideal to come up with a new conceptual model for delegation. A new conceptual model,
that would in some way summarize the work done in past and combine them to present a unique
and novel idea that would be valid within and beyond the boundaries of Federation.
6.1 A look Back:
The project started off with doing an extensive literature survey of various documents related to
Online Identities, Identity Federation, and Identity Delegation. Quite a few papers, journals,
articles, books, tutorials, products documentation, etc. were reviewed to get a holistic view of the
problem at hand. Once, the final decision was made on the delegation model that would be looked
at, it was important to review the technologies that help and support identity delegation.
As most of the technologies and some of the concepts were new to me, hence it required extra hard
work and dedication from my part to understand the intricacies of Federation and Delegation.
A review of SAML was done in the dissertation as SAML provides the framework and technology
for entities to implement Identity delegation and Federation in a seamless manner. So it was
Investigation into Delegation in a Federated Environment August 27, 2012
81
critical to discuss SAML as its been widely accepted as the language to propagate information
securely across the open networks.
One of the most challenging parts of the dissertation was the review and analysis of Gomi’s
conceptual model. The paper was well presented and the idea for delegation was excellent. But it
was quite challenging to put the model presented in the form of a security protocol. Some of the
values used by Gomi within the paper were too vague and open for misinterpretation. So this
required me to test the protocols for different values.
The tool used to validate the security of protocols was AVISPA. AVISPA provides an excellent
tool for validation of security protocols. AVISPA can either be downloaded or a user can load their
program on to the AVISPA web tool. The AVISPA is an easy to use tool that gives very precise
reports on the attack found on the user’s protocol. AVISPA gives an attack trace both in text and
visual format. AVISPA only accepts programs written in HLPSL. Another challenge during my
dissertation was to learn and understand HLPSL. But the documentations and tutorials on HLPSL
were an excellent resource in my understanding of the language. Once the protocols were created
and tested on AVISPA it was time for result analysis and evaluation.
The protocol was tested for different parameters and different values of the ID’s that were
suggested by Gomi in his paper. The protocols were also tested for added security features that
may be implemented within the protocol with little modifications. Most of the protocols were
found to be insecure by AVISPA. So once, the results were generated and analyzed, real time
scenarios were conceptualized that may take advantage of the shortcomings of the protocol and
expose the lack security of the model.
After the analysis and evaluation, it was time to come up with a new model that would plug the
security holes found within Gomi’s model. This was the most challenging part as it involved
extensive study of different delegation model and mark out their best features. After long hours of
discussions and analysis, a model was conceptualized that would combine the best features of
some well-known delegation models and present it in a new model.
6.2 Achievements:
6.2.1 Explore Identity Federation:
Investigation into Delegation in a Federated Environment August 27, 2012
82
Within the course of researching and reviewing Identity Federation it was possible to understand
the importance and need of Identity Federation. It was possible to understand how Identity
Federation solves the problem of multiple online identities, how it prevents identity management
hassles for both identity and service providers. It was through Identity Federation that Single Sign-
on became a reality and made it easier for user to access different services. Opportunity was
provided to explore different technologies that support Identity Federation.
6.2.2 Explore SAML:
SAML is one of the technologies that provides extensive set of functions to help organizations
enable a secure Federated environment. The review and analysis of SAML was an excellent
opportunity to understand and review the structure and components of SAML that help enable
secure implementation of Federation. How SAML’s XML based structure makes it very easy to
understand and modify its implementations depending upon the need of an organization.
6.2.3 Test and Evaluation of Protocols:
To create a protocol from a model and test it for different values was an excellent learning
opportunity. It allowed me to have a deeper understanding of how protocols work and what is
critical in the designing stages of a protocol. Testing protocols on a tool like AVISPA was initially
a challenge, but once the test was successfully performed, it was quite satisfactory.
6.2.4 Conceptualization of a new model:
The opportunity of conceptualizing a new model for secure and dynamic person-person to
delegation was a mouth-watering prospect. It gave me an opportunity to explore my imaginative
side. It also involved a thorough understanding of other delegation models so as to combine their
best features and form a new model. I believe the new model was successful in presenting a new
model for delegation that would be both, secure and dynamic.
Investigation into Delegation in a Federated Environment August 27, 2012
83
6.3 Conclusion:
The growth in Internet and Online services over the past few years have been tremendous. Users
can now just sit in front of their computers and file their taxes, pay their rents, register for voter
identification, register for a passport and so much more. But, it is sometimes not possible for users
to do all these tasks by themselves. Hence, the need for delegation arises. A user would delegate
his/her task to a delegatee, and the delegatee will perform the task on the behalf of the user. In this
massive global business environment, sometimes a user needs to delegatee their task to a person
and not to a service. A solution to provide dynamic and secure mechanism for person-to-person
delegation is the need of the hour. A solution already put forward has been analyzed and a new
solution has been presented. Delegation should become an integral part of Identity federation and
not just an added feature.
Investigation into Delegation in a Federated Environment August 27, 2012
84
7 Bibliography:
[1] OpenGroup.org, “Single Sign-On.” [Online]. Available: http://www.opengroup.org/security/sso/.
[2] Y. Zuo, X. Luo, and F. Zeng, “Towards a dynamic federation framework based on SAML and automated trust negotiation,” Web Information Systems and Mining, pp. 254–262, 2010.
[3] H. Lockhart, “Security Assertion Markup Language ( SAML ) V2 . 0 Technical Overview,” 2008.
[4] H. Gomi, “Dynamic Identity Delegation Using Access Tokens in Federated Environments,” 2011 IEEE International Conference on Web Services, pp. 612–619, Jul. 2011.
[5] Shapeshed, “Moving Your Online Identity.” [Online]. Available: http://shapeshed.com/moving_your_online_identity/. [Accessed: 26-Aug-2012].
[6] Adriana, “Media Influencer.” [Online]. Available: http://www.mediainfluencer.net/2009/01/crm-cmr-or-vrm/comment-page-1/. [Accessed: 26-Aug-2012].
[7] F. Cavazza, “FredCavazza.net.” [Online]. Available: - http://www.fredcavazza.net/blog/in-english/.
[8] P. Madsen, “Liberty ID-WSF People Service – federated social identity Editor,” 2005.
[9] D. Morin, “Facebook developers.” [Online]. Available: http://developers.facebook.com/blog/post/2008/05/09/announcing-facebook-connect/.
[10] Facebook, “Facebook developers.” [Online]. Available: http://developers.facebook.com/docs/guides/web/.
[11] IBBT, “Identity Management for eGovernment,” no. December, pp. 1–36, 2007.
[12] R. Peeters and D. D. Cock, “Cross-Context Delegation through Identity Federation ∗.”
Investigation into Delegation in a Federated Environment August 27, 2012
85
[13] P. Madsen, E. Maler, S. Microsystems, T. Wisniewski, T. Nadalin, S. Cantor, and J. Hodges, “SAML V2.0 Executive Overview,” no. April, pp. 1–7, 2005.
[14] C. Technologies, “Federation Security Services Terminology.” [Online]. Available: https://support.ca.com/cadocs/0/CA SiteMinder r6 0 SP6-ENU/Bookshelf_Files/HTML/index.htm?toc.htm?257874.html.
[15] A. Team, “AVISPA v1 . 1 User Manual,” 2006.
[16] G. Lowe, “Casper : A Compiler for the Analysis of Security Protocols 1 Introduction 2 The Casper syntax,” pp. 1–31, 1998.
[17] F. Systems, “Failures-Divergence Refinement,” no. October, 2010.
[18] B. Blanchet and B. Smyth, “Automatic Cryptographic Protocol Verifier , User Manual and Tutorial,” 2011.
[19] S. Escobar and C. Meadows, “Maude-NPA, Version 2.0 (November 26th, 2011),” vol. 0, pp. 0–73, 2011.
[20] D. Basin and M. Sebastian, “OFMC : A symbolic model checker for security protocols,” 2004.
[21] D. Dolev and a. Yao, “On the security of public key protocols,” IEEE Transactions on Information Theory, vol. 29, no. 2, pp. 198–208, Mar. 1983.
[22] M. Turuani, “The CL-Atse Protocol Analyser,” pp. 277–286, 2006.
[23] A. Armando and L. Compagna, “SATMC : A SAT-Based Model Checker for Security Protocols,” pp. 730–733, 2004.
[24] A. Armando, D. Basin, Y. Boichut, Y. Chevalier, and L. Compagna, “The AVISPA Tool for the Automated Validation,” pp. 281–285.
[25] T. A. Team, “HLPSL Tutorial,” 2006.
[26] M. Burrows and R. Needham, “A Logic of Authentication.” Proc. R. Soc. Lond. A December 8, 1989 426 1871 233-271; 1471-2946
[27] B. Clifford Neuman and Theodore Ts‘o, “Kerberos: An Authentication Sewice for Computer Networks,” no. September, 1994.
Investigation into Delegation in a Federated Environment August 27, 2012
86
[28] S. Sánchez García, A. Gómez Oliva, E. Pérez Belleboni, and I. Pau de la Cruz, “Solving identity delegation problem in the e-government environment,” International Journal of Information Security, vol. 10, no. 6, pp. 351–372, Jul. 2011.
[29] L. Gabriel and F. G. Antonio, “A Credential Conversion Service for SAML-based Scenarios,” pp. 297–305, 2004.
[30] M. Q. Kuhnen and G. Mart, “Enhancing OpenID through a Reputation,” pp. 1–18, 2011.