Detailed discussion on Identity Management issue in a Federated Environment.

1. Investigation into Delegation in a Federated
Environment
DistributedDissertation
(COMM002)
MSc Board Game Environment
MSc Dissertation COMM002
Akshat Ratanpal (URN: 6190741)
Peter Helland 1366211
Submitted for the Degree of
Master of Science in Security Technologies and Applications
Submitted for the Degree of
Master of Science in tInternet Computing
from
he
from the
Department of Computing
Department of Computing
Faculty of Engineering and Physical Sciences
Faculty of Engineering and Physical Sciences
University of Surrey
University of Surrey
Guildford, Surrey, GU2 7XH, UK
Guildford, Surrey, GU2 7XH, UK
16th August 2010
August 2012
Supervised by:by: Dr Roger Peel
Supervised Dr Helen Treharne
© Akshat Ratanpal 2012
Peter Helland 2010

2. Investigation
into
Delegation
in
a
Federated
Environment
August
27,
2012
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.
2

3. Investigation
into
Delegation
in
a
Federated
Environment
August
27,
2012
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.
3

4. Investigation
into
Delegation
in
a
Federated
Environment
August
27,
2012
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
4

5. Investigation
into
Delegation
in
a
Federated
Environment
August
27,
2012
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
5

6. Investigation
into
Delegation
in
a
Federated
Environment
August
27,
2012
6.3
Conclusion: ............................................................................................................................. 83
7
Bibliography: ............................................................................................................... 84
6

7. Investigation
into
Delegation
in
a
Federated
Environment
August
27,
2012
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
7

8. Investigation
into
Delegation
in
a
Federated
Environment
August
27,
2012
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
8

9. Investigation
into
Delegation
in
a
Federated
Environment
August
27,
2012
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:
9

10. Investigation
into
Delegation
in
a
Federated
Environment
August
27,
2012
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
Introduction
Literature
Review
Overview
of
AVISPA
Problem
Analysis
A
new
conceptual
model
Conclusion
Figure
1:
Structure
of
the
Report
10

11. Investigation
into
Delegation
in
a
Federated
Environment
August
27,
2012
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
11

12. Investigation
into
Delegation
in
a
Federated
Environment
August
27,
2012
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.
12

13. Investigation
into
Delegation
in
a
Federated
Environment
August
27,
2012
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:
13

14. Investigation
into
Delegation
in
a
Federated
Environment
August
27,
2012
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
14

15. Investigation
into
Delegation
in
a
Federated
Environment
August
27,
2012
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
15

16. Investigation
into
Delegation
in
a
Federated
Environment
August
27,
2012
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]
16

17. Investigation
into
Delegation
in
a
Federated
Environment
August
27,
2012
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
17

18. Investigation
into
Delegation
in
a
Federated
Environment
August
27,
2012
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:
Source web site:
airline.example.com
Authenticate
information
1
Identity
Business agreement
2 Access Destination web site:
protected cars.example.co.uk
resource
SSO-usecase
Figure 2: General Single Sign-On Use Case
365 This high-level descriptionFigure
5: General Single Sign-on Use case from [3] before accessing a
indicated that the user had first authenticated at the IdP
366 protected resource at the SP. This scenario is commonly referred to as an IdP-initiated web SSO
367 scenario. While IdP-initiated SSO is useful in certain cases, a more common scenario starts with a user
368 visiting an SP site through abe seen how a user has to authenticate at the IdP, which in this case special
In the figure above it can browser bookmark, possibly first accessing resources that require no is
369 authentication or authorization. In a SAML-enabled deployment, when they subsequently attempt to
airline.example.com, and the IdP then shares the users information with the SP, which in this case
370 access a protected resource whomSP, the SP will send the for some restricted resources or services.
is cars.example.com, from
at the the user has requested user to the IdP with an authentication request
371 in order to have the user log in. Thus this scenario is referred to as SP-initiated web SSO. Once logged in,
372 the is to cannoted that this type ofthat can be used by the SP topossible the user's access a previous
It IdP be produce an assertion information sharing is only validate if there has been rights to the
373 protected resource. SAML V2.0 supportsparties involved in the user’s information sharing.
business agreements between the two both the IdP-initiated and SP-initiated flows.
374 SAML supports numerous variations on these two primary flows that deal with requirements for using
375 The previous example demonstrated how a users information is shared between two entities that
various types and strengths of user authentication methods, alternative formats for expressing federated
376 identities, use of different bindings for transporting the protocol messages, inclusion of identity attributes,
have pre-established trust relationship. But, Identity Federation Management goes much beyond
377 etc. Many of these options are looked at in more detail in later sections of this document.
18
378 3.3
Identity Federation Use Case
379 As mentioned earlier, a user's identity is said to be federated between a set of providers when there is an

19. Investigation
into
Delegation
in
a
Federated
Environment
August
27,
2012
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 3: General Identity Federation Use Case
Prepare to rent car logged in Prepare to book hotel logged in
Book flight logged in
as jdoe; accept offer of as johnd; accept offer of
as johndoe
federation with airline.example.com federation with airline.example.com
airline.example.com cars.example.co.uk hotels.example.ca
No correlation of John's
activities across these sites
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)
IDFed-usecase
427 The processing sequence is as follows:
428 1. John books Figure
6: airline.example.com using his johndoe user account.
a flight at General Identity Federation Use Case from[3]
429 2. John then uses a browser bookmark or clicks on a link to visit cars.example.co.uk to reserve a car.
430 This site sees that the browser user is not logged in locally but that he has previously visited their IdP
431 partner site airline.example.com (optionally using the new IdP discovery feature of SAML V2.0). So
432 cars.example.co.uk asks John if he would like to consent to federate his local cars.example.co.uk
433 identity with airline.example.com.
434 3. John consents to the federation and his browser is redirected back to airline.example.com where the
435 site creates a new pseudonym, azqu3H7 for John's use when he visits cars.example.co.uk. The
436 19
pseudonym is linked to his johndoe account. Both providers agree to use this identifier to refer to John
437 in subsequent transactions.
438 4. John is then redirected back to cars.example.co.uk with a SAML assertion indicating that the user
439 represented by the federated persistent identifier azqu3H7 is logged in at the IdP. Since this is the first
440 time that cars.example.co.uk has seen this identifier, it does not know which local user account to

20. Investigation
into
Delegation
in
a
Federated
Environment
August
27,
2012
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
20

21. Investigation
into
Delegation
in
a
Federated
Environment
August
27,
2012
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]
21

22. Investigation
into
Delegation
in
a
Federated
Environment
August
27,
2012
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.
22

23. Investigation
into
Delegation
in
a
Federated
Environment
August
27,
2012
- 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
23

24. Investigation
into
Delegation
in
a
Federated
Environment
August
27,
2012
2.3.2 When and why was SAML created?
Figure 7 gives a historic timeline of SAML
• OASIS
SSTC
committe
meet
for
the
Pirst
time
2001
Jan
• SAML
v1.0
was
announced
as
an
OASIS
2002
Nov
standard
• Liberty
releases
ID-­‐FF
1.1
2003
Apr
• SAML
v1.1
is
Introduced
2003
Sep
2003
Sep
• Liberty
contributes
ID-­‐FF
to
OASIS
• Liberty
ID-­‐FF
v1.2
is
Pinalized
2003
Nov
• SAML
v2.0
is
announced
2005
Mar
• Errata
approved
for
SAML
v2.0
2007
Jul
Figure
8: Timeline of SAML till year 2007
24

25. Investigation
into
Delegation
in
a
Federated
Environment
August
27,
2012
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
25

26. 476 SSO profile. Profiles typically define constraints on the contents of SAML a
477 bindings in order to solve the business use case in an interoperable fashion
478 Profiles, which do not refer to any protocol messages and bindings, that def
479 information using assertions in waysn
a
Federated
Environment
Investigation
into
Delegation
i that align with a number of common us
480 LDAP directories, DCE).
August
27,
2012
481 Figure 4 illustrates the relationship between these basic SAML concepts.
Profiles
Combinations of assertions, protocols,
and bindings to support a defined use case
Bindings
Mappings of SAML protocols
onto standard messaging and
Authentic
communication protocols
Detailed
and strength
Protocols
Requests and responses for
obtaining assertions and doing
identity management Me
Configur
identity and
Assertions
Authentication, attribute, and
entitlement information
Figure 4: Basic SAML Concepts
Figure
9: Primary components of SAML obtained from [3]
483 Two other SAML concepts are useful for building and deploying a SAML en
484 • Metadata defines a way to express and share configuration informatio
485 instance, an entity's supported SAML bindings, operational roles (IDP,
486 information, supporting identity attributes, and key information for encr
sstc-saml-tech-overview-2.0-cd-02
Copyright© OASIS® 2008. All Rights Reserved.
26

27. Investigation
into
Delegation
in
a
Federated
Environment
August
27,
2012
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 john.doe@example.com 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:
27

28. SAML-component-nesting
Figure 5: Relationship of SAML Components
Investigation
into
Delegation
in
a
Federated
Environment
August
27,
2012
625 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: j.doe@example.com
11: </saml:NameID>
12: </saml:Subject>
13: <saml:Conditions
14: NotBefore="2005-01-31T12:00:00Z"
15: NotOnOrAfter="2005-01-31T12:10:00Z">
16: </saml:Conditions>
17: <saml:AuthnStatement
18: AuthnInstant="2005-01-31T12:00:00Z" SessionIndex="67775277772">
19: <saml:AuthnContext>
20: <saml:AuthnContextClassRef>
21: urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
22: </saml:AuthnContextClassRef>
23: </saml:AuthnContext>
24: </saml:AuthnStatement>
25: </saml:Assertion>
Figure 6: Assertion with Subject, Conditions, and Authentication Statement
626
Figure
10: Example of a SAML assertion from [3]
627 Figure 6shows an XML fragment containing an example assertion with a single authentication statement.
628 Note that the XML text in the figure (and elsewhere in this document) has been formatted for presentation
629 purposes. Specifically, while line breaks and extra spaces are ignored between XML attributes within an
630 XML element tag, when they appear between XML element start/end tags, they technically become part of
631 the element value. They are inserted in the example only for readability.
sstc-saml-tech-overview-2.0-cd-02 Mar 25,2008
Copyright© OASIS® 2008. All Rights Reserved.
28

29. Investigation
into
Delegation
in
a
Federated
Environment
August
27,
2012
The figure shows idp.example.com as the issuer of the assertion. The subject of the assertion that is
given by NameID is j.doe@example.com 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]
29

30. Investigation
into
Delegation
in
a
Federated
Environment
August
27,
2012
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.
30

31. Investigation
into
Delegation
in
a
Federated
Environment
August
27,
2012
HTTP
Redirect
SAML
HTTP
URI
Post
Reverse
HTTP
SOAP
Artifact
SAML
SOAP
Figure
11: Types of SAML Bindings
31

32. Investigation
into
Delegation
in
a
Federated
Environment
August
27,
2012
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:
32

33. Investigation
into
Delegation
in
a
Federated
Environment
August
27,
2012
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.
33

34. Investigation
into
Delegation
in
a
Federated
Environment
August
27,
2012
Web
Browser
SSO
Name
IdentiPier
ECP
Management
Identity
Name
IdentiPier
Provider
Mapping
Discovery
Artifact
Single
Resolution
Logout
Assertion
Query/
Request
Figure
12: SAML profiles
34

35. onents that, when put together, allow a number of use cases to be
permit transfer of identity, authentication, attribute, and
nomous organizations that haveelegation
in
a
Federated
Etrust relationship.
Investigation
into
D
an established nvironment
he structure and content of both assertions and protocol messages
August
27,
2012
ut a principal that an asserting party claims to be true. The valid
are defined by the SAML assertion XML schema. Assertions are
ased on a request of some sort from a relying party, although under
can be delivered to a relying party in Profile:
2.3.4.4.7 Name Identifier Management an unsolicited manner. SAML
he SAML-defined requests the protocol name identifier management protocol, is used with The
Defines how and return appropriate responses.
ges are defined by the SAML-defined protocol XML schema.
various SAML bindings.
unication or messaging protocols (such as HTTP or SOAP) are
ages between participants is defined by the SAML bindings.
sfy a particular business use case, for example the Web Browser
onstraints on the contents of SAML assertions, protocols, and
2.3.4.4.8 Name Identifier Mapping Profile:
use case in an interoperable name identifier mapping protocol uses a synchronous binding
“Defines how the fashion. There are also Attribute
ocol messages SOAP”[3].
such as
and bindings, that define how to exchange attribute
at align with a number of common usage environments (e.g. X.500/
ween theseThe SAML components discussed above are also supported by two other SAML components that
basic SAML concepts.
support, and are useful in implementing a SAML environment are Authentication Context and
Metadata.
ons, protocols,
defined use case
s
protocols
aging and Authentication Context
rotocols
Detailed data on types
and strengths of authentication
s
onses for
and doing
ement Metadata
Configuration data for
identity and service providers
ns
bute, and
mation
Figure
13: Additional SAML components from[3]
SAML-concepts
igure 4: Basic SAML Concepts
2.3.4.5 Authentication Context:
Authentication Context is a component of SAML. But it has its separate XML format to
or building convey the information within SAML environment: used to convey information
and deploying a it. Authentication Context is basically
regarding the authentication mechanism used by a SAML entity. For example, if a service provider
ss and share configuration information between SAML parties. For
35
AML bindings, operational roles (IDP, SP, etc), identifier
ttributes, and key information for encryption and signing can be

36. Investigation
into
Delegation
in
a
Federated
Environment
August
27,
2012
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.
36

37. Investigation
into
Delegation
in
a
Federated
Environment
August
27,
2012
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.
37

38. Investigation
into
Delegation
in
a
Federated
Environment
August
27,
2012
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
38

39. Investigation
into
Delegation
in
a
Federated
Environment
August
27,
2012
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.
39

40. Investigation
into
Delegation
in
a
Federated
Environment
August
27,
2012
Figure
15: Scenario 2
2.4.3 Scenario 3:
Figure
16: Scenario 3
40

41. Investigation
into
Delegation
in
a
Federated
Environment
August
27,
2012
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.
41

42. Investigation
into
Delegation
in
a
Federated
Environment
August
27,
2012
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
42

43. Investigation
into
Delegation
in
a
Federated
Environment
August
27,
2012
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
43

44. Investigation
into
Delegation
in
a
Federated
Environment
2 User Section
August
27,
2012
This section describes architectureto use the AVISPA tool: to specify protocols in HLPSL,
3.2 AVISPA the easiest way and HLPSL:
then to run the avispa script for analysing it.
High−Level Protocol Specification Language (HLPSL)
avispa script file
Translator
HLPSL2IF
Intermediate Format (IF)
On−the−fly CL−based SAT−based Tree Automata−based
Model−Checker Attack Searcher Model−Checker Protocol Analyser
OFMC AtSe SATMC TA4SP
Output Format (OF)
Figure
17: Architecture of AVISPA from[15]
Figure 1: Architecture of the AVISPA tool v.1.1
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
2.1 used to analyze aProtocols: OFMC, AtSe, SATMC, and TA4SP.
Specifying protocol are, HLPSL
Protocols to be studied Model-Checker (OFMC): specified in HLPSL (standing for High
3.2.1 On-the-fly by the AVISPA tool have to be
Level Protocols Specification Language), and written in a file with extension hlpsl.
This language is basedet al. [20] and hisroles for three comprising of participant role, and composition
David basin on roles: basic team of representing each himself, Sebastian
roles for representing scenarios offrom theroles. Each role is independent from Zurich, Zurich,
M ̈odersheim, and Luca Vigan`o
basic Department of Computer Science, ETH the others, getting
Switzerland designed the OFMC tool. The motivation and purpose of the tool was to design a tool
some initial information byprotocols for infinite number of state spaces and consider the intruder
that would check security
parameters, communicating with the other roles by channels.
In this section, we present the syntax of HLPSL and some guidelines for HLPSL beginners.
44
2.1.1 HLPSL Syntax The syntax of HLPSL is detailed in the following, using the standard

45. Investigation
into
Delegation
in
a
Federated
Environment
August
27,
2012
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.
45