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.


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.


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


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


6

6.3 Conclusion: ............................................................................................................................. 83

7 Bibliography: ............................................................................................................... 84


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


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


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:


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


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


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.


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:


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


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


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]


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


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


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.


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


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


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]


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.


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


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


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


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


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


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:


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.


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


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]


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.


31

Figure 11: Types of SAML Bindings

HTTP Redirect

HTTP Post

HTTP Artifact

SAML SOAP

Reverse SOAP

SAML URI


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:


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.


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


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


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


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.


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.


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


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.


40


2.4.3 Scenario 3:



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.


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


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


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


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.


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:


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.


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:


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:


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.


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.


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].


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].


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:


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


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.


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


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.


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


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.


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.


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:


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.


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)


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.


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.


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


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.


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.


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.


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


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.


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.


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).


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


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.


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


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.


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.


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


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:


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.


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.


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 ∗.”


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.


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.

information security (dissertation)

Technology