providing identification services to external entities ... · providing identification services to...

Providing Identification Services to External Entities using SAML

N I K L A S M Ö R N E S T E N

Master of Science Thesis Stockholm, Sweden 2011

Providing Identification Services to External Entities using SAML

N I K L A S M Ö R N E S T E N

Master’s Thesis in Computer Science (30 ECTS credits) at the School of Computer Science and Engineering Royal Institute of Technology year 2011 Supervisor at CSC was Douglas Wikström Examiner was Johan Håstad TRITA-CSC-E 2011:137 ISRN-KTH/CSC/E--11/137--SE ISSN-1653-5715 Royal Institute of Technology School of Computer Science and Communication KTH CSC SE-100 44 Stockholm, Sweden URL: www.kth.se/csc

AbstractThis project investigates approaches for implementing a method for pro-viding identification services to external entities using SAML. SAMLattempts to provide standardized means of exchanging authenticationdata between multiple parties. By implementing support for SAMLboth so-called service providers and identity providers can reach a largenumber of other entities that have done the same. An evaluation ofdifferent SAML-features and SAML-libraries was performed in order toproduce a prototype that is described in this report. The result of theprototype is a system that allows a user to log in to external websites us-ing existing identification infrastructure such as the user’s online bank,with the use of SAML between the service and the identity provider.

SammanfattningAtt tillhandahålla identifieringstjänster till externa

entiteter med SAML

Den här rapporten undersöker olika metoder för att kunna tillhanda-hålla identifieringstjänster till externa entiteter med SAML. SAML för-söker att tillhandahålla ett standardiserat sätt att utbyta autentisie-ringsdata mellan flera parter. Genom att implementera stöd för SAMLkan både så kallade tjänsteleverantörer och identitetsleverantörer nå ettstort antal andra entiteter som gjort detsamma. En utvärdering av olikaSAML-funktioner och SAML-bibliotek gjordes för att kunna skapa enprototyp som är beskriven i denna rapport. Resultatet av prototypenär ett system som tillåter en användare att logga in på externa webb-tjänster genom användandet av existerande identifieringsinfrastruktursåsom användarens internetbank, med hjälp av SAML mellan tjänste-och identitetsleverantören.

Acknowledgements

This degree project is the result of the final course work in the Computer Scienceprogramme at the Royal Insititute of Technology (KTH) in Stockholm and has beencarried out at Swedbank AB.

Special thanks go to my supervisor, Markus Backman, at Swedbank for his timeand for providing the necessary support.

Contents

1 Introduction 11.1 Single sign-on (SSO) . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Authentication adaptation of new systems . . . . . . . . . . . . . . . 21.4 SAML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.5 The goal of this project . . . . . . . . . . . . . . . . . . . . . . . . . 31.6 Swedbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.7 Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Background 52.1 Electronic identification and SAML in Sweden . . . . . . . . . . . . . 52.2 SAML Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.1 Participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.2 Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.3 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.4 Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.5 Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.6 Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.7 Exchange of metadata . . . . . . . . . . . . . . . . . . . . . . 11

2.3 SAML software libraries . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.1 OpenSAML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3.2 Shibboleth . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3.3 JBoss PicketLink . . . . . . . . . . . . . . . . . . . . . . . . . 122.3.4 OpenAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4 Web SSO using SAML . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Pre-study 153.1 Open questions with SAML Web SSO . . . . . . . . . . . . . . . . . 153.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.3 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4 Method and implementation 194.1 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.1.1 SAML features to use . . . . . . . . . . . . . . . . . . . . . . 204.1.2 Phishing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.1.3 Anti-phishing features . . . . . . . . . . . . . . . . . . . . . . 224.1.4 Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.1.5 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.1.6 Signatures and encryption . . . . . . . . . . . . . . . . . . . . 23

5 Results 275.1 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.1.1 The SAML Authentication Request . . . . . . . . . . . . . . 275.1.2 Metadata lookup . . . . . . . . . . . . . . . . . . . . . . . . . 315.1.3 The SAML Response . . . . . . . . . . . . . . . . . . . . . . . 31

5.2 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6 Conclusions and recommendations 356.1 SAML conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356.2 SAML libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356.3 Signatures and encryption . . . . . . . . . . . . . . . . . . . . . . . . 366.4 Difficulties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Bibliography 37

Appendices 38

A Technical terms and abbreviations 39

B Metadata 41B.1 Identity provider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41B.2 Service provider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

C SAML Response 45C.1 SAML Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Chapter 1

Introduction

This chapter provides an introduction to the degree project, presents the organiza-tion of and the motivation behind the report and also contains a brief explanationof the terms that are relevant for the project. For a complete list of technical termsand abbreviations, please refer to appendix A.

1.1 Single sign-on (SSO)

The problem of authenticating users against services is a growing one. The numberof services, especially on the internet in the form of web applications is growingrapidly. These types of services typically have some sort of protected or personal-ized content. In order to authenticate users on the sites one common method is touse a digital identity in the form of a username and a password. Managing thesemultiple digital identities and associated authentication credentials is difficult formost users [23]. Since the number of services is increasing, a single user today hasto keep track of an increasing number of usernames and passwords. Ideally thesepasswords should all be unique and randomly generated, but this makes remember-ing them a difficult task. One way of solving this problem is to implement a systemthat allows a user to log in to multiple systems at once.

Single sign-on (SSO) is a concept where users can enter their credentials onceand then gain access to multiple systems without being prompted to log in to eachindividual system. Single sign-on solutions use centralized authentication serversin order to authenticate users across different systems, a concept that can also beused in an organization to provide an authentication service for its users to thirdparty services. There exist many proprietary implementations of such single sign-onsolutions: something that can be troublesome if one, as an identity provider, wantssupport for a wide variety of external services.

1

CHAPTER 1. INTRODUCTION

1.2 Motivation

When businesses and organizations possess identification methods for customersit is often in the businesses’ or organizations’ interest to be able to provide theseidentification methods to third parties in a secure way. In other words, businesseswant to be able to act as an identity provider towards other service providers inidentifying customers and signing them on to external services.

One way of communicating such authentication information is by the use ofSAML (Security Assertion Markup Language), an XML-based framework that al-lows business entities to make assertions regarding users to other third party entitiessuch as partnering companies or services.

This project is mainly motivated by two driving forces:

• The need for single sign-on allowing users to identify themselves once in orderto gain access to multiple internal and external systems.

• Simplifying adaptation of new systems. When introducing new systems, bothinternally and externally, one would prefer a simple way of configuring the newsystem to work in connection with the existing authentication infrastructure.

1.3 Authentication adaptation of new systems

When introducing a new system to a set of existing users and when one wants tocontinue to use an existing mechanism for authentication, the question of how tointegrate the two separate systems arises. One would typically want to keep theexisting authentication mechanism and ideally have the already logged-in users au-tomatically logged into the new system. With systems being developed or purchasedby numerous different companies a standardized way for the systems to exchangethe required authentication details of users would be desired. This would enable newsystems to be able to use the existing identity provider without much integration.

1.4 SAML

SAML attempts to provide a standardized way of exchanging identity data betweenmultiple parties. By implementing support for SAML, both service providers andidentity providers can reach a large number of entities that also have implementedsupport for SAML while still only having to implement support for one protocol.SAML has support for most of the features that are desired when exchanging iden-tity data such as single sign-on, single sign-out and communication of identity databoth using a forwarding entity (typically a web browser) as well as a separate ded-icated communication channel between the two entities.

2

1.5. THE GOAL OF THIS PROJECT

1.5 The goal of this project

The aim of this project is to investigate possible solutions for implementing supportfor SAML for an identity provider, e.g. Swedbank, using multiple identificationmethods and a customer base of several million users, for use towards both internaland external services.

The goal can be formalized into these four statements:

1. Determining what SAML features can and should be used in order to be ableto securely authenticate existing customers towards external entities.

2. Looking at whether existing SAML implementations can be used.

3. Looking at which existing SAML libraries can be used.

4. Implementing a prototype that shows functionality of a SAML-compatibleidentity provider towards an example service.

In connection to this, the following limitations have been made:

1. The project only investigates version 2.0 of the SAML specification.

2. The project only investigates SAML-libraries for Java.

3. The implemented prototype does not have to be ready for actual usage, butit should possess enough functionality to make informed decisions about thetypes of libraries to be used. It should also be able to motivate which partsof the SAML-specification are needed to implement a single sign-on system.

1.6 Swedbank

Swedbank is a Nordic-Baltic banking group with 17,000 employees and with aninternational customer base of 9.5 million retail customers and more than 500,000corporate customers. The group has 377 branches in Sweden with an additional 224branches in the Baltic countries. Almost all of these customers have an identificationmethod issued by Swedbank, used for electronic identification and authenticationtowards the bank, which for the customers in Sweden, include identification viasecurity token, BankID on card, BankID in mobile and personal code. These iden-tification methods are used for providing the customers with a secure way of doingtheir banking online. As Swedbank is a large identity provider, as in one that is ableto provide identification services to many of its customers, Swedbank desires col-laboration with other service providers where its identification and authenticationservices can be provided to other services.

3

CHAPTER 1. INTRODUCTION

1.7 OrganizationThe organization of the report is as follows. Chapter 2 contains background andtheory of electronic identification and also provides an overview to SAML and SingleSign-On. Chapter 3 comprises a pre-study which was necessary to conduct beforechoosing a method for implementing the prototype. Chapter 4 contains the resultsfrom the pre-study as well as details of how the prototype-implementation was donewhile chapter 5 provides the results of the prototype and chapter 6 the conclusionsand further recommendations of using SAML and the library used.

4

Chapter 2

Background

This chapter provides background information for the remainder of the report. Itcontains an introduction to the problem of electronic identification, an overviewof the different parts of SAML as well as descriptions of various software librariesthat implement SAML. The chapter also describes the Web Single Sign-On scenariousing SAML.

2.1 Electronic identification and SAML in SwedenAs previously mentioned, the number of services on the web is increasing rapidly. InSweden, the topic of identification on the internet has gained importance with theintroduction of a government authority (E-legitimationsnämnden) assigned the taskof developing a new federation-based identification service1 for Swedish citizens [7].There already exists a group of established national identity providers for Swedishcitizens which consists of a collection of issuers ranging from banks to telephoneoperators. One of the largest identity providers is called BankID [8].

The new federation consists of both identity and service providers. The iden-tity providers are under regulation by the mentioned government authority whichensures that the identity providers follow guidelines for handling of sensitive data.The authority also provides specifications on how communication should take place,which currently is said to follow the SAML 2.0 specification, as well as help to newproviders connecting to the federation [15].

As Swedbank could act as an identity provider in this new federation, it givesSwedbank additional motivation to implement SAML-support.

2.2 SAML OverviewSAML is developed and maintained by OASIS Security Services Technical Commit-tee [20] and is “an XML-based framework for describing and exchanging security

1A federation-based identification service is a service that can link together multiple onlineidentities into a so-called federated identity.

5

CHAPTER 2. BACKGROUND

information between on-line business partners [21].” It is mainly driven forward bythree concepts:

• Single sign-on – In the past, products that claimed to provide web-based SSOtypically used browser cookies. Since browser cookies only work within asingle domain other proprietary solutions were used for multi-domain SSO(MDSSO). Organizations, however, typically used different vendors’ imple-mentations and so cross-organization collaboration was complicated. SAMLsolved the MDSSO problem by providing a standardized vendor-independentplatform for communicating authentication data of users between two webservers, completely independent of other domain limited solutions.

• Federated identity – Another use case for cross-organizational collaborationis with federated identities. A user is said to have a federated identity whentwo or more entities agree on a common identifier for referring to a user.This common identifier is automatically set up without the need for the or-ganizations to maintain identity-related data or synchronize identity-baseddatabases. SAML provides a standardized way of communicating betweenthe entities in order to set up such an identity.

• Web services – SAML allows for its security assertions to be used outsideof the otherwise defined SAML contexts. This adaptation has proved usefulto other services, for instance the ability to use SAML’s assertions within aweb service security token that can be used in encrypting web service SOAPmessages [21].

This SAML overview section covers a subset of the SAML v2.0 specification ingreater detail. It covers the SAML areas of profiles, protocols, assertions and bind-ings.

These areas make up the SAML-specification and their relationship can be con-ceptually modeled as in Figure 2.1.

2.2.1 ParticipantsIn any SAML interaction the involved entities are SAML asserting parties andSAML relying parties. An asserting party in a SAML environment issues assertionswhile a relying party uses the assertions. SAML also refers to the party that makesa direct request to another entity a SAML requester and the responding entity theSAML responder. Both the asserting party and the relying party can be equallyrequester and responder.

In addition to the above participants SAML also defines roles which are presentin different SAML scenarios. For example in the single sign-on context SAMLdefines the roles identity provider (IdP) and service provider (SP) where the identityprovider is the asserting party issuing assertions to the relying party, in this case,the service provider.

6

2.2. SAML OVERVIEW

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 doing identity management

AssertionsAuthentication, attribute, and

entitlement information

MetadataConfiguration data for

identity and service providers

Figure 2.1. Relationships of different SAML-areas covered by the SAML-specification.

The subject in a SAML context is normally the user, found in most assertionsissued.

2.2.2 Assertions

An assertion in SAML allows an asserting party to assert security information abouta subject in the form of different statements. Each SAML assertion contains somebasic required information as well as one or more statements.

SAML defines three types of statements that can be included in an assertion:

• Authentication statements: These contain information that a user has beensuccessfully authenticated. These statements are created by the entity thathas authenticated the user. Authentication statements contain, at the veryleast, the type of authentication method used and the date and time the userwas authenticated.

7


• Attribute statements: These statements contain attributes that are applicableto the authenticated user such as personal details, group memberships etc.

• Authorization decision statements: These can contain decisions taken by theissuing party defining which actions a user is authorized to perform.

The assertion is encapsulated within a SAML response message as shown in Fig-ure 2.2.

Transport protocol

Transport protocol payload

Transport protocol header

SAML response

Assertion

Authenticationstatement

Otherstatements

Figure 2.2. Encapsulation of SAML-assertions in a SAML-response.

2.2.3 Protocols

Several protocols exist in SAML that describe the communication between twoparties in different contexts.

• Authentication Request Protocol: A protocol that describes how an entity canrequest assertions from an assertion-issuing entity. In the Web Browser SSOProfile this protocol is used to initiate the sign-on process where the serviceprovider issues an authentication request to the identity provider.

8

2.2. SAML OVERVIEW

• Single Logout Protocol: This is a protocol that allows a user to be logged outof multiple services nearly simultaneously. The logout process can be initiatedfrom any of the service providers, the identity provider or by the user.

• Assertion Query and Request Protocol: This describes the protocol used forquerying or requesting assertions over an unspecified binding.

• Artifact Resolution Protocol: This describes a protocol used for resolving ar-tifacts, which are later used for retrieving assertions. An artifact is defined asa small fixed-length value. The party that receives the artifact uses the Arti-fact Resolution Protocol to ask the creator of the artifact to dereference theartifact in order to receive the actual message, which is typically an assertion.

• Name Identifier Management Protocol: This specifies the protocol of com-municating changes in value or format of a name identifier used to refer to asubject.

• Name Identifier Mapping Protocol: This specifies the protocol of mapping apreviously agreed upon SAML name identifier into a new one between two ormore parties.

2.2.4 BindingsBindings in SAML are defined as the transport protocols over which the overlyingSAML messages can be sent. The bindings defined are:

• HTTP Redirect Binding – A binding which defines how HTTP 302 redirectscan be used to send Base642-encoded SAML-messages.

• HTTP POST Binding – A binding which defines how Base64-encoded SAMLmessages can be transported in HTML forms over HTTP POST3 requests.

• HTTP Artifact Binding – A binding which defines how artifacts can be sentfrom a message sender to a message receiver. This is supported via eitherHTML-form data or via URL-request parameters.

• SAML SOAP Binding – This binding is used for sending SAML-messages overSOAP4 1.1.

• Reverse SOAP (PAOS) Binding – This binding allows an HTTP client to actas a SOAP responder and can be used in some of the SAML profiles.

• SAML URI Binding – A binding which defines how to retrieve an existingSAML assertion by resolving a uniform resource identifier (URI).

2See appendix A for a brief explanation of Base64-encoding.3HTTP POST is a type of command present in the HTTP-protocol. See appendix A for a

longer description.4SOAP, Simple Object Access Protocol, a protocol for exchanging structured information in

web services.

9


2.2.5 ProfilesSAML defines a set of profiles which lay down rules and constraints for how asser-tions and bindings are used in the different SAML scenarios.

SAML specifies the following profiles:

• Web Browser SSO Profile. This profile covers how SAMLmessages are used forachieving web single sign-on with web browsers featuring the HTTP Redirect,HTTP POST and HTTP Artifact bindings.

• Enhanced Client and Proxy Profile. This is a specialization of the WebBrowser SSO Profile which enables specialized clients such as mobile clientsto use SOAP and reverse-SOAP (PAOS).

• Identity Provider Discovery Profile. This describes a mechanism for letting aservice provider automatically find a user’s identity provider which the userhas previously visited.

• Single Logout Profile. Tightly coupled with the Web Browser SSO Profile,it describes how to achieve single logout from multiple identity and serviceproviders with use of the SOAP, HTTP Redirect, HTTP POST and HTTPArtifact bindings.

• Assertion Query/Request Profile. This describes a mechanism for querying orrequesting assertions from an asserting party over the SAML SOAP binding.Requesting in this context means asking for an existing assertion given anassertion id while querying means asking for new assertions based on certaincriteria.

• Artifact Resolution Profile. This is a profile which describes how to resolvean artifact over a SAML SOAP binding.

• Name Identifier Management Profile. This provides details on how to modifyor terminate the value or format of a name identifier that identifies a subjectwith the use of the SOAP, HTTP Redirect, HTTP POST or HTTP Artifactbindings. Both the service provider and the identity provider can issue sucha request.

• Name Identifier Mapping Profile. This is a profile which explains a mecha-nism for mapping one name identifier to another. A service provider can, forexample, request a new mapping for a subject, which it can in turn use forintegration with another service provider.

2.2.6 MetadataSAML metadata is used for connecting different entities in a SAML-enabled config-uration. The metadata document contains information such as identifiers, binding

10

2.3. SAML SOFTWARE LIBRARIES

support, endpoints and certificates for each of the entities. The SAML specificationalso specifies how this metadata should be formatted with the goal of simplifyingconfiguration when adding new parties to a SAML-enabled system.

Each metadata document is XML-based and contains one or more entities thatcan contain one or more roles. For example a SAML system entity can act as anidentity provider and an attribute authority which are defined as two different roles.

Appendix B.1 shows an example of such a SAML metadata file containing anentity acting as the role identity provider.

Each party involved in any SAML configuration has this type of metadata. Foran example of metadata for a service provider, please see appendix B.2.

2.2.7 Exchange of metadata

The exchange of metadata can be accomplished in several different ways. Thesimplest way of exchanging metadata is by manual means not specified in the SAML-specification. This could be over secure e-mail, various physical media, etc. TheSAML metadata-specification, however, also describes ways of automatically andsecurely retrieving such metadata, something which is necessary if one wants to beable to support anonymous5 service providers.

One way of automatically publishing and resolving metadata is by what theSAML specification refers to as “via well-known location” [5]. The entity ID of aSAML-enabled entity is typically a valid URL. At this URL the metadata documentdescribing the entity can be placed, and therefore, a partnering SAML-entity canretrieve the metadata as long as it is aware of the entity id of the other party.

The second, more complex, way of automatically exchanging metadata is by theuse of DNS [5].

The input for resolution of the metadata is still the party’s entity id. In-stead of accessing the full URI, only the domain name of the URI is used. Oncethe domain name has been established, the URL of the metadata can be derivedthrough DNS-queries of NPATR Resource Records, as described in RFC2915 [17]and RFC3403 [16]. It is possible to set up multiple methods of publishing the meta-data document, which means details of the available publishing methods also existwithin the NPATR Resource Records.

2.3 SAML software librariesSince one of the main goals of SAML is to be able to provide a standardized wayof communicating authentication data, many implementations of SAML exist. Theimplementations come both in the form of software libraries, used for generatingSAML-messages, as well as stand-alone SAML-compatible products that can beintegrated with an existing application.

5Anonymous here refers to the fact that the identity provider does not know of the serviceprovider beforehand. It does not mean that the service provider is or can be fully anonymous.

11


The following sections describe a few popular software libraries and stand-aloneapplications.

2.3.1 OpenSAML

OpenSAML is an open source library developed and maintained by the organizationInternet2 and is a library that has both Java and C++ bindings [12]. It is a verylow-level library, but enables an application to be able to create any SAML-message.It provides some but not extensive functionality for validating that the generatedmessages conform to the SAML-specification. It does, however, provide helpfulfeatures such as cryptographic validation of signatures and the ability to encrypt,sign and compress messages. The SAML-messages are built using a DocumentObject Model (DOM6) which is later marshalled to form actual XML-output. Thismakes the creation of messages extremely versatile.

2.3.2 Shibboleth

Shibboleth is an open source library and, as is OpenSAML, also developed by Inter-net2 [13]. Shibboleth, however, works at a higher level than OpenSAML, providingnative support for all bindings in the SAML-specification. Shibboleth ships in twoparts, an IdP (identity provider) and an SP (service provider). Both of these arehighly configurable stand-alone applications which means that in order to success-fully set up a complete SAML-enabled entity one does not have to program using anylibraries, but merely configure the stand-alone identity or service provider. Configu-ration of the Shibboleth identity provider includes adding relevant service providerstogether with their corresponding metadata, as well as installing the certificate forthe identity provider so that Shibboleth is able to generate the identity provider’smetadata.

2.3.3 JBoss PicketLink

JBoss PicketLink is open source software developed by JBoss. As Shibboleth, JBossPicketLink is stand-alone software that is deployed on a Java server as a web ap-plication [1]. The application is then used as a proxy for intercepting requests inorder to be able to handle sessions.

Configuration therefore consists of similar tasks as for Shibboleth, such as settingup certificates, customizing the login page etc., which makes it a similar alternativeto Shibboleth.

2.3.4 OpenAM

OpenAM, previously known as OpenSSO, was originally developed by Sun. WhenOracle, with the acquisition of Sun, chose to discontinue the development of OpenSSO

6See appendix A for a brief explanation.

12

2.4. WEB SSO USING SAML

ForgeRock announced that it would continue to develop and maintain OpenSSO un-der the new name OpenAM [9].

As with both JBoss PicketLink and Shibboleth, OpenAM ships as a web-application.Configuration is done via a web-interface and includes choosing keys for signing andencrypting messages and choosing a user store, a database of users that should beable to sign-in.

2.4 Web SSO using SAMLAs previously mentioned, the SAML Web Single Sign-On scenario is one of the maindriving forces for the creation of SAML. The SAML Web SSO scenario can be usedwith several different SAML-bindings, most notably, the HTTP Redirect binding,the HTTP POST binding and the HTTP Artifact binding. This section containsa detailed example of two SAML-enabled parties in a SAML Web Browser SSOProfile configuration using multiple bindings and protocols.

Figure 2.3 shows the flow of a SAML-setup using the HTTP Redirect and HTTPPost bindings:

Service Providersp1.swedbank.se

Identity Provideridp.swedbank.se

Accesscheck

AssertionConsumer

Service

Browser

User orautomated action

SingleSign-OnService

Automated action

Accessresource

1

2

Redirect with<AuthnRequest>

7

Supplyresource

POST signed<Response>

6 Signed<Response>

in HTML form

5

4

GET using<AuthnRequest>

3

Challengefor

credentials

Userlogin

Figure 2.3. Illustration of the message flow during sign-in with relevant entities.

13


1. The user tries to access a protected resource at the service provider.

2. The service provider checks for a local session context for the correspondinguser, and if no such context exists, generates a SAML authentication requestwhich is Base64-encoded (according to RFC4648 [14]) and embedded as aGET-parameter in a URL of the identity provider as described by the SAMLHTTP Redirect binding [4]. The web server then issues a HTTP redirectresponse to the user’s web browser, redirecting the user to the new URL.

3. The user’s web browser receives the redirect response and starts a new connec-tion to the identity provider, the SAML authentication request still embeddedwithin the URL of the request.

4. The identity provider receives the authentication request, checks for a localsession context for the corresponding user, and if no such context exists, re-turns HTML that challenges the user for authentication credentials.

5. The user provides necessary credentials, sending them back to the identityprovider.

6. The identity provider verifies the credentials, and if correct creates a localsession context for the user and then issues a SAML authentication responsecontaining an assertion. The SAML-response contains data of how and whenthe user was authenticated, by what means the user has authenticated it-self as well as potential custom attributes such as what groups the user is amember of, memberships the user has, etc. This response and the assertionare typically signed by the identity provider to avoid tampering. Finally theSAML-response is Base64-encoded and placed as the value of a hidden formin HTML which is returned to the users’ web browser as described by theSAML HTTP Post binding [4].

7. The browser receives the HTML and submits the form to the service providereither automatically using Javascript or manually by the user if Javascript hasbeen disabled.

8. The service provider receives the authentication response, validating any sig-natures present within the response and then creates a local session contextfor the user, returning the protected content originally requested to the user.

14

Chapter 3

Pre-study

In order to build a prototype capable of securely authenticating users towards otherentities, some questions arise that need to be addressed immediately before thedesign of the prototype starts. The pre-study chapter of this report formalizesthese questions into requirements for the prototype.

3.1 Open questions with SAML Web SSOWhile SAML is extremely flexible and versatile, using it in the even somewhatbasic case of normal web-based browser single sign-on can still be very challenging.Many SAML-implementations today generally require the administrator to havea deep understanding of the SAML-standard. P. Harding, L. Johansson and N.Klingenstein highlight this by bringing forth questions that have to be answered byanyone setting up SAML [11]:

• How should trust between providers be managed?

• How should information about providers (metadata) be provisioned?

• Which SAML profiles and bindings should be used?

• Which messages and what part of each message should be signed?

• Which identifiers and attributes should be exchanged?

• What are the semantics of those attributes and identifiers?

These types of questions have to be answered by anyone wanting to use SAML in asingle sign-on environment.

3.2 RequirementsIn addition to the above open questions that need to be answered, in this specificcase there exist a number of requirements that are specific for Swedbank. This

15

CHAPTER 3. PRE-STUDY

is because Swedbank eventually wishes to integrate the developed prototype intoits online bank. This integration with Swedbank’s online bank in turn createsrequirements also for the prototype which are listed below in table 3.1.

ID Requirement Motivation1 Prototype must be implemented in

Java.Future integration of prototype withexisting IdP software is desired,which is Java-based.

2 Prototype must be easily extendablewhen integration is desired with newservice providers.

Work is reduced if integration withnew service providers is uncompli-cated.

3 Prototype must be capable of beingintegrated with the existing identityprovider software.

Support for authentication with sev-eral authentication methods is al-ready implemented in existing iden-tity provider software.

4 Libraries must have support forSAML 2.0.

Support for communication withSAML 2.0-speaking peers is desired.

5 Communication between identityprovider and service provider shouldbe solely via the web browser.

If all communication is done via theweb browser there is no need toset up new direct connections be-tween parties when adding serviceproviders – which eases integration.

6 Solution for handling metadata ofservice providers must be scalable interms of administration effort.

A scalable solution for addingnew service providers should min-imize code duplication and allowfor simple addition of new serviceproviders.

7 Solution should not be vulnerable toa particular sort of phishing attack.

One does not want a malicious siteto be able to send users to the iden-tity provider only to return to a ma-licious phishing site.

8 Only known service providersshould be able to interact with theidentity provider.

One wants to ensure with which ser-vices the organization is associated.

Table 3.1. Table of requirements

3.3 Security

One of the main points of SAML is that implementers desire their solution to besecure. Secure is a broad term which in this specific case can mean several things:

16

3.3. SECURITY

• Integrity – One wants to be able to make sure that messages sent between theparties have not been modified by anyone.

• Authenticity – One wants to know that the message was actually sent by theentity that it was claimed to be sent by.

• Confidentiality – No-one else but the trusted partner entity should be able toread the message.

Along with this there are several other potential attacks one might want to be secureagainst:

• Replay attacks – An evil party that has recorded a message should not beable to resend it and successfully authenticate themselves or someone else.

• Phishing attacks – An evil party should not be able to send a legitimate user toa fraudulent website after the user authenticates itself at the identity provider.

• Denial-of-service attacks – An evil party should not easily be able to takedown the system by e.g. generating excessive load.

Prior to starting work on the prototype, it had to be decided which of these qualitieswere required and this is answered in the next chapter.

17

Chapter 4

Method and implementation

This chapter contains the results of the pre-study with a brief discussion and moti-vation of the choices made. It also describes the implementation and what SAMLfeatures should be used.

4.1 ImplementationA prototype was implemented that showed functionality of a working identityprovider against two different service providers.

The prototype enabled users to be able to log in to two different online services,or service providers, with the use of the prototype acting as the identity provider.Figure 4.1 shows an overview of the systems involved in the prototype.

In order to achieve requirements 1, 2 and 3 (table 3.1, page 16), OpenSAMLwas chosen as the library to use. The main reason for choosing OpenSAML overany of the other libraries is that due to its low-level design it is possible to in-tegrate with Swedbank’s existing infrastructure. Since Swedbank already has anidentity provider [22], it becomes natural to integrate SAML-support into the exist-ing identity provider software, instead of integrating a stand-alone product (such asShibboleth, OpenAM or JBoss PicketLink) with the existing software. OpenSAMLalso has Java bindings and support for SAML 2.0 [12] which was requirement 4 onpage 16.

Because of the lack of validation routines in OpenSAML, using it requires arelatively deep understanding of the SAML-specification. The SAML-specificationitself contains many uses of the keywords SHOULD, MUST, RECOMMENDED asdescribed by RFC2119 [3], something one as a user of the library has to considerwhen building messages using OpenSAML. This can make programming using theOpenSAML library more time-consuming than using other libraries or stand-aloneSAML-implementations.

19

CHAPTER 4. METHOD AND IMPLEMENTATION

Swedbank Online Bankinternetbank.swedbank.se

Browser


Identity Provideridp.swedbank.se


Figure 4.1. Overview of the systems involved with arrows symbolizing commu-nication. The lighter box titled “Identity Provider” corresponds to the prototypeimplementation.

4.1.1 SAML features to use

This section covers the previously mentioned SAML assertion statements, protocols,bindings and profiles which are relevant and needed when implementing a SAMLidentity provider that allows authentication of users towards other systems.

• Assertion statements: Generally no authorization decision statements are used– the default scenario is that the service provider fully trusts the identityprovider to have carried out whatever authorization checks that are needed.

Authentication statements are the fundamental part of an assertion which areused in order to say when and by what means a user has been authenticated.

20

4.1. IMPLEMENTATION

Attribute statements may be used as they are common practice when theservice provider requires more structured data about a user. This could, forexample, be the first and last name of a user, groups the user belongs to, etc.

• Protocols: The main protocols that are needed are the Authentication RequestProtocol, which is used when the service provider initiates the authenticationprocedure, and the optional Single Logout Protocol which is used if a single-logout feature is necessary. If the Single Logout Protocol is not implemented,session logouts are handled separately by each identity and service provider.

• Bindings: The two necessary bindings are the HTTP Redirect Binding andthe HTTP Post Binding. The redirect binding is commonly used by theservice provider when issuing the authentication request towards the identityprovider. It is generally not used if the authentication request is signed sincealthough permissible URL length is theoretically infinite, the limit is oftenunpredictable and hence the HTTP Post Binding is used instead [4].The HTTP Post Binding is used by the identity provider in order to send theSAML-response back to the service provider. These two bindings are fullybrowser based which conforms to the browser requirement (requirement 5).The SOAP and Artifact bindings, which are not (solely) browser based aretherefore not relevant.

• Profiles: The main profile studied for use with the prototype is the SAMLWeb Browser SSO Profile. Together with the Single Logout Profile they makeup the core of providing authentication of a user towards someone else. TheSingle Logout Profile can be seen as optional if each party keeps track of thelocal session context themselves. In those cases each entity can log out theuser from their own context, even though the login was only done once.Since only browser-based communication is desired (requirement 5) the Arti-fact Resolution Profile becomes unnecessary. The Assertion Query/Requestprofile is not used either, since it is utilized for retrieving existing assertions.The Name Identifier Management and Mapping profiles can be seen as op-tional for more advanced use cases where multiple involved entities want tokeep track of a user after the login has been completed. Such use cases typi-cally involve federated identities.The Identity Provider Discovery Profile is not needed either since anonymousservice providers are not allowed (requirement 8). Not having anonymousservice providers requires each new service provider to be set up manually,which makes the Identity Provider Discovery Profile superfluous.

4.1.2 Phishing

Phishing is a type of online fraud where an attacker, one way or another, triesto trick users into entering their legitimate credentials by creating a fake website

21


very similar to the original website. It can simply be described as “the practiceof directing users to fraudulent web sites [6].” Most types of phishing are hard toprotect against, since a web page can be copied with ease. Often, the best way ofmitigating phishing is by educating the users.

Some phishing attacks work by using flaws in the original legitimate system, andit is important to avoid creating such flaws when designing an identity provider. Anexample of such a flaw is described in the next section.

4.1.3 Anti-phishing features

One of the requirements (requirement 7) is that the single sign-on solution shouldbe resilient against a certain type of phishing attack. This phishing attack is pos-sible when an identity provider either does not authenticate the service providerrequesting authentication or blindly trusts the contents of the request. This typeof phishing-attack can be difficult to counter, and is not always possible in othersingle sign-on solutions such as OpenID [19], where an identity provider does nothave to know a service provider beforehand.

An authentication request typically contains information about who is request-ing the authentication of a subject, where the identity provider should redirectthe user after this authentication is complete, as well as various timestamps. Ifthis message is not signed in any way then this information could be modified bya man-in-the-middle attack, but equally importantly, a malicious site could sendidentical information, but with a different return URL, thereby sending the user tothe malicious site after first authenticating with the real site.

This sort of problem is especially tricky for the user to see as the user onlybriefly visits the malicious site, is then redirected to the real site where they entertheir credentials, and is then sent to a malicious phishing site.

Listing 4.1 shows a valid SAML authentication request.

1 <?xml version="1.0" encoding="UTF-8"?>2 <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"3 AssertionConsumerServiceURL="https://sp1.swedbank.se/Swedbank-SP"4 Destination="https://idp.swedbank.se/SSOService"5 ID="_eb53d3837b82d1f11927502265f05e65d625ba49a9"6 IssueInstant="2011-05-31T09:34:49Z"7 ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"8 Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">9 <saml:Issuer>https://sp1.swedbank.se</saml:Issuer>

10 <samlp:NameIDPolicy AllowCreate="true"11 Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>12 </samlp:AuthnRequest>

Listing 4.1. A SAML authentication request.

22

4.1. IMPLEMENTATION

The vulnerable field is the AssertionConsumerServiceURL property on line 3 whichtells the identity provider where to send the user after it has successfully authenti-cated itself. Even if the identity provider does not allow anonymous service providersand checks the Issuer-tag on line 9, the identity provider still needs to check theAssertionConsumerServiceURL against the URL found in locally stored metadatafor the given entity ID (line 9) which is one way of solving this problem, but, whichof course, requires the identity provider to both know about and trust each ser-vice provider it wants to interact with. This problem is hence general for all singlesign-on solutions that want to use anonymous service providers.

Another solution for solving this issue is for the service provider to sign theauthentication request with a key belonging to a certificate trusted by the identityprovider. In this scenario the identity provider does not need to know about theservice provider, as long as the certificate is trusted (perhaps by signature of atrusted certificate authority). Examples of both signed and unsigned authenticationrequests are further described in the next chapter.

4.1.4 Functionality

The prototype was developed mainly as a developer API. An example applicationwas however also created to showcase the functionality available in the API.

The API is extensible for additions of new SAML-features and for modifying thecontent in the SAML-messages sent. It has support for the SAML Single Sign-onProfile using both the HTTP Post binding and the HTTP Redirect binding. It caneasily be configured per service provider with regard to the signing of different partsof the SAML-messages, the addition of custom attributes or modification of otherparts of the SAML-messages.

The prototype has support for cryptographic verification of signatures in incom-ing SAML-messages using the certificates present in the locally stored metadata foreach service provider. It does not perform trust verification checks of the certificatesthemselves such as expiry date checks, revocation status, etc., as this is consideredoutside of the scope of the application. The application assumes that if the certifi-cate has been manually stored for a service provider then that certificate is deemedvalid.

4.1.5 Design

The API uses the builder pattern [10] in order to accommodate extensibility fordifferent service providers. Figure 4.2 shows a class diagram of the prototype.

4.1.6 Signatures and encryption

Some security concerns have already been covered in section 4.1.3 (Anti-phishingfeatures). This section however describes how to address more general securityconcerns first discussed in the pre-study chapter (section 3.3).

23


AbstractResponseAssemblerSP1ResponseAssembler SP2ResponseAssembler

ResponseBuilderSP1ResponseBuilder

IDP

SSOService

SAMLObjectFactory

XMLObjectFactory

Figure 4.2. A class diagram of the implemented prototype. A solid line representsinheritance while a dashed line represents usage.

Below is a list of those concerns that can be addressed to some degree by thesending party by signing and/or encrypting messages.

• Integrity can be solved by signing messages. If someone modifies a message,they would need the sender’s private key in order to produce a valid matchingsignature and remain undetected.

• Authenticity is solved by signing a challenge generated by the other party.The SAML-response can be signed and provide authenticity since it contains

24

4.1. IMPLEMENTATION

the unique identification number previously sent in the corresponding SAML-authentication request. In order to provide authenticity for the first authen-tication request, the request has to contain a unique identification number aswell as a timestamp. In order to guarantee that the message has not beenrecorded by someone and later resent, the identity provider has to check thatthe unique identification number has not been previously used as well as checkthe timestamp present in the request.

• Confidentiality can be solved by encrypting the messages or ensuring thatthe entire communication channel is encrypted. This typically happens whencommunicating over HTTPS.

• Replay attacks: In order to avoid replay-attacks messages should containtimestamps and unique identification numbers which are then signed. If theother party checks that the number has not been used before then this ensuresthat replay-attacks are not possible.

• Phishing attacks can, to some degree, be prevented by signing messages andtherefore preventing a malicious user from modifying the URL where the usershould be sent after authentication. However, if the service providers are non-anonymous, a simpler way of avoiding phishing attacks is to verify the URLagainst locally stored metadata.

• Denial-of-service attacks: In order to avoid denial-of-service attack, validationrules should perform simpler checks before more computationally expensiveones. This means that the system should check that the message is sentfrom a valid service provider (entity id) before cryptographically verifying thesignature attached to the message (which is computationally expensive).

25

Chapter 5

Results

This chapter contains the results of the actual prototype and describes the finalcommunication between the entities in great detail.

5.1 CommunicationThis section describes the end result of the prototype and how communicationtook place between the service providers and the identity provider. Figure 5.1shows a UML-sequence diagram of the interaction between the browser, the serviceprovider and the identity provider. The messages sent are thoroughly described inthe following sections.

5.1.1 The SAML Authentication RequestThe authentication request sent by a service provider is the first step when a userinitiates a login. The actual SAML-message sent to the identity provider using theredirect binding can be seen in listing 5.1.

27

CHAPTER 5. RESULTS

Identity provider Service providerBrowser

Access resource

AuthnRequest

Query for credentials

Provide credentials

Verify request against metadata

Verify credentials

Response

Verify response against metadata

Send protected resource

Figure 5.1. A UML-sequence diagram of the communication between two SAMLentities and a user’s browser.

28

5.1. COMMUNICATION

1 <?xml version="1.0" encoding="UTF-8"?>2 <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"3 AssertionConsumerServiceURL="https://sp1.swedbank.se/Swedbank-SP"4 Destination="https://idp.swedbank.se/SSOService"5 ID="_eb53d3837b82d1f11927502265f05e65d625ba49a9"6 IssueInstant="2011-05-31T09:34:49Z"7 ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"8 Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">9 <saml:Issuer>https://sp1.swedbank.se</saml:Issuer>

10 <samlp:NameIDPolicy AllowCreate="true"11 Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>12 </samlp:AuthnRequest>

Listing 5.1. A SAML authentication request sent by a service provider with entityid https://sp1.swedbank.se to an identity provider.

The AssertionConsumerServiceURL-property (line 3) describes where the identityprovider should send the user with the SAML-response containing an assertion. Thisfield must be verified against the metadata stored for this service provider (see Meta-data lookup, section 5.1.2). The ID-property on line 5 must be a unique identifica-tion number used only once and should be generated randomly. The IssueInstant-property (line 6) is a timestamp of when the authentication request was issued, andshould be verified to be accurate by the identity provider with some unspecifiederror tolerance. The Issuer-tag (line 9) contains the entity ID of the entity thatissued the message, in this case the service provider. The NameIDPolicy-tag (line10-11) says that the identity provider is free to create a transient identifier for theuser for this session.

The XML is then compressed using the DEFLATE Encoding [4], Base64-encodedaccording to RFC4648 [14] and placed as the value of the SAMLRequest parameterin a URL. The value of each parameter value is then URL-encoded according toRFC3986 [2]. Listing 5.2 shows an example of a URL containing a SAMLRequest-parameter. In the example the URL has not been URL-encoded for readability.

As previously discussed the authentication request can also be signed whichprevents some phishing attacks. Listing 5.3 shows an example of a signed authen-tication request.

29

CHAPTER 5. RESULTS

1 https://idp.swedbank.se/SSOService?SAMLRequest=fZJfT4MwFMW/Cuk70LJ/0LAl2 c4txyVQypg++mA4urhF3dPTxiiqsubLxh7VDj4aQOt8VaVC3jXhzGGWT8OYXGWv/5WWmFTg3 mpDGKa4ESuRIoKKYjFohslXPSglo5YXGWv/5WWmFTgRk6T7vtP0LYEWRVl9BxhslXPSglo54 URoxNWjKcguCO2ZyNOx5yNXoizb3Wx54lNdGW53pklxIrisEVILcZT5fIhgrtSLOZj0nr8U5 m8jlbCd6mhtzX3a7C1Ov70MMJkx2VOTe+/5T+2b+BKzLspmE+ZA/hMaBDSWQAwzuAAyXOMx6 Kp03JXj1se652JZsruRKpfq7Xpsh34I+d1+n7jJY7oni/gM510qukJ8oNQ726aECcCfpo8g7 MZjFYw5p5OGzxEGL/cibun/qhpW/WiS5l9u3calMJe335uSJzt+hGuTVCoQRl27DKUp9WBo8 SFObGmAeIv+pV/P9TiBw==9 &RelayState=https://sp1.swedbank.se/authenticate/Swedbank-SP

Listing 5.2. A URL with embedded SAMLRequest and RelayState-parameters.

1 https://idp.swedbank.se/SSOService?SAMLRequest=fZJfT4MwFMW/Cuk70LJ/0LAl2 c4txyVQypg++mA4urhF3dPTxiiqsubLxh7VDj4aQOt8VaVC3jXhzGGWT8OYXGWv/5WWmFTg3 mpDGKa4ESuRIoKKYjFohslXPSglo5YXGWv/5WWmFTgRk6T7vtP0LYEWRVl9BxhslXPSglo54 URoxNWjKcguCO2ZyNOx5yNXoizb3Wx54lNdGW53pklxIrisEVILcZT5fIhgrtSLOZj0nr8U5 m8jlbCd6mhtzX3a7C1Ov70MMJkx2VOTe+/5T+2b+BKzLspmE+ZA/hMaBDSWQAwzuAAyXOMx6 Kp03JXj1se652JZsruRKpfq7Xpsh34I+d1+n7jJY7oni/gM510qukJ8oNQ726aECcCfpo8g7 MZjFYw5p5OGzxEGL/cibun/qhpW/WiS5l9u3calMJe335uSJzt+hGuTVCoQRl27DKUp9WBo8 SFObGmAeIv+pV/P9TiBw==9 &RelayState=https://sp1.swedbank.se/authenticate/Swedbank-SP

10 &SigAlg=http://www.w3.org/2000/09/xmldsig#rsa-sha111 &Signature=RA2cmCa1a/HxxGip/X+BJRfe123Bh0v6coX+bq3eNkSfi0C5CewicgD4FxlD12 NAEqTmahObYpMYAnX5LjC4kllwu96aNyQHcLWLahWWs2+LJU8XTkm6QlWmQ5NkGFCqs7y2b13 r1t7RAcQTMcntUFHV9khss4bRtFVE4ZNNNunPp5H03c+vOgboNEqCA6sw5NQ5dw/+9m6L8H14 gJJGLGHPsvemQdIrHXyvN0iFalFiooETlGY7wjlJMeIevSNMCwOZXgKvMi3XLWSK8Nmz5ph15 PORPh5wg3KqQdJeiIvTUNYePZEzBlfdjCkn64RnXFN7yzYtDfC9ITAbDcmgjS3IRDTFoQ==

Listing 5.3. A signed URL containing a SAML authentication request.

As can be seen in listing 5.3 – where the authentication request is signed, in com-parison to the unsigned authentication request in listing 5.2, two additional pa-rameters are added onto the URL: SigAlg (line 10) and Signature (line 11). TheSigAlg-parameter describes the type of signature that is used while the Signature-parameter contains the cryptographic signature. The signature present in theSignature-parameter is a signature of the entire URL except for the Signature-parameter which is yet to be computed. This means that both the RelayState- andthe SigAlg-parameters are signed as well, together with the SAML-request [4] andthe base of the URL.

30

5.1. COMMUNICATION

5.1.2 Metadata lookup

Once the identity provider receives the SAML authentication request and has val-idated that the entity id is trusted, it looks up where it should send the SAML-response by finding the location for the appropriate binding in the metadata file ofthe corresponding service provider. This is done by looking at the Location-propertyin the appropriate AssertionConsumerService-tag (line 26 in service provider meta-data, found in appendix B.2).

5.1.3 The SAML Response

The valid SAML-response can be seen in appendix C.1.As in the authentication request the ID-parameter (line 4) also here is a ran-

domly generated identification number. In addition there also exists an InResponseTo-parameter which contains the value of the ID-field in the previous authenticationrequest. Since the response is also signed, the ID-parameter together with the sig-nature stops replay-attacks. Also here the Issuer-tag contains the entity id of theissuer of the message, in this case the identity provider. The entire Signature-tagcontains information of how the SAML-response is signed with the most relevanttags being the Reference-tag with a URI-property that matches an ID-property ofanother tag in the SAML-response, specifying what part of the document is signedby the signature. It is apparent that the Reference-tag on line 17 corresponds tothe entire SAML-response while the Reference-tag on line 63 corresponds to theassertion within the SAML-response. The DigestValue-tags (lines 31-33 and 77-79)contains a Base64-encoded hash of the corresponding part of the response, whilethe SignatureValue-tag (lines 36 and 82) contains Base64-encoded cryptographic sig-natures. The X509Certificate-tag (lines 39-41 and 85-87) contain Base64-encodedX.509-certificates which should be validated against the certificates in the locally-stored metadata which are then used for verification of the signatures in the re-sponse.

The Subject-tag on line 91 describes the property of the subject (user) authen-ticated in the assertion. This includes a name identifier (lines 93-94) together withdetails of when and for whom the name identifier is valid (lines 99-101). The as-sertion also contains information of when and for what entity ids it is valid (lines104-110).

Finally the SAML-response contains an authentication statement and an at-tribute statement containing two attributes. The authentication statement containsthe instant the user was authenticated (line 111), how long the session should bevalid (line 112) and how the user was authenticated (lines 115-118). The two at-tributes containing the first and last name of the authenticated user are found onlines 122 and 127.

The SAML-response is then Base64-encoded and placed as the value of a hiddenfield in HTML which is posted back to the service provider using the URL previ-ously derived from the metadata. If a RelayState-parameter was passed with the

31

CHAPTER 5. RESULTS

authentication request, then this is posted back to the service provider.The HTML sent to the browser is seen in listing 5.4, where line 10 contains the

entire base64-encoded SAML-response.

1 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">2 <body onload="document.forms[0].submit()">3 <noscript>4 <p><strong>Note:</strong> Since your browser does not support5 JavaScript, you must press the Continue button once to proceed.6 </p>7 </noscript>8 <form action="https://sp1.swedbank.se/Swedbank-SP" method="post">9 <div>

10 <input type="hidden" name="SAMLResponse" value="cguC...ZT5"/>11 <input type="hidden" name="RelayState"12 value="https://sp1.swedbank.se/authenticate/Swedbank-SP5"/>13 </div>14 <noscript>15 <div><input type="submit" value="Continue"/></div>16 </noscript>17 </form>18 </body>19 </html>

Listing 5.4. The entire response sent to the web browser, with the Base64-encodedSAML-response embedded on line 10.

5.2 Testing

The prototype was tested against two different SAML-enabled service providers.One was an example service provider that used SimpleSAMLphp [18] for SAML-support, the other was a real system that used JBoss SEAM. The decision of testingagainst several different SAML-implementations was beneficial, since it became clearthat the implementations did not always follow the SAML-specification. The pro-totype was first designed to work with the service provider using SimpleSAMLphp,but once working properly the prototype did not function as intended with the otherservice provider. In fact, it was impossible to use the same format for the SAML-responses for the two different entities, so separate code was needed per entity.This in turn placed new requirements on the prototype – that customization of theSAML-messages for different service providers should be simple, without having toduplicate code. This is of course bad for SAML as a standard. The most importantpart of a standard is that multiple implementations should be able to interact with

32

5.2. TESTING

each other, which was not true for the tested implementations. This could be bothbecause of the complexity of the specification, but also because of its many optionalparts.

33

Chapter 6

Conclusions and recommendations

This chapter draws conclusions of which types of SAML-libraries exist, discuss issueswith using SAML together with multiple service providers and how encryption andsigning should be used with SAML. It also discusses general difficulties that werediscovered during the work with the degree project.

6.1 SAML conclusionsAs mentioned in the previous chapter, during testing it was identified quite early onthat implementations of SAML did not fully conform to the SAML-specification,and this caused some problems. The fact that implementations differ from the spec-ification can however be explained by the complex and highly detailed specification.Since SAML is supposed to be a standard, the fact that it is difficult to imple-ment SAML-support that functions together with other SAML-implementations,becomes an issue that to some degree can defeat the purpose of SAML.

Apart from the issues arising between the different implementations, SAMLcan be extremely powerful. The specification has details of almost any imaginablescenario, which makes SAML very versatile.

6.2 SAML librariesMany Java-based open source libraries that implement SAML exist, most of themhowever are complete solutions ready to be deployed and only need configuration.As Swedbank already has an identity provider and methods for identifying users,most of these libraries become unusable. The one library that was studied and wascompatible with the existing architecture was OpenSAML, which was later used inthe prototype. This choice was necessary, even though OpenSAML works at sucha low level and requires a developer to study the SAML-specification with greatdetail. With a good, extensible abstraction layer on top of the OpenSAML API,as was shown in the prototype, it however becomes manageable but still powerfulenough to function with several other SAML-implementations.

35

CHAPTER 6. CONCLUSIONS AND RECOMMENDATIONS

6.3 Signatures and encryptionSAML describes many security features, such as encryption and signatures of mes-sages, but also features recommendations as to which parts need to be signed and/orencrypted. In the end, the prototype used these recommendations, which are thesame as this report’s recommendations, such as using HTTPS for all communica-tion, signing the SAML-responses but not the SAML-requests1 and not encryptingany messages sent via the browser – leaving the browser free to read the messages,but not to modify signed ones.

6.4 DifficultiesDuring the degree project some challenges were encountered. For example, eventhough many papers exist that discuss the details of SAML, not as many describethe act of implementing SAML-support.

Another challenge that has already been mentioned was that the different im-plementations of SAML behaved differently. During testing, after the prototypewas implemented, it was discovered that the prototype did not function as intendedtogether with the second SAML-peer. This in turn led to having to re-design theprototype and to search for a software design pattern that allowed for easy adapta-tion of the code to work with multiple SAML-implementations.

The SAML-specification was a good and necessary reference for implementingSAML-support using OpenSAML, but it contained a number of special cases thatneeded to be considered. For example, the SAML-specification refers to the signingof each individual assertion as required and the signing of the entire response asrecommended, therefore the prototype implementation did both. One of the peersalso required this, but the other did not accept that the entire response was signed.In this case, the SAML-specification stated that it was recommended to sign theresponse, but did not address how the other entity should handle such scenarios.

Another issue for this degree project was the lack of suitable SAML-libraries.The original plan was to look at and compare suitable libraries, but during theresearch phase only one appropriate library, OpenSAML, was found and thus com-parisons of the libraries could not be carried out in the manner that was originallyplanned.

1To avoid the previously mentioned phishing attack, the prototype validates the URL againstlocally stored metadata which is much less computationally expensive than computing a signatureand thus avoids a potential denial-of-service attack.

36

Bibliography

[1] Anil Saldhana. PicketLink Federation User Guide, v1.0.0. Vis-ited, July 18. Available at http://community.jboss.org/wiki/PicketLinkSAMLSSOforWebContainers.

[2] T. Berners-Lee, R. Fielding, and L. Masinter. Uniform Resource Identifier(URI): Generic Syntax. RFC 3986 (Standard), January 2005.

[3] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. RFC2119 (Best Current Practice), March 1997.

[4] S. Cantor, F. Hirsch, J. Kemp, R. Philpott, and E. Maler. Bindings for theOASIS Security Assertion Markup Language (SAML) v2.0, 2005. Availableat http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf.

[5] S. Cantor, J. Moreh, R. Philpott, E. Maler, et al. Metadata for the OASISSecurity Assertion Markup Language (SAML) v2.0, 2005. Available at http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf.

[6] R. Dhamija, J. D. Tygar, and M. Hearst. Why phishing works. In Proceedingsof the SIGCHI conference on Human Factors in computing systems, CHI ’06,pages 581–590, New York, NY, USA, 2006. ACM.

[7] Finansdepartementet. En myndighet för samordning av elektronisk identifier-ing och signering. Kommittédirektiv, June 28, 2010. Dir. 2010:69, Available athttp://regeringen.se/sb/d/12785/a/148817.

[8] Finansiell ID-Teknik BID. This is BankID. Visited, June 15, 2011. Availableat http://www.bankid.com/en/What-is-BankID/.

[9] ForgeRock. ForgeRock Releases OpenAM 9.5. Visited, July 5, 2010. Availableat http://forgerock.com/press2010-07-22.html.

[10] E. Gamma, R. Helm, R. E. Johnson, and J. Vlissides. Design Patterns: El-ements of Reusable Object-Oriented Software. Addison-Wesley, Reading, MA,1995.

37

BIBLIOGRAPHY

[11] P. Harding, L. Johansson, and N. Klingenstein. Dynamic security assertionmarkup language: Simplifying single sign-on. IEEE Security and Privacy,6:83–85, March 2008.

[12] Internet2. OpenSAML Wiki, 2011. Available at https://wiki.shibboleth.net/confluence/display/OpenSAML/Home/.

[13] Internet2. Shibboleth Wiki, 2011. Available at https://wiki.shibboleth.net/confluence/display/SHIB2/Home.

[14] S. Josefsson. The Base16, Base32, and Base64 Data Encodings. RFC 4648(Proposed Standard), October 2006.

[15] F. Ljunggren. Chatt om identifikation på nätet. Dagens Ny-heter, March 4, 2011. Available at http://www.dn.se/vart-internet/vart-internet---hem/chatt-om-identifikation-pa-natet.

[16] M. Mealling. Dynamic Delegation Discovery System (DDDS) Part Three: TheDomain Name System (DNS) Database. RFC 3403 (Proposed Standard), Oc-tober 2002.

[17] M. Mealling and R. Daniel. The Naming Authority Pointer (NAPTR) DNSResource Record. RFC 2915 (Proposed Standard), September 2000. Obsoletedby RFCs 3401, 3402, 3403, 3404.

[18] Olav Morken. SimpleSAMLphp Service Provider QuickStart. Vis-ited, July 14, 2011. Available at http://simplesamlphp.org/docs/1.8/simplesamlphp-sp.

[19] OpenID Foundation. OpenID Wiki – OpenID Phishing Brainstorm. Visited,June 15, 2011. Available at http://wiki.openid.net/w/page/12995216/OpenID_Phishing_Brainstorm.

[20] Organization for the Advancement of Structured Information. SAML v2.0 Spec-ification, 2005. Available at http://saml.xml.org/saml-specifications.

[21] N. Ragouzis, J. Hughes, R. Philpott, E. Maler, P. Madsen, and T. Scavo.Security assertion markup language (SAML) v2.0 Technical Overview. Com-mittee Draft sstc-saml-tech-overview-2.0-cd-02, 1:13, 2008. Available at http://saml.xml.org/saml-technical-overview.

[22] Swedbank AB (publ). Swedbank Online Bank Identity Provider. Visited,July 7, 2011. Available at https://internetbank.swedbank.se/bviPrivat/privat?ns=1.

[23] I. Thomas and C. Meinel. An identity provider to manage reliable digitalidentities for SOA and the web. In Proceedings of the 9th Symposium on Identityand Trust on the Internet, IDTRUST ’10, pages 26–36, New York, NY, USA,2010. ACM.

38

Appendix A

Technical terms and abbreviations

• SAML – Security Assertion Markup Language.

• XML – Extensible Markup Language.

• HTML – HyperText Markup Language.

• HTTPS – HTTP Secure, a combination of HTTP and SSL/TLS that providesencrypted communication between a browser and a web server.

• IdP – Identity Provider.

• SP – Service Provider.

• OASIS – Organization for the Advancement of Structured Information Stan-dards.

• Asserting party – The SAML party that issues assertions.

• Relying party – The SAML party that relies on assertion.

• Base64 – An encoding used for representing arbitrary sequences of binaryoctets in a form that uses mostly upper- and lowercase letters. Specified byRFC4648 [14].

• URL-encode – Also known as percent-encoding. An encoding mechanism usedto represent binary octets not valid in a URL. Specified by section 2.1 inRFC3986 [2].

• DNS – Domain Name System.

• URL – Uniform Resource Locator.

• URI – Uniform Resource Identifier.

39

APPENDIX A. TECHNICAL TERMS AND ABBREVIATIONS

• DOM – Document Object Model, a simple and powerful method of represent-ing and interacting with several markup languages such as HTML and XML.The hierarchical nature of these markup languages is used for creating an ob-ject representation of the document, where each object has links to its parentand children objects.

• SOAP – Simple Object Access Protocol, a protocol for exchanging structuredinformation in web services.

• SSO – Single Sign-On.

40

Appendix B

Metadata

This appendix contains the final metadata used by the identity provider in theprototype implementation, as well as the metadata used by the example serviceprovider set up for testing.

B.1 Identity provider

1 <?xml version="1.0" encoding="utf-8"?>2 <md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"3 xmlns:ds="http://www.w3.org/2000/09/xmldsig#"4 entityID="https://idp.swedbank.se">5 <md:IDPSSODescriptor WantAuthnRequestsSigned="true"6 protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">7 <md:KeyDescriptor use="signing">8 <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">9 <ds:X509Data>

10 <ds:X509Certificate>MIIDW...OJipr90=</ds:X509Certificate>11 </ds:X509Data>12 </ds:KeyInfo>13 </md:KeyDescriptor>14 <md:KeyDescriptor use="encryption">15 <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">16 <ds:X509Data>17 <ds:X509Certificate>MIIDW...OJipr90=</ds:X509Certificate>18 </ds:X509Data>19 </ds:KeyInfo>20 <md:EncryptionMethod21 Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc">22 <xenc:KeySize23 xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">24 128

41

APPENDIX B. METADATA

25 </xenc:KeySize>26 </md:EncryptionMethod>27 </md:KeyDescriptor>28 <md:SingleLogoutService29 Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"30 Location="https://idp.swedbank.se/SingleLogoutService"/>31 <md:NameIDFormat>32 urn:oasis:names:tc:SAML:2.0:nameid-format:transient33 </md:NameIDFormat>34 <md:SingleSignOnService35 Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"36 Location="https://idp.swedbank.se/SSOService"/>37 </md:IDPSSODescriptor>38 <md:ContactPerson contactType="technical">39 <md:GivenName>IdP</md:GivenName>40 <md:SurName>Administrator</md:SurName>41 <md:EmailAddress>[email protected]</md:EmailAddress>42 </md:ContactPerson>43 </md:EntityDescriptor>

B.2 Service provider

1 <?xml version="1.0" encoding="utf-8"?>2 <md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"3 entityID="https://sp1.swedbank.se">4 <md:SPSSODescriptor5 protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol6 urn:oasis:names:tc:SAML:2.0:protocol">7 <md:KeyDescriptor use="signing">8 <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">9 <ds:X509Data>

10 <ds:X509Certificate>MIIDmzCC...UTNURu</ds:X509Certificate>11 </ds:X509Data>12 </ds:KeyInfo>13 </md:KeyDescriptor>14 <md:KeyDescriptor use="encryption">15 <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">16 <ds:X509Data>17 <ds:X509Certificate>MIIDmzCC...UTNURu</ds:X509Certificate>18 </ds:X509Data>19 </ds:KeyInfo>20 </md:KeyDescriptor>21 <md:SingleLogoutService

42

B.2. SERVICE PROVIDER

22 Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"23 Location="https://sp1.swedbank.se/Swedbank-SP"/>24 <md:AssertionConsumerService25 Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"26 Location="https://sp1.swedbank.se/Swedbank-SP"27 index="0"/>28 <md:AssertionConsumerService29 Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"30 Location="https://sp1.swedbank.se/Swedbank-SP"31 index="1"/>32 <md:AssertionConsumerService33 Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"34 Location="https://sp1.swedbank.se/Swedbank-SP"35 index="2"/>36 <md:AssertionConsumerService37 Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01"38 Location="https://sp1.swedbank.se/Swedbank-SP/artifact"39 index="3"/>40 </md:SPSSODescriptor>41 <md:ContactPerson contactType="technical">42 <md:GivenName>SP</md:GivenName>43 <md:SurName>Administrator</md:SurName>44 <md:EmailAddress>[email protected]</md:EmailAddress>45 </md:ContactPerson>46 </md:EntityDescriptor>

43

Appendix C

SAML Response

This appendix contains a SAML-response sent by the identity provider in the pro-totype implementation to the example service provider.

C.1 SAML Response

1 <?xml version="1.0" encoding="UTF-8"?>2 <saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"3 Destination="https://sp1.swedbank.se/Swedbank-SP"4 ID="_e275b1195a20a66e92d813abc72eac76"5 InResponseTo="_eb53d3837b82d1f11927502265f05e65d625ba49a9"6 IssueInstant="2011-05-31T09:34:51.949Z" Version="2.0"7 xmlns:xs="http://www.w3.org/2001/XMLSchema">8 <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">9 https://idp.swedbank.se

10 </saml2:Issuer>11 <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">12 <ds:SignedInfo>13 <ds:CanonicalizationMethod14 Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>15 <ds:SignatureMethod16 Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>17 <ds:Reference URI="#_e275b1195a20a66e92d813abc72eac76">18 <ds:Transforms>19 <ds:Transform20 Algorithm="http://www.w3.org/2000/09/xmldsig21 #enveloped-signature"/>22 <ds:Transform23 Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">24 <ec:InclusiveNamespaces25 xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"

45

APPENDIX C. SAML RESPONSE

26 PrefixList="xs"/>27 </ds:Transform>28 </ds:Transforms>29 <ds:DigestMethod30 Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>31 <ds:DigestValue>32 F8o4m6+pzrg+jbUG7oA2+09LvGQ=33 </ds:DigestValue>34 </ds:Reference>35 </ds:SignedInfo>36 <ds:SignatureValue>iATY7nvZf...lierQ==</ds:SignatureValue>37 <ds:KeyInfo>38 <ds:X509Data>39 <ds:X509Certificate>40 MIIDWDCCAkCg...ckOJipr90=41 </ds:X509Certificate>42 </ds:X509Data>43 </ds:KeyInfo>44 </ds:Signature>45 <saml2p:Status>46 <saml2p:StatusCode47 Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>48 </saml2p:Status>49 <saml2:Assertion50 xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"51 ID="_ca9986e2e6d02e4abd226b2a4d2606f7"52 IssueInstant="2011-05-31T09:34:51.949Z" Version="2.0"53 xmlns:xs="http://www.w3.org/2001/XMLSchema">54 <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">55 https://idp.swedbank.se56 </saml2:Issuer>57 <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">58 <ds:SignedInfo>59 <ds:CanonicalizationMethod60 Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>61 <ds:SignatureMethod62 Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>63 <ds:Reference URI="#_ca9986e2e6d02e4abd226b2a4d2606f7">64 <ds:Transforms>65 <ds:Transform66 Algorithm="http://www.w3.org/2000/09/xmldsig67 #enveloped-signature"/>68 <ds:Transform69 Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">

46

C.1. SAML RESPONSE

70 <ec:InclusiveNamespaces71 xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"72 PrefixList="xs"/>73 </ds:Transform>74 </ds:Transforms>75 <ds:DigestMethod76 Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>77 <ds:DigestValue>78 b4l8LS/RVm0FFp6F1itfGY0SOX8=79 </ds:DigestValue>80 </ds:Reference>81 </ds:SignedInfo>82 <ds:SignatureValue>L7MMo9p8R.../febQ==</ds:SignatureValue>83 <ds:KeyInfo>84 <ds:X509Data>85 <ds:X509Certificate>86 MIIDWDCCAkCg...ckOJipr90=87 </ds:X509Certificate>88 </ds:X509Data>89 </ds:KeyInfo>90 </ds:Signature>91 <saml2:Subject92 xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">93 <saml2:NameID94 Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>95 <saml2:SubjectConfirmation96 Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">97 <saml2:SubjectConfirmationData98 InResponseTo="_eb53d3837b82d1f11927502265f05e65d625ba49a9"99 NotBefore="2011-05-31T09:24:51.949Z"

100 NotOnOrAfter="2011-05-31T09:44:51.949Z"101 Recipient="https://sp1.swedbank.se/Swedbank-SP"/>102 </saml2:SubjectConfirmation>103 </saml2:Subject>104 <saml2:Conditions NotBefore="2011-05-31T09:24:51.949Z"105 NotOnOrAfter="2011-05-31T09:44:51.949Z"106 xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">107 <saml2:AudienceRestriction>108 <saml2:Audience>https://sp1.swedbank.se</saml2:Audience>109 </saml2:AudienceRestriction>110 </saml2:Conditions>111 <saml2:AuthnStatement AuthnInstant="2011-05-31T09:34:51.949Z"112 SessionNotOnOrAfter="2011-05-31T09:44:51.949Z"113 xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">

47

APPENDIX C. SAML RESPONSE

114 <saml2:AuthnContext>115 <saml2:AuthnContextClassRef>116 urn:oasis:names:tc:SAML:2.0:ac:classes:117 InternetProtocolPassword118 </saml2:AuthnContextClassRef>119 </saml2:AuthnContext>120 </saml2:AuthnStatement>121 <saml2:AttributeStatement>122 <saml2:Attribute Name="FirstName">123 <saml2:AttributeValue124 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"125 xsi:type="xs:string">Niklas</saml2:AttributeValue>126 </saml2:Attribute>127 <saml2:Attribute Name="LastName">128 <saml2:AttributeValue129 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"130 xsi:type="xs:string">Mornesten</saml2:AttributeValue>131 </saml2:Attribute>132 </saml2:AttributeStatement>133 </saml2:Assertion>134 </saml2p:Response>

48

TRITA-CSC-E 2011:137 ISRN-KTH/CSC/E--11/137-SE

ISSN-1653-5715

www.kth.se

providing identification services to external entities ... · providing identification services to...

Documents