Investigation into Delegation in a Federated                            Environment	              DistributedDissertation	...
Investigation	  into	  Delegation	  in	  a	  Federated	  Environment	                                                   Au...
Investigation	  into	  Delegation	  in	  a	  Federated	  Environment	                                                   Au...
Investigation	  into	  Delegation	  in	  a	  Federated	  Environment	                                                     ...
Investigation	  into	  Delegation	  in	  a	  Federated	  Environment	                                                     ...
Investigation	  into	  Delegation	  in	  a	  Federated	  Environment	                                                     ...
Investigation	  into	  Delegation	  in	  a	  Federated	  Environment	                                                     ...
Investigation	  into	  Delegation	  in	  a	  Federated	  Environment	                                                Augus...
Investigation	  into	  Delegation	  in	  a	  Federated	  Environment	                                              August	...
Investigation	  into	  Delegation	  in	  a	  Federated	  Environment	                                                     ...
Investigation	  into	  Delegation	  in	  a	  Federated	  Environment	                                              August	...
Investigation	  into	  Delegation	  in	  a	  Federated	  Environment	                                             August	 ...
Investigation	  into	  Delegation	  in	  a	  Federated	  Environment	                                             August	 ...
Investigation	  into	  Delegation	  in	  a	  Federated	  Environment	                                                     ...
Investigation	  into	  Delegation	  in	  a	  Federated	  Environment	                                                 Augu...
Investigation	  into	  Delegation	  in	  a	  Federated	  Environment	                                                 Augu...
Investigation	  into	  Delegation	  in	  a	  Federated	  Environment	                                              August	...
Investigation	  into	  Delegation	  in	  a	  Federated	  Environment	                                                     ...
Investigation	  into	  Delegation	  in	  a	  Federated	  Environment	                                                     ...
Investigation	  into	  Delegation	  in	  a	  Federated	  Environment	                                              August	...
Investigation	  into	  Delegation	  in	  a	  Federated	  Environment	                                              August	...
Investigation	  into	  Delegation	  in	  a	  Federated	  Environment	                                               August...
Investigation	  into	  Delegation	  in	  a	  Federated	  Environment	                                              August	...
Investigation	  into	  Delegation	  in	  a	  Federated	  Environment	                                                     ...
Investigation	  into	  Delegation	  in	  a	  Federated	  Environment	                                                     ...
476   SSO profile. Profiles typically define constraints on the contents of SAML a477   bindings in order to solve the bus...
Investigation	  into	  Delegation	  in	  a	  Federated	  Environment	                                             August	 ...
SAML-component-nesting                                            Figure 5: Relationship of SAML Components               ...
Investigation	  into	  Delegation	  in	  a	  Federated	  Environment	                                              August	...
Investigation	  into	  Delegation	  in	  a	  Federated	  Environment	                                             August	 ...
Investigation	  into	  Delegation	  in	  a	  Federated	  Environment	                                          August	  27...
Investigation	  into	  Delegation	  in	  a	  Federated	  Environment	                                              August	...
Investigation	  into	  Delegation	  in	  a	  Federated	  Environment	                                              August	...
Investigation	  into	  Delegation	  in	  a	  Federated	  Environment	                                                 Augu...
onents that, when put together, allow a number of use cases to bepermit transfer of identity, authentication, attribute, a...
Investigation	  into	  Delegation	  in	  a	  Federated	  Environment	                                             August	 ...
Investigation	  into	  Delegation	  in	  a	  Federated	  Environment	                                              August	...
Investigation	  into	  Delegation	  in	  a	  Federated	  Environment	                                              August	...
Investigation	  into	  Delegation	  in	  a	  Federated	  Environment	                                              August	...
Investigation	  into	  Delegation	  in	  a	  Federated	  Environment	                                        August	  27,	...
Investigation	  into	  Delegation	  in	  a	  Federated	  Environment	                                              August	...
Investigation	  into	  Delegation	  in	  a	  Federated	  Environment	                                                     ...
Investigation	  into	  Delegation	  in	  a	  Federated	  Environment	                                                     ...
Investigation	  into	  Delegation	  in	  a	  Federated	  Environment	  2 User Section                                     ...
Information Security (Dissertation)
Information Security (Dissertation)
Information Security (Dissertation)
Information Security (Dissertation)
Information Security (Dissertation)
Information Security (Dissertation)
Information Security (Dissertation)
Information Security (Dissertation)
Information Security (Dissertation)
Information Security (Dissertation)
Information Security (Dissertation)
Information Security (Dissertation)
Information Security (Dissertation)
Information Security (Dissertation)
Information Security (Dissertation)
Information Security (Dissertation)
Information Security (Dissertation)
Information Security (Dissertation)
Information Security (Dissertation)
Information Security (Dissertation)
Information Security (Dissertation)
Information Security (Dissertation)
Information Security (Dissertation)
Information Security (Dissertation)
Information Security (Dissertation)
Information Security (Dissertation)
Information Security (Dissertation)
Information Security (Dissertation)
Information Security (Dissertation)
Information Security (Dissertation)
Information Security (Dissertation)
Information Security (Dissertation)
Information Security (Dissertation)
Information Security (Dissertation)
Information Security (Dissertation)
Information Security (Dissertation)
Information Security (Dissertation)
Information Security (Dissertation)
Information Security (Dissertation)
Information Security (Dissertation)
Information Security (Dissertation)
Information Security (Dissertation)
Upcoming SlideShare
Loading in...5
×

Information Security (Dissertation)

2,393

Published on

Detailed discussion on Identity Management issue in a Federated Environment.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
2,393
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
35
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Information Security (Dissertation)"

  1. 1. Investigation into Delegation in a Federated Environment   DistributedDissertation  (COMM002)   MSc Board Game Environment   MSc Dissertation COMM002 Akshat Ratanpal (URN: 6190741) Peter Helland 1366211 Submitted for the Degree of Master of Science in Security Technologies and Applications Submitted for the Degree of Master of Science in tInternet Computing from   he   from the   Department of Computing Department of Computing Faculty of Engineering and Physical Sciences Faculty of Engineering and Physical Sciences University of Surrey University of Surrey Guildford, Surrey, GU2 7XH, UK Guildford, Surrey, GU2 7XH, UK 16th August 2010 August 2012 Supervised by:by: Dr Roger Peel Supervised Dr Helen Treharne © Akshat Ratanpal 2012 Peter Helland 2010
  2. 2. Investigation  into  Delegation  in  a  Federated  Environment   August  27,  2012     Abstract Identity delegation is the process of an entity authorizing another entity to use their identity information. Quite a lot of research of research has been done when dealing with delegation. But most of the researches cover only a limited scope of delegation. In this thesis we will be looking into the need for delegation, what are the technologies that support delegation and different types of delegation. Furthermore, the work will concentrate on person-to-person type of delegation, and taking that into context, a pre-existing model will be analyzed and evaluated. The work will concentrate on the architecture and the security protocol within the model. A new model for secure and dynamic delegation model will be proposed, which will provide secure and dynamic delegation framework for both within and beyond a Federated environment.2    
  3. 3. Investigation  into  Delegation  in  a  Federated  Environment   August  27,  2012     ACKNOWLEDGEMENTS I take this opportunity to thank my dissertation supervisor, Dr Helen Treharne, for her guidance and motivation during the course of this dissertation. Without her encouragement and motivation Iwould not have been able to achieve such an in-depth understanding of the subject. She was always there whenever I needed help and guided me through the challenging stages of the dissertation. I would like to dedicate this dissertation to my parents. Without their continuous support I would never have the life I have. Their sacrifices for their kids are my biggest motivation to succeed and I hope to one day make them proud. I would also like to thank my sister and my dog ‘Gappu’. My sister has always been my pillar of support and I thank her for being there always. Lastly, I would like to thank all the people who motivated me and supported me in any way during my masters and in completion of my dissertation. 3    
  4. 4. Investigation  into  Delegation  in  a  Federated  Environment   August  27,  2012    Table of Contents1   Introduction to the Dissertation ................................................................................... 8  1.1   Objectives:................................................................................................................................. 9  1.2   Structure of the Report ............................................................................................................ 10   1.2.1   Literature Review ............................................................................................................ 11   1.2.2   Overview of AVISPA ...................................................................................................... 11   1.2.3   Problem Analysis ............................................................................................................. 11   1.2.4   Modeling of Protocol ....................................................................................................... 11   1.2.5   Evaluation ........................................................................................................................ 11   1.2.6   Conclusion ....................................................................................................................... 12  2   Literature Review ........................................................................................................ 13  2.1   Online Identity: ....................................................................................................................... 13   2.1.1   What is online Identity? ................................................................................................... 14   2.1.2   How is Online Identity created? ...................................................................................... 14   2.1.3   How many Identities does Bob have?.............................................................................. 15   2.1.4   What is the problem? ....................................................................................................... 17  2.2   Identity Federation .................................................................................................................. 17   2.2.1   What is Identity Federation? ............................................................................................ 17   2.2.2   How does Identity Federation Work? .............................................................................. 17   2.2.3   What is Delegation/Identity Delegation? ......................................................................... 22   2.2.4   How does Identity Delegation work? .............................................................................. 23  2.3   Security Assertion Markup Language (SAML) ...................................................................... 23   2.3.1   What is SAML? ............................................................................................................... 23   2.3.2   When and why was SAML created?................................................................................ 24   2.3.3   Why SAML? .................................................................................................................... 25   2.3.4   What is SAML made up of? ............................................................................................ 25   2.3.5   Relation between SAML and Identity Federation ........................................................... 36  2.4   SAML and Identity Delegation ............................................................................................... 37   2.4.1   Scenario 1: ....................................................................................................................... 37   2.4.2   Scenario 2: ....................................................................................................................... 39   2.4.3   Scenario 3: ....................................................................................................................... 40  3   Overview of AVISPA................................................................................................... 42  3.1   Introduction: ............................................................................................................................ 42  3.2   AVISPA architecture and HLPSL: ......................................................................................... 44  4    
  5. 5. Investigation  into  Delegation  in  a  Federated  Environment   August  27,  2012     3.2.1   On-the-fly Model-Checker (OFMC): .............................................................................. 44   3.2.2   CL based Attack Searcher (CL-Atse): ............................................................................. 45   3.2.3   SAT Based Model-Checker (SATMC): .......................................................................... 45   3.2.4   Tree Automata-based Protocol Analyzer (TA4SP): ........................................................ 45  3.3   HLPSL Syntax: ....................................................................................................................... 46   3.3.1   Basic Roles: ..................................................................................................................... 46   3.3.2   Transitions: ...................................................................................................................... 47   3.3.3   Composed Roles: ............................................................................................................. 48  3.4   Basic Overview of Dolev-Yao Model: ................................................................................... 50  4   Problem Analysis ......................................................................................................... 54  4.1   Introduction: ............................................................................................................................ 54  4.2   Introduction to Scenario: ......................................................................................................... 54  4.3   Conceptual model: .................................................................................................................. 55   4.3.1   Entities: ............................................................................................................................ 56   4.3.2   Working: .......................................................................................................................... 57  4.4   Analysis: .................................................................................................................................. 60   4.4.1   Introduction:..................................................................................................................... 60   4.4.2   Advantages: ..................................................................................................................... 60   4.4.3   Attack Scenarios: ............................................................................................................. 62   4.4.4   Limitations: ...................................................................................................................... 69  5   A New Conceptual model ............................................................................................ 71  5.1   Introduction: ............................................................................................................................ 71  5.2   Review of Key requirements for a new model: ...................................................................... 71  5.3   Conceptual Model: .................................................................................................................. 72  5.4   New architectural components: ............................................................................................... 73   5.4.1   Privilege authorization directory: .................................................................................... 73   5.4.2   Credential conversion service: ......................................................................................... 74   5.4.3   Reputation framework: .................................................................................................... 74  5.5   Working of the Model: ............................................................................................................ 74   5.5.1   Steps in the model: ........................................................................................................... 75  6   Conclusions: ................................................................................................................. 80  6.1   A look Back: ........................................................................................................................... 80  6.2   Achievements: ......................................................................................................................... 81   6.2.1   Explore Identity Federation: ............................................................................................ 81   6.2.2   Explore SAML:................................................................................................................ 82   6.2.3   Test and Evaluation of Protocols: .................................................................................... 82   6.2.4   Conceptualization of a new model: ................................................................................. 82   5    
  6. 6. Investigation  into  Delegation  in  a  Federated  Environment   August  27,  2012    6.3   Conclusion: ............................................................................................................................. 83  7   Bibliography: ............................................................................................................... 84                                                                      6    
  7. 7. Investigation  into  Delegation  in  a  Federated  Environment   August  27,  2012          Figure 1: Structure of the Report ........................................................................................ 10  Figure 2: Online Identity from[5] ........................................................................................ 14  Figure 3: Online information sharing from[6] .................................................................... 15  Figure 4: Online Identity Mapping from [7] ........................................................................ 16  Figure 5: General Single Sign-on Use case from [3] .......................................................... 18  Figure 6: General Identity Federation Use Case from[3] ................................................... 19  Figure 7: Example of Usage of Facebook Connect from [10] ............................................. 21  Figure 8: Timeline of SAML till year 2007 .......................................................................... 24  Figure 9: Primary components of SAML obtained from [3] ................................................ 26  Figure 10: Example of a SAML assertion from [3] ............................................................. 28  Figure 11: Types of SAML Bindings .................................................................................... 31  Figure 12: SAML profiles .................................................................................................... 34  Figure 13: Additional SAML components from[3] .............................................................. 35  Figure 14: Scenario 1 .......................................................................................................... 38  Figure 15: Scenario 2 .......................................................................................................... 40  Figure 16: Scenario 3 .......................................................................................................... 40  Figure 17: Architecture of AVISPA from[15] ...................................................................... 44  Figure 18: Role definition obtained from[25]...................................................................... 47  Figure 19: Transition for Server (S) obtained from[25] ...................................................... 48  Figure 20: Role session obtained from [25] ........................................................................ 49  Figure 21: Declaration of role environment obtained from[25] ......................................... 50  Figure 22: Motivating Scenario obtained from[4] .............................................................. 55  Figure 23: Delegation Authorization Mediation obtained from[4] ..................................... 57  Figure 24: Delegated access interaction obtained from [4] ................................................ 59  Figure 25: MSC Attack Trace from OFMC tool .................................................................. 63  Figure 26: MSC attack trace from CL-Atse tool.................................................................. 64  Figure 27: MSC attack trace from OFMC........................................................................... 65  Figure 28: MSC attack trace from CL-Atse ......................................................................... 66  Figure 29: MSC attack trace from CL-Atse ......................................................................... 67  Figure 30: New delegated access interactions .................................................................... 75  Figure 31: Structural overview of the new model................................................................ 78         7    
  8. 8. Investigation  into  Delegation  in  a  Federated  Environment   August  27,  2012    1 Introduction to the Dissertation Online identities refer to the repository of information collected by identity providers orservice provider over time about a user, through a user’s interactions with these systems. A useronce registered with these systems requests for services offered by the services providers, byauthenticating herself to the system. The user identifies itself with the email-id or username and thechallenge that is posted by the system in the form of a password, or one time key. Once a user isauthenticated to these systems, the user is allowed to access the services that are being offered bythe service provider. With the growth in Internet and the exponential increase in the services beingoffered online, a user is made or asked to create multiple identities to access these services. A usercould have one identity for a service and a totally different identity for another service. The processof creating new identities for every different service makes it very difficult for a user to managehis/her identity. Not just a user, managing so many identities becomes very difficult even forservice provider and identity providers.The problem of creating and managing multiple identities of a user became a problem for all theentities involved in the interaction. From the user to the identity provider and to the serviceprovider who would offer his services once a user has been authenticated and creates an accountfor the user on its side. A user would end up having more than six to seven identities for thedifferent services that a user used. A solution has been devised and is being commonly used thesedays, i.e. Identity Federation.Identity federation is the concept of linking of users various identities and attributes stored acrossdifferent system. Identity federation allows a user to use a single or lesser number of identities toauthenticate. 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 toaccess all computers and systems where he has access permission, without the need to entermultiple passwords. Single sign-on reduces human error, a major component of systems failure andis therefore highly desirable but difficult to implement” [1]. SSO is just a technical part of the8    
  9. 9. Investigation  into  Delegation  in  a  Federated  Environment   August  27,  2012    whole concept of Federated identity management (FIdM). FIdM extends not just to the technicalaspect of security, but also to the non-technical aspects.Federated Identity Management (FIdM) has been described quite excellently by Zuo, Luo, Zeng etal. as “FIdM allows the use of same users Personal Identification Information (PII) across multipleorganizations within a federation. The PII includes user’s login names, user properties, and useridentity attributes.”[2] The technologies used for federated identity are SAML, OAuth andOpenID. I will be discussing SAML quite extensively in my dissertation.SAML (Security Assertion Markup Language)[3] is an open standard that has been managed bythe OSASIS security services technical committee. SAML is an open standard that allows foridentity information like, authentication and authorization across different domains. SAML allowsan identity provider to create a SAML assertion containing the information of a user, andcommunicate it to the service provider for the service provider’s authentication requirements.SAML assertions provide an easy and secure method of communicating user information acrossdifferent security domains.The increase in the number of web services on the Internet has also lead to an increase in theinstances wherein a user has to share her identity information with another entity. The sharingcould be with a service provider wherein; a service provider needs some identity information of auser before provisioning any services. This identity information sharing is called identitydelegation. Social networks and applications running on those platforms are a good example ofidentity delegation being used to provide users the services it needs. Quite a lot of research hasgone into identity delegation between a user, service provider and an identity provider. But notmuch has been talked about when a user delegates her identity to another user than a serviceprovider. 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 Ihad read. Japanese researcher, Hidehato Gomi, authored the paper. The paper [4], discussesidentity delegation among users. The paper also introduces a real life scenario wherein; a husbandand wife need to share their identity information with a service provider before a service could beprovided. The paper was an interesting read and motivated me further to read about Onlineidentities, Identity Federation, Identity delegation and SAML. My main motivation was to presentmy acquired knowledge of the subject and to come up with a new framework.1.1 Objectives: 9    
  10. 10. Investigation  into  Delegation  in  a  Federated  Environment   August  27,  2012    The objectives of the dissertation are as follows: 1. Overview of delegation in a Federated environment 2. Overview of the literature on Federation and Identity delegation. 3. Overview of Technologies that help support delegation in a federated environment 4. Review and analysis of a proposed model for secure and dynamic data access management using delegation. 5. Evaluating the security and validity of the protocol proposed, by testing it on a security protocol analyzer. 6. Present a new model or framework for delegation within and beyond the boundaries of Federation.1.2 Structure of the Report Introduction     Literature  Review   Overview  of  AVISPA   Problem  Analysis   A  new  conceptual  model   Conclusion     Figure  1:    Structure  of  the  Report  10    
  11. 11. Investigation  into  Delegation  in  a  Federated  Environment   August  27,  2012    This section of the report will talk about how the thesis will be structured and what all will becovered 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 theyused. 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 quiteextensively with some examples of how SAML supports Identity Delegation. Then we exploreSAML artifacts that support identity delegation.1.2.2 Overview of AVISPAThe literature will continue into the security analysis of things. We will have a detailed descriptionof the technology AVISPA, which is being used to map the protocol and find the possible attackson 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 usedto 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 onDynamic Identity Delegation Using Access Tokens in Federated Environments. A detailed analysiswill be done of the conceptual model proposed by the author. Key points and assumption from thepaper 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 onAVISPA. 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. Acritical analysis of the attacks and possible improvements in protocol will be discussed in this 11    
  12. 12. Investigation  into  Delegation  in  a  Federated  Environment   August  27,  2012    chapter. A new and improved conceptual model will be proposed. A critical analysis will beperformed of the newly proposed model. The next part of the chapter will include a review ofprevious research on identity delegation and how concepts from those researches can beincorporated 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 concludingremark on the results obtained.12    
  13. 13. Investigation  into  Delegation  in  a  Federated  Environment   August  27,  2012    2 Literature ReviewThis chapter covers the theoretical background of the dissertation. In the section 2.1 we will startoff by discussing online identities and the problem associated with multiple identities. In section2.2 we will look into how the previous problem is solved using Identity Federation. This sectionwill also cover the basic idea of Federation and how it is implemented using few examples. Withinthis section we will touch upon delegation but will not dwell into more details. In section 2.3, wewill look at how SAML helps provide a framework for Identity Federation. We will look at thestructure and components of SAML that provide features that enable entities to share credentialssecurely within a federated environment.2.1 Online Identity:   13    
  14. 14. Investigation  into  Delegation  in  a  Federated  Environment   August  27,  2012    2.1.1 What is online Identity? Online Identity as the name suggests is the identity a user uses to identify itself to differentonline services. Figure  2: Online Identity from[5]So what really is Online Identity? Online identity is basically the repository of informationcollected 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 asonline identity.For example, a user Bob has an account on the social networking site Facebook1. Bob authenticatesitself to access Facebook by giving his username or email-id and then a password. These twoelements, email ID or password form just the base of user bob’s online identity. Once Bob haslogged in to Facebook and adds more information to his account for instance, his phone number,                                                                                                                1  http://www.facebook.com  14    
  15. 15. Investigation  into  Delegation  in  a  Federated  Environment   August  27,  2012    address, date of birth, place of birth, favorite color etc. forms the core of Bob’s identity. It’s thecollection of this information and other information, like bank account details, social securitynumbers; passport; number; height; weight etc. form the crux of Bob’s online identity. It’s thiscollection 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 regularbasis. With each interaction, some data is generated about a user. This data is collected over timeby 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. Infact, Bob uses many different web services. For paying his electricity bills, bob has signed up foronline billing by creating an identity at the electricity company. For his emails and chats Bob usesGmail services. Before Bob could use Gmail’s services, Bob has to create an account and share hisinformation with Gmail too. To pay his telephone and mobile bills, Bob has signed up online withhis service provider. The service provider has asked Bob to create an account at the SP’s web 15    
  16. 16. Investigation  into  Delegation  in  a  Federated  Environment   August  27,  2012    application and input his personal information. For travel, hotel and transport booking, Bob hascreated another account with a different portal. The portal asks the same thing as previouslydiscussed web applications, i.e. Bob shares his personal information with the application beforeBob is allowed to access any services. As we can see, Bob has to create multiple identities atmultiple service providers to be allowed to access any of the services. An aggregation of thedifferent online identities that we create and how they are mapped to different services will helpsus understand the problem that we are dealing with; Figure  4: Online Identity Mapping from [7]16    
  17. 17. Investigation  into  Delegation  in  a  Federated  Environment   August  27,  2012    2.1.4 What is the problem? The problem is that Bob or User has to share his personal information with multipleservice providers. The user has to create a unique identity with each service provider. The task canbe tedious. Above all, there are security implications to information sharing with so many differentservice providers. First, not all service providers have a standardized security policy on how tomanage a user’s information. Secondly, some service providers outsource their data managementprocess to third parties. Which may or may not follow the strict security policies of the serviceprovider that the user has trusted with his personal information. So how does a user avoid thetedious task of creating multiple identities and be able to trust the service provider with hispersonal information. The solution is Identity Federation.2.2 Identity Federation2.2.1 What is Identity Federation? “A federated identity in information technology is the means of linking a personselectronic 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. Thishelps the users to reduce the effort of creating multiple identities for each service rendered. It alsoallows Identity management systems and service provider to make Identity management easier.Identity Federation or commonly known as Federated Identity Management has been excellentlydefined 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, userproperties, 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 thata user may require. Due to the nature of the design of the system, there is pre-established trustbetween the SP and IdP, which allows quick and easy access of services to the user. This concept 17    
  18. 18. Investigation  into  Delegation  in  a  Federated  Environment   August  27,  2012     allows the user not to register or login at different web services, instead, use the same identity across different web services. A user could be registered with only one IdP or SP and if the there is a pre-established trust between these entities then user can be allowed to authenticate himself through a single identity across multiple systems. The working of the Identity federation and how IdP and SP share user identity information in Single Sign-On (A sub domain of Identity Federation) is show in figure 4: Source web site: airline.example.com Authenticate information 1 Identity Business agreement 2 Access Destination web site: protected cars.example.co.uk resource SSO-usecase Figure 2: General Single Sign-On Use Case365 This high-level descriptionFigure  5: General Single Sign-on Use case from [3] before accessing a indicated that the user had first authenticated at the IdP366 protected resource at the SP. This scenario is commonly referred to as an IdP-initiated web SSO367 scenario. While IdP-initiated SSO is useful in certain cases, a more common scenario starts with a user368 visiting an SP site through abe seen how a user has to authenticate at the IdP, which in this case special In the figure above it can browser bookmark, possibly first accessing resources that require no is369 authentication or authorization. In a SAML-enabled deployment, when they subsequently attempt to airline.example.com, and the IdP then shares the users information with the SP, which in this case370 access a protected resource whomSP, the SP will send the for some restricted resources or services. is cars.example.com, from at the the user has requested user to the IdP with an authentication request371 in order to have the user log in. Thus this scenario is referred to as SP-initiated web SSO. Once logged in,372 the is to cannoted that this type ofthat can be used by the SP topossible the users access a previous It IdP be produce an assertion information sharing is only validate if there has been rights to the373 protected resource. SAML V2.0 supportsparties involved in the user’s information sharing. business agreements between the two both the IdP-initiated and SP-initiated flows.374 SAML supports numerous variations on these two primary flows that deal with requirements for using375 The previous example demonstrated how a users information is shared between two entities that various types and strengths of user authentication methods, alternative formats for expressing federated376 identities, use of different bindings for transporting the protocol messages, inclusion of identity attributes, have pre-established trust relationship. But, Identity Federation Management goes much beyond377 etc. Many of these options are looked at in more detail in later sections of this document. 18  378 3.3   Identity Federation Use Case379 As mentioned earlier, a users identity is said to be federated between a set of providers when there is an
  19. 19. Investigation  into  Delegation  in  a  Federated  Environment   August  27,  2012    that. The next scenario that I have considered in my research on Identity federation involvesmultiple 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 johndat airlines.example.com, cars.example.com and hotels.example.com respectively. The three serviceproviders have come to an agreement and allow a user to use the same identities across the threeservice providers. The user John Doe hasn’t yet federated his identities across these three serviceproviders. Figure 3: General Identity Federation Use Case Prepare to rent car logged in Prepare to book hotel logged in Book flight logged in as jdoe; accept offer of as johnd; accept offer of as johndoe federation with airline.example.com federation with airline.example.com airline.example.com cars.example.co.uk hotels.example.ca No correlation of Johns activities across these sites Agree on azqu3H7 for referring to John (neither knows the local ID used on the other side) Agree on f78q9c0 for referring to John (neither knows the local ID used on the other side) IDFed-usecase 427 The processing sequence is as follows: 428 1. John books Figure  6: airline.example.com using his johndoe user account. a flight at General Identity Federation Use Case from[3] 429 2. John then uses a browser bookmark or clicks on a link to visit cars.example.co.uk to reserve a car. 430 This site sees that the browser user is not logged in locally but that he has previously visited their IdP 431 partner site airline.example.com (optionally using the new IdP discovery feature of SAML V2.0). So 432 cars.example.co.uk asks John if he would like to consent to federate his local cars.example.co.uk 433 identity with airline.example.com. 434 3. John consents to the federation and his browser is redirected back to airline.example.com where the 435 site creates a new pseudonym, azqu3H7 for Johns use when he visits cars.example.co.uk. The 436 19   pseudonym is linked to his johndoe account. Both providers agree to use this identifier to refer to John   437 in subsequent transactions. 438 4. John is then redirected back to cars.example.co.uk with a SAML assertion indicating that the user 439 represented by the federated persistent identifier azqu3H7 is logged in at the IdP. Since this is the first 440 time that cars.example.co.uk has seen this identifier, it does not know which local user account to
  20. 20. Investigation  into  Delegation  in  a  Federated  Environment   August  27,  2012    1) John first logs in at airline.example.com and books his flights.2) Now John decides to book a car for his travel. So he follows a link on theairline.example.com page and gets to the page of cars.example.com. The cars.example.com sitesees that the user hasn’t logged in, but has come from a site that is a federated partner. So the siteasks 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 anidentity provider than a service provider. It creates a pseudonym for John Doe and sends it tocar.example.com. This ensures that the information provided by the user to cars.example.comcomes from a trusted source. Secondly, it lays down the foundation for user being allowed to linkhis local identity with his identity provider identity.4) The aforementioned scenario happens once the IDP (airline.example.com) creates apseudonym and sends it to SP (cars.example.com) to identify the user. The SP still has no way ofknowing for sure that the user requesting the services is a registered user or not, and to whichidentity 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 tothe user’s account at the SP. This allows the user to be able to use just a single login session at theIDP 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 onhotels.example.com is taken back to airline.example.com and a pseudonym is created linking theusers 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) andwould able to use the services offered by both hotels.example.com and cars.example.com withouthaving to login at each service provider.[3]The previously mentioned scenario is just one type of identity federation wherein the user alreadyhas local accounts and is then allowed to link those accounts with his main account at the identityprovider. 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 delegatethe task of booking of hotels and renting cars to this IdP, which would act as a service provider inthe new scenario. More about delegation would be discussed in section 2.2 and 2.3. Another20    
  21. 21. Investigation  into  Delegation  in  a  Federated  Environment   August  27,  2012    scenario that we are going to discuss is wherein the user does not even have to have local accountspreviously established at service providers. Instead, the user can just use his unique identity createdat an Identity Provider to authenticate himself at the service providers that are in federation withthe identity provider. The next example is very similar to the issues we will be discussing inchapter 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 providercalled Facebook Connect [9]. Facebook connect allows users to use their Facebook identity or theinformation 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 usethe users Facebook identity as the means to identify the user. Facebook connect is available onthousands of websites. The user can have control over the information it shares with these sites bychanging his privacy settings at his single Facebook account. The change in settings is then appliedat all the sites where the user has used his Facebook identity as a means of authentication. [6] Figure  7: Example of Usage of Facebook Connect from [10] 21    
  22. 22. Investigation  into  Delegation  in  a  Federated  Environment   August  27,  2012    Facebook Connect helps reduce the work of a user, by completely eliminating the tedious job ofregistering at each site to access the services offered. It also gives the user more control over thetype of information that it shares with a service provider. Also, Identity federation using FacebookConnect greatly reduces the identity management tasks of the service provider. The serviceprovider 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 ofmismanagement of users information like, stealing of personal data, theft of username andpassword, and accidental or intentional modification of users identity information, and sharing ofusers personal information with an un-trusted third party.After reviewing identity delegation we have realized that a single authentication session can allowa user to have access to various services offered by multiple service providers that are in federationwith the identity provider.With the growing number of services shifting online has made the job of a user easier and difficultat the same time. Services like voter registration, income tax filing, events registration, registeringfor health or motor insurance, employment services, pensions or funds tracking can all be doneonline these days. But, there are times where a user does not have the knowledge or the time toperform these tasks. So a user needs to hire a third party that would do these tasks on the usersbehalf. So how does that happen in a federated or a non-federate environment? What is such aprocess called?2.2.3 What is Delegation/Identity Delegation? “Delegation is the process whereby an identified entity confers a mandate to anotheridentified entity”[11]. It is basically the process wherein, an entity known as the delegator gives theauthority to another entity known as the delegatee to perform some actions on his behalf at aservice provider [12].The three primary entities in identity delegation procedure according to Peeters et al. [12] are asfollows:- Delegator: It is the entity that gives the right to another entity to perform privilege actionson his behalf.- Delegatee: It is the entity that receives the right from a delegator to perform some privilegeactions on the behalf of the delegator.22    
  23. 23. Investigation  into  Delegation  in  a  Federated  Environment   August  27,  2012    - Service Provider: Is the entity that provides the services to the delegatee on the behalf ofthe 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 arepassed 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 anddetails of the technology that helps support identity delegation and Identity federation in a secureway.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 committeeof Organization for the Advancement Structured Information Standards (OASIS). SAML allowsfor entities to share information regarding a user’s permissions, attributes, and identity with otherentities in a secure and seamless manner. SAML is a flexible protocol that can be extended orcustomized for other existing secure communications standards like the liberty alliance, theshibboleth project, and OASIS web services security [13]. Most of these standards have alreadyincorporated SAML as a technology in some way or the other in their standards 23    
  24. 24. Investigation  into  Delegation  in  a  Federated  Environment   August  27,  2012    2.3.2 When and why was SAML created? Figure 7 gives a historic timeline of SAML •  OASIS  SSTC  committe  meet  for  the  Pirst  time   2001  Jan   •  SAML  v1.0  was  announced  as  an  OASIS   2002  Nov   standard   •  Liberty  releases  ID-­‐FF  1.1   2003  Apr   •  SAML  v1.1  is  Introduced   2003  Sep   2003  Sep   •  Liberty  contributes  ID-­‐FF  to  OASIS   •  Liberty  ID-­‐FF  v1.2  is  Pinalized   2003  Nov   •  SAML  v2.0  is  announced   2005  Mar   •  Errata    approved  for  SAML  v2.0   2007  Jul   Figure  8: Timeline of SAML till year 200724    
  25. 25. Investigation  into  Delegation  in  a  Federated  Environment   August  27,  2012    Quite a few improvements and additions have been made to SAML since its inception. This hasoffered 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 adoptionand popularity of SAML:1. Certain implementations of SAML can make the Identity Provider more responsible foridentity management than the service provider.2. SAML enables Single Sign-on for users. It also allows for information customization whensharing 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 managingidentity information.4. Above all, SAML is platform neutral. So it can be implemented by different services withdifferent architectures. For example, SAML has been implemented to enable Single Sign-on anddelegation 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 addfurther functionality to SAML.                                                                                                                2  http://www-­‐01.ibm.com/software/websphere/  3  http://www.microsoft.com/en-­‐gb/directory/cloud.aspx   25    
  26. 26. 476 SSO profile. Profiles typically define constraints on the contents of SAML a477 bindings in order to solve the business use case in an interoperable fashion478 Profiles, which do not refer to any protocol messages and bindings, that def479 information using assertions in waysn  a  Federated  Environment   Investigation  into  Delegation  i that align with a number of common us480 LDAP directories, DCE). August  27,  2012  481 Figure 4 illustrates the relationship between these basic SAML concepts.   Profiles Combinations of assertions, protocols, and bindings to support a defined use case Bindings Mappings of SAML protocols onto standard messaging and Authentic communication protocols Detailed and strength Protocols Requests and responses for obtaining assertions and doing identity management Me Configur identity and Assertions Authentication, attribute, and entitlement information Figure 4: Basic SAML Concepts Figure  9: Primary components of SAML obtained from [3]483 Two other SAML concepts are useful for building and deploying a SAML en484 • Metadata defines a way to express and share configuration informatio485 instance, an entitys supported SAML bindings, operational roles (IDP,486 information, supporting identity attributes, and key information for encr   sstc-saml-tech-overview-2.0-cd-02 Copyright© OASIS® 2008. All Rights Reserved. 26    
  27. 27. Investigation  into  Delegation  in  a  Federated  Environment   August  27,  2012    2.3.4.1 Assertions: Assertions can be defined as the means of an entity to convey security information aboutanother entity. SAML does it in the form of statements that are part of the message. The statementscontain information like an entity’s name, group, ID, and any other relevant information. Forexample, if an entity, like an identity provider wants to convey information about one of its user’snamed John Doe, to a service provider. Then the identity provider can use SAML assertions, whichmay include user’s information like his name John Doe, email-ID as john.doe@example.com andgroup “engineers”. In the previous scenario John Doe is the subject of the assertion. Everyassertion contains a subject of assertion, conditions for assertion and assertion statements.There are primarily three types of statements in a SAML assertion:2.3.4.1.1 Authentication Statements: These statements contain information regarding how and when the subject of the assertion was authenticated.2.3.4.1.2 Attribute Statements: Contain or convey the attribute information about a subject of the assertion. For example, name ‘John Doe’ is part of the ‘engineering’ group.2.3.4.1.3 Entitlement Information: They define the ‘if’ and ‘what’ the subject of the assertion is entitled to do.An example of how a SAML assertion looks like is given in figure 10: 27    
  28. 28. SAML-component-nesting Figure 5: Relationship of SAML Components Investigation  into  Delegation  in  a  Federated  Environment   August  27,  2012     625 4.4.2 Assertion, Subject, and Statement Structure 1: <saml:Assertion xmlns:saml=”urn:oasis:names:tc:SAML:2.0:assertion” 2: Version="2.0" 3: IssueInstant="2005-01-31T12:00:00Z"> 4: <saml:Issuer Format=urn:oasis:names:SAML:2.0:nameid-format:entity> 5: http://idp.example.org 6: </saml:Issuer> 7: <saml:Subject> 8: <saml:NameID 9: Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"> 10: j.doe@example.com 11: </saml:NameID> 12: </saml:Subject> 13: <saml:Conditions 14: NotBefore="2005-01-31T12:00:00Z" 15: NotOnOrAfter="2005-01-31T12:10:00Z"> 16: </saml:Conditions> 17: <saml:AuthnStatement 18: AuthnInstant="2005-01-31T12:00:00Z" SessionIndex="67775277772"> 19: <saml:AuthnContext> 20: <saml:AuthnContextClassRef> 21: urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport 22: </saml:AuthnContextClassRef> 23: </saml:AuthnContext> 24: </saml:AuthnStatement> 25: </saml:Assertion> Figure 6: Assertion with Subject, Conditions, and Authentication Statement 626 Figure  10: Example of a SAML assertion from [3] 627 Figure 6shows an XML fragment containing an example assertion with a single authentication statement. 628 Note that the XML text in the figure (and elsewhere in this document) has been formatted for presentation 629 purposes. Specifically, while line breaks and extra spaces are ignored between XML attributes within an 630 XML element tag, when they appear between XML element start/end tags, they technically become part of 631 the element value. They are inserted in the example only for readability. sstc-saml-tech-overview-2.0-cd-02 Mar 25,2008 Copyright© OASIS® 2008. All Rights Reserved.28    
  29. 29. Investigation  into  Delegation  in  a  Federated  Environment   August  27,  2012    The figure shows idp.example.com as the issuer of the assertion. The subject of the assertion that isgiven by NameID is j.doe@example.com and the conditions for the assertion are stated under theConditions 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 identityprovider 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 particularuser.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’swith 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 changedduring the communication process.2.3.4.2.6 Artifact Resolution Protocol: Defines how a SAML message would be requested and retrieved using an SAMLArtifact. An Artifact is defined as “A 42-byte, hex-encoded ID that references an assertion storedwith the session server at the producer. The artifact enables the SAML Affiliate Agent to retrievean assertion document from the producer.”[14] 29    
  30. 30. Investigation  into  Delegation  in  a  Federated  Environment   August  27,  2012    2.3.4.3 Bindings: SAML bindings as the name suggests determine the bindings of SAML messages todifferent transport protocols. Bindings determine how SAML messages are carried over varioustransport protocols. There are six different types of bindings defined.2.3.4.3.1 HTTP Redirect Binding: Defines how SAML messages are carried in HTTP redirect request.2.3.4.3.2 HTTP POST Binding: Defines how SAML messages can be transported in an HTTP POST request.30    
  31. 31. Investigation  into  Delegation  in  a  Federated  Environment   August  27,  2012     HTTP   Redirect   SAML   HTTP   URI   Post   Reverse   HTTP   SOAP   Artifact   SAML   SOAP   Figure  11: Types of SAML Bindings 31    
  32. 32. Investigation  into  Delegation  in  a  Federated  Environment   August  27,  2012    2.3.4.3.3 HTTP Artifact Binding: Defines how an SAML artifact is transported in an HTTP request.2.3.4.3.4 SAML SOAP Binding: Defines how SOAP messages are used for communicating SAML messages.2.3.4.3.5 Reverse SOAP (PAOS) Binding: Defines the communication within an HTTP/SOAP message that allows for rolereversal. For example, in a request, the client could play the role of the service provider and theservice 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 ResourceIdentifier).2.3.4.4 Profiles: OASIS’s SSTC have defined eight different SAML profiles. These profiles define howSAML’s assertion, bindings and protocols combine for a particular scenario. Profiles offers sort ofinteroperability of the previously discussed components of SAML for a particular use case orscenario. For example, one of SAML’s profiles, i.e. Web Browser SSO profile defines how aSAML 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 arecombined with SAML assertions and different combinations of SAML bindings like HTTPRedirect, HTTP artifact and HTTP POST bindings to achieve single sign-on.2.3.4.4.2 Enhanced Client and Proxy (ECP) Profile:32    
  33. 33. Investigation  into  Delegation  in  a  Federated  Environment   August  27,  2012     Defines a unique scenario wherein, the client may or may not be part of thecommunication. Instead, there could be a proxy filling up the role of client in the communicationprocess. 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 usermight have visited previously. An example of where such a profile might be created and used hasbeen previously discussed in the second example of identity federation use cases. Where theservice provider cars.example.com discovers that the user’s request or the user had visited itsfederation 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 assertionsusing unique identifiers. The process basically involves the process of first checking for an existingof an assertion based upon an identifier. If it exists, then send an appropriate response to thesender.2.3.4.4.6 Artifact Resolution Profile: The profile defines how artifact resolution is done over a SAML SOAP binding toretrieve the message referred to by the artifact. 33    
  34. 34. Investigation  into  Delegation  in  a  Federated  Environment   August  27,  2012     Web   Browser   SSO   Name   IdentiPier   ECP   Management   Identity   Name  IdentiPier   Provider   Mapping   Discovery   Artifact   Single   Resolution   Logout   Assertion   Query/   Request   Figure  12: SAML profiles34    
  35. 35. onents that, when put together, allow a number of use cases to bepermit transfer of identity, authentication, attribute, and nomous organizations that haveelegation  in  a  Federated  Etrust relationship. Investigation  into  D an established nvironment  he structure and content of both assertions and protocol messages August  27,  2012     ut a principal that an asserting party claims to be true. The valid are defined by the SAML assertion XML schema. Assertions areased on a request of some sort from a relying party, although undercan be delivered to a relying party in Profile: 2.3.4.4.7 Name Identifier Management an unsolicited manner. SAMLhe SAML-defined requests the protocol name identifier management protocol, is used with The Defines how and return appropriate responses.ges are defined by the SAML-defined protocol XML schema. various SAML bindings.unication or messaging protocols (such as HTTP or SOAP) areages between participants is defined by the SAML bindings.sfy a particular business use case, for example the Web Browseronstraints on the contents of SAML assertions, protocols, and 2.3.4.4.8 Name Identifier Mapping Profile: use case in an interoperable name identifier mapping protocol uses a synchronous binding “Defines how the fashion. There are also Attributeocol messages SOAP”[3]. such as and bindings, that define how to exchange attribute at align with a number of common usage environments (e.g. X.500/ween theseThe SAML components discussed above are also supported by two other SAML components that basic SAML concepts. support, and are useful in implementing a SAML environment are Authentication Context and Metadata.ons, protocols,defined use cases protocols aging and Authentication Contextrotocols Detailed data on types and strengths of authenticationsonses for and doingement Metadata Configuration data for identity and service providersnsbute, andmation Figure  13: Additional SAML components from[3] SAML-conceptsigure 4: Basic SAML Concepts 2.3.4.5 Authentication Context: Authentication Context is a component of SAML. But it has its separate XML format toor building convey the information within SAML environment: used to convey information and deploying a it. Authentication Context is basically regarding the authentication mechanism used by a SAML entity. For example, if a service providerss and share configuration information between SAML parties. For 35  AML bindings, operational roles (IDP, SP, etc), identifier  ttributes, and key information for encryption and signing can be
  36. 36. Investigation  into  Delegation  in  a  Federated  Environment   August  27,  2012    requires to know from the identity provider the method of authenticating a user. Then the identityprovider can provide the information in form of an XML message to convey information likesimple username-password authentication or two-factor authentication. It is used as an assertion toshare 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, themetadata components are used to convey information regarding certain aspects of a SAML entitiesimplementation of its SAML environment. It basically gives the information regardingconfiguration of SAML entities like an SP or an IDP. For example, if in a message some sort ofhashing has been used then metadata is used to communicate the type of hashing algorithm usedfor 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 wherewe introduced identity federation with an example of single sign-on. We can see that SAMLcomponents like Web Browser Single sign-on profile with a protocol like Authentication requestprotocol 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 almostcomplete SAML Single Sign-On (SSO) environment. Hence, different SAML components can becombined together in different ways to form a SAML based environment depending on a particularuse case. Similar to the Single Sign-On example of Identity federation, we implement the example1 discussed in the section 2.2.2 using SAML. In that example we can use different combinations ofSAML assertions with SAML protocols like Authentication request, Name Identifier Mapping,Name Identifier Management, and Assertion Query and Request protocols, with SAML profileslike Identity provider discovery profile or Name Identifier Management profile or Name identifiermapping profile to enable identity federation in the example discussed. In the scenario, SAMLassertions would contain information regarding the user, SP, IDP. They would also containpseudonym 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 learnabout the IDP that a user might have previously visited. All of this could be done very easily usingsimple a browser and regular HTTP POST request. Hence, we see how SAML can be used toenable a secure and privacy ensuring Identity Federation Environment. Now in the next part wewill discuss more about Identity Delegation and how SAML can be used and has been used toenable Identity Delegation in an Identity Federation environment.36    
  37. 37. Investigation  into  Delegation  in  a  Federated  Environment   August  27,  2012    2.4 SAML and Identity Delegation This section of the documents will be dedicated to discussing the different types ofcommonly adopted delegation models. These models will be analyzed with SAML as theunderlying 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 byservice provider number 2. But due to lack of knowledge of how to perform the particular task, theclient delegates the task to service provider 1 that has expertise in performing tasks on behalf ofclients on service provider 2. So, the client needs to delegate its task to a service provider. 37    
  38. 38. Investigation  into  Delegation  in  a  Federated  Environment   August  27,  2012     Figure  14: Scenario 1  2.4.1.1 Working:2.4.1.1.1 Step 1: The delegator sends a request to the Security Token service to generate a SAML tokenfor delegation purposes.2.4.1.1.2 Step 2: The token generation service generates a token for the task of delegation, with thesubject as the ‘Delegator’. The token may contain other attributes about a subject like the groupname, email-ID etc. The token generated may or may not be signed by the issuer of the token. Inmost 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 maycontain all the information required and the SP1 does not have to send the token to the tokengeneration service for further processing. In the second scenario, the token received is sent to the38    
  39. 39. Investigation  into  Delegation  in  a  Federated  Environment   August  27,  2012    token generation service to allow SP1 to authenticate itself and subsequently be allowed to act asthe delegator for the particular action. The original token and the newly generated token may bothhave some conditions defined in the token. The conditions may state the time of assertion, the taskto 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 onthe behalf of the Delegator. The SP1 performs the specified tasks on SP1 and passes on the resultto the Delegator.2.4.1.1.6 Note: <saml:condition> element is used as part of the assertion to state the conditions forassertion. 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 directdelegation 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 auser needs to use a service offered by a service provider. For example, the service provider offersusers to able to check their credit record and advice them on the type of insurance or loans a usercan go for depending on their economic records. The service provider asks the user to allow it tohave access to users personal information like, past loan, current loans, credit limit, bank accountinformation, investments made, etc. The scenario is quite similar to scenario 1 previouslydiscussed. The only difference being, that the user will create an assertion consisting of delegationof 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 wontbe 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 thepurpose of accessing information at the issuer of the SAML token, i.e. IdP. In this scenario, the IdPmay put extra conditions and restriction on the allowed access to user personal information by theservice provider depending upon the user’s privilege level. This is done to restrict the chances ofany malicious activity on the part of the service provider. The transaction can also be monitored bythe IdP to keep a record of the transaction for future use, if there is a dispute of any kind.The following figure will give a sketch of the communication that would take place. 39    
  40. 40. Investigation  into  Delegation  in  a  Federated  Environment   August  27,  2012     Figure  15: Scenario 22.4.3 Scenario 3: Figure  16: Scenario 340    
  41. 41. Investigation  into  Delegation  in  a  Federated  Environment   August  27,  2012    The scenario above, scenario 3 hasn’t been much discussed and researched when it comes todelegation. The above scenario is what we will be analyzing and discussing in the remainingsections 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 torequest user 1 to hand over his information to user 2 in a form of delegation, as user 2 needs it for aservice at the SP. The user 1 authenticates itself and request for a delegation token to be generatedwhich will be passed to the SP via the user 2 for access to user 1’s personal information at theidentity provider (IdP). The scenario above will be looked into great detail, analyzed, evaluatedand solution on how to make this feasible and secure will be discussed in the next sections of thisdissertation. 41    
  42. 42. Investigation  into  Delegation  in  a  Federated  Environment   August  27,  2012    3 Overview of AVISPA  3.1 Introduction: According to the AVISPA package user manual [15], AVISPA (Automated Validation ofInternet Security Protocols and Applications) is a tool designed to automate the procedure ofvalidating the security of Internet security protocols and applications. AVISPA offers tools andapplications for users to design their own security protocols or applications and validate them aswell.Apart from AVISPA, there are quite a few other excellent security protocol analysis tools availableto a designer. The following is a list of some of the tools available: 1. CASPER4[16] was designed by Gavin Lowe at Oxford University Computing Laboratory, Oxford University. It is an easy to use tool that uses text input in the form of a .spl file and returns a textual output of attacks found by the tool. The input program is very easy to write and understand. The tool compiles the input programs into CSP mode, which are then used as input for FDR[17]. As FDR can only deal with finite states or instances, this tool is used for only limited number of instances of the entities participating in the communication. Also, FDR is software that requires a license. It is an infeasible solution if the tool is used just once for a limited period of time. 2. ProVerif 5[18], is an excellent tool that like AVISPA uses the DY model to test the security of protocol specified by the user. It is slightly more complicated to write input programs in ProVerif as compared to AVISPA or CASPER. The tool tests security for the same parameters as AVISPA. For example, it can test the protocol based upon secrecy,                                                                                                                4  http://www.cs.ox.ac.uk/gavin.lowe/Security/Casper/  5  http://www.proverif.ens.fr  42    
  43. 43. Investigation  into  Delegation  in  a  Federated  Environment   August  27,  2012     authentication, strong secrecy, etc. The program to describe the protocol is slightly more complex, and needs a thorough understanding of the protocol syntax before a user can describe a protocol for ProVerif. A ProVerif output gives an excellently detailed output report. The report describes in detail about the attack trace if there is any. 3. Another excellent tool that can be used for security analysis of protocols is Maude- NPA6[19]. It is an excellent easy to use tool with a Graphical User Interface (GUI). The GUI allows for easy loading and execution of security protocols. It also allows users to generate attack trace tree. The user can then select the particular node of the attack tree to get further details on the weakness and attack trace. The tools offers the designer to specify some algebraic properties regarding entities and their relationships, to narrow down the possibilities of the type of attack a designer is looking for. It is a good tool if a designer is looking for specific attacks, but for general attack descriptions, it works similarly to any other tool.All the tools offer good results in evaluating the security of protocols. Some of them have easy toprogram protocol description like, AVISPA and CASPER. And some offer excellent graphicaldescription of the attack trace, for example, AVISPA and Maude-NPA. But none of the above toolexcept AVISPA incorporate four different other tools as part of the analysis process. The four toolsof AVISPA will be discussed in section 3.2. These tools give AVISPA a much broader analysisframework, as the validation on the protocol can be done on four different conditions of thecommunication process. These conditions or states are defined within the tool, so during theanalysis process, they all consider the same input file but test for four separate conditions of theprotocol run. AVISPA also offers a free to use Web-Interface7, which allows users to simplyupload their protocols defined in HLPSL format and then test it for all the tools or select any toolthat the user wants to test the security of their protocol against. The web tool also gives users atextual and visual attack trace for a protocol. Hence, simplicity of use of AVISPA and featuresoffered by the tool made it the tool of choice for the dissertation. In the following sections we willlook at AVISPA in much detail.AVISPA requires that security protocol to be written in HLPSL (High-Level ProtocolSpecification Language). AVISPA has been created by the joint efforts of Information Securitygroup at ETHZ (Zurich, Switzerland), Siemens AG (Munich, Germany), Artificial IntelligenceLaboratory at DIST (University of Genova, Genova, Italy), and the CASSIS group INRIALorraine (LORIA, Nancy, France).                                                                                                                6  http://maude.cs.uiuc.edu/tools/Maude-­‐NPA/  7  http://www.avispa-­‐project.org/web-­‐interface/basic.php   43    
  44. 44. Investigation  into  Delegation  in  a  Federated  Environment  2 User Section August  27,  2012    This section describes architectureto use the AVISPA tool: to specify protocols in HLPSL, 3.2 AVISPA the easiest way and HLPSL:then to run the avispa script for analysing it. High−Level Protocol Specification Language (HLPSL) avispa script file Translator HLPSL2IF Intermediate Format (IF) On−the−fly CL−based SAT−based Tree Automata−based Model−Checker Attack Searcher Model−Checker Protocol Analyser OFMC AtSe SATMC TA4SP Output Format (OF) Figure  17: Architecture of AVISPA from[15] Figure 1: Architecture of the AVISPA tool v.1.1 The figure above shows the architecture of the AVISPA tool. The protocol written in HLPSL is translated by the tool into an Intermediate Format. IF is a lower-level language, that is fed directly to the back-end applications for analysis and validation. The four Back-end systems2.1 used to analyze aProtocols: OFMC, AtSe, SATMC, and TA4SP. Specifying protocol are, HLPSLProtocols to be studied Model-Checker (OFMC): specified in HLPSL (standing for High 3.2.1 On-the-fly by the AVISPA tool have to beLevel Protocols Specification Language), and written in a file with extension hlpsl.This language is basedet al. [20] and hisroles for three comprising of participant role, and composition David basin on roles: basic team of representing each himself, Sebastianroles for representing scenarios offrom theroles. Each role is independent from Zurich, Zurich, M ̈odersheim, and Luca Vigan`o basic Department of Computer Science, ETH the others, getting Switzerland designed the OFMC tool. The motivation and purpose of the tool was to design a toolsome initial information byprotocols for infinite number of state spaces and consider the intruder that would check security parameters, communicating with the other roles by channels. In this section, we present the syntax of HLPSL and some guidelines for HLPSL beginners. 44    2.1.1 HLPSL Syntax The syntax of HLPSL is detailed in the following, using the standard

×