Providing Identification Services to External Entities using SAML NIKLAS MÖRNESTEN

Transcription

1 Providing Identification Services to External Entities using SAML NIKLAS MÖRNESTEN Master of Science Thesis Stockholm, Sweden 2011

2 Providing Identification Services to External Entities using SAML NIKLAS MÖRNESTEN 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 Royal Institute of Technology School of Computer Science and Communication KTH CSC SE Stockholm, Sweden URL:

3 Abstract This project investigates approaches for implementing a method for providing identification services to external entities using SAML. SAML attempts to provide standardized means of exchanging authentication data between multiple parties. By implementing support for SAML both so-called service providers and identity providers can reach a large number of other entities that have done the same. An evaluation of different SAML-features and SAML-libraries was performed in order to produce a prototype that is described in this report. The result of the prototype is a system that allows a user to log in to external websites using existing identification infrastructure such as the user s online bank, with the use of SAML between the service and the identity provider.

4 Sammanfattning Att tillhandahålla identifieringstjänster till externa entiteter med SAML Den här rapporten undersöker olika metoder för att kunna tillhandahålla identifieringstjänster till externa entiteter med SAML. SAML försöker att tillhandahålla ett standardiserat sätt att utbyta autentisieringsdata mellan flera parter. Genom att implementera stöd för SAML kan både så kallade tjänsteleverantörer och identitetsleverantörer nå ett stort antal andra entiteter som gjort detsamma. En utvärdering av olika SAML-funktioner och SAML-bibliotek gjordes för att kunna skapa en prototyp som är beskriven i denna rapport. Resultatet av prototypen är ett system som tillåter en användare att logga in på externa webbtjänster genom användandet av existerande identifieringsinfrastruktur såsom användarens internetbank, med hjälp av SAML mellan tjänsteoch identitetsleverantören.

5 Acknowledgements This degree project is the result of the final course work in the Computer Science programme at the Royal Insititute of Technology (KTH) in Stockholm and has been carried out at Swedbank AB. Special thanks go to my supervisor, Markus Backman, at Swedbank for his time and for providing the necessary support.

6

7 Contents 1 Introduction Single sign-on (SSO) Motivation Authentication adaptation of new systems SAML The goal of this project Swedbank Organization Background Electronic identification and SAML in Sweden SAML Overview Participants Assertions Protocols Bindings Profiles Metadata Exchange of metadata SAML software libraries OpenSAML Shibboleth JBoss PicketLink OpenAM Web SSO using SAML Pre-study Open questions with SAML Web SSO Requirements Security Method and implementation Implementation

8 4.1.1 SAML features to use Phishing Anti-phishing features Functionality Design Signatures and encryption Results Communication The SAML Authentication Request Metadata lookup The SAML Response Testing Conclusions and recommendations SAML conclusions SAML libraries Signatures and encryption Difficulties Bibliography 37 Appendices 38 A Technical terms and abbreviations 39 B Metadata 41 B.1 Identity provider B.2 Service provider C SAML Response 45 C.1 SAML Response

9 Chapter 1 Introduction This chapter provides an introduction to the degree project, presents the organization of and the motivation behind the report and also contains a brief explanation of the terms that are relevant for the project. For a complete list of technical terms and abbreviations, please refer to appendix A. 1.1 Single sign-on (SSO) The problem of authenticating users against services is a growing one. The number of services, especially on the internet in the form of web applications is growing rapidly. These types of services typically have some sort of protected or personalized content. In order to authenticate users on the sites one common method is to use a digital identity in the form of a username and a password. Managing these multiple digital identities and associated authentication credentials is difficult for most users [23]. Since the number of services is increasing, a single user today has to keep track of an increasing number of usernames and passwords. Ideally these passwords should all be unique and randomly generated, but this makes remembering them a difficult task. One way of solving this problem is to implement a system that allows a user to log in to multiple systems at once. Single sign-on (SSO) is a concept where users can enter their credentials once and then gain access to multiple systems without being prompted to log in to each individual system. Single sign-on solutions use centralized authentication servers in order to authenticate users across different systems, a concept that can also be used in an organization to provide an authentication service for its users to third party services. There exist many proprietary implementations of such single sign-on solutions: something that can be troublesome if one, as an identity provider, wants support for a wide variety of external services. 1

10 CHAPTER 1. INTRODUCTION 1.2 Motivation When businesses and organizations possess identification methods for customers it is often in the businesses or organizations interest to be able to provide these identification methods to third parties in a secure way. In other words, businesses want to be able to act as an identity provider towards other service providers in identifying customers and signing them on to external services. One way of communicating such authentication information is by the use of SAML (Security Assertion Markup Language), an XML-based framework that allows business entities to make assertions regarding users to other third party entities such 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 order to gain access to multiple internal and external systems. Simplifying adaptation of new systems. When introducing new systems, both internally and externally, one would prefer a simple way of configuring the new system 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 to continue to use an existing mechanism for authentication, the question of how to integrate the two separate systems arises. One would typically want to keep the existing authentication mechanism and ideally have the already logged-in users automatically logged into the new system. With systems being developed or purchased by numerous different companies a standardized way for the systems to exchange the required authentication details of users would be desired. This would enable new systems 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 between multiple parties. By implementing support for SAML, both service providers and identity providers can reach a large number of entities that also have implemented support 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 identity data such as single sign-on, single sign-out and communication of identity data both using a forwarding entity (typically a web browser) as well as a separate dedicated communication channel between the two entities. 2

11 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 support for SAML for an identity provider, e.g. Swedbank, using multiple identification methods and a customer base of several million users, for use towards both internal and 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 able to 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-compatible identity 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, but it should possess enough functionality to make informed decisions about the types of libraries to be used. It should also be able to motivate which parts of 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 an international customer base of 9.5 million retail customers and more than 500,000 corporate customers. The group has 377 branches in Sweden with an additional 224 branches in the Baltic countries. Almost all of these customers have an identification method issued by Swedbank, used for electronic identification and authentication towards the bank, which for the customers in Sweden, include identification via security token, BankID on card, BankID in mobile and personal code. These identification methods are used for providing the customers with a secure way of doing their banking online. As Swedbank is a large identity provider, as in one that is able to provide identification services to many of its customers, Swedbank desires collaboration with other service providers where its identification and authentication services can be provided to other services. 3

12 CHAPTER 1. INTRODUCTION 1.7 Organization The organization of the report is as follows. Chapter 2 contains background and theory of electronic identification and also provides an overview to SAML and Single Sign-On. Chapter 3 comprises a pre-study which was necessary to conduct before choosing a method for implementing the prototype. Chapter 4 contains the results from the pre-study as well as details of how the prototype-implementation was done while chapter 5 provides the results of the prototype and chapter 6 the conclusions and further recommendations of using SAML and the library used. 4

13 Chapter 2 Background This chapter provides background information for the remainder of the report. It contains an introduction to the problem of electronic identification, an overview of the different parts of SAML as well as descriptions of various software libraries that implement SAML. The chapter also describes the Web Single Sign-On scenario using SAML. 2.1 Electronic identification and SAML in Sweden As previously mentioned, the number of services on the web is increasing rapidly. In Sweden, the topic of identification on the internet has gained importance with the introduction of a government authority (E-legitimationsnämnden) assigned the task of developing a new federation-based identification service 1 for Swedish citizens [7]. There already exists a group of established national identity providers for Swedish citizens which consists of a collection of issuers ranging from banks to telephone operators. One of the largest identity providers is called BankID [8]. The new federation consists of both identity and service providers. The identity providers are under regulation by the mentioned government authority which ensures 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 new providers connecting to the federation [15]. As Swedbank could act as an identity provider in this new federation, it gives Swedbank additional motivation to implement SAML-support. 2.2 SAML Overview SAML is developed and maintained by OASIS Security Services Technical Committee [20] and is an XML-based framework for describing and exchanging security 1 A federation-based identification service is a service that can link together multiple online identities into a so-called federated identity. 5

14 CHAPTER 2. BACKGROUND information between on-line business partners [21]. It is mainly driven forward by three concepts: Single sign-on In the past, products that claimed to provide web-based SSO typically used browser cookies. Since browser cookies only work within a single domain other proprietary solutions were used for multi-domain SSO (MDSSO). Organizations, however, typically used different vendors implementations and so cross-organization collaboration was complicated. SAML solved the MDSSO problem by providing a standardized vendor-independent platform for communicating authentication data of users between two web servers, completely independent of other domain limited solutions. Federated identity Another use case for cross-organizational collaboration is with federated identities. A user is said to have a federated identity when two 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 organizations to maintain identity-related data or synchronize identity-based databases. SAML provides a standardized way of communicating between the entities in order to set up such an identity. Web services SAML allows for its security assertions to be used outside of the otherwise defined SAML contexts. This adaptation has proved useful to other services, for instance the ability to use SAML s assertions within a web service security token that can be used in encrypting web service SOAP messages [21]. This SAML overview section covers a subset of the SAML v2.0 specification in greater detail. It covers the SAML areas of profiles, protocols, assertions and bindings. These areas make up the SAML-specification and their relationship can be conceptually modeled as in Figure Participants In any SAML interaction the involved entities are SAML asserting parties and SAML relying parties. An asserting party in a SAML environment issues assertions while a relying party uses the assertions. SAML also refers to the party that makes a direct request to another entity a SAML requester and the responding entity the SAML responder. Both the asserting party and the relying party can be equally requester and responder. In addition to the above participants SAML also defines roles which are present in different SAML scenarios. For example in the single sign-on context SAML defines the roles identity provider (IdP) and service provider (SP) where the identity provider is the asserting party issuing assertions to the relying party, in this case, the service provider. 6

15 2.2. SAML OVERVIEW Profiles Combinations of assertions, protocols and bindings to support a defined use case Bindings Mappings of SAML protocols onto standard messaging and communication protocols Protocols Requests and responses for obtaining assertions and doing identity management Assertions Authentication, attribute, and entitlement information Metadata Configuration data for identity and service providers Figure 2.1. Relationships of different SAML-areas covered by the SAMLspecification. The subject in a SAML context is normally the user, found in most assertions issued Assertions An assertion in SAML allows an asserting party to assert security information about a subject in the form of different statements. Each SAML assertion contains some basic 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 been successfully authenticated. These statements are created by the entity that has authenticated the user. Authentication statements contain, at the very least, the type of authentication method used and the date and time the user was authenticated. 7

16 CHAPTER 2. BACKGROUND Attribute statements: These statements contain attributes that are applicable to the authenticated user such as personal details, group memberships etc. Authorization decision statements: These can contain decisions taken by the issuing party defining which actions a user is authorized to perform. The assertion is encapsulated within a SAML response message as shown in Figure 2.2. Transport protocol Transport protocol header Transport protocol payload SAML response Assertion Authentication statement Other statements Figure 2.2. Encapsulation of SAML-assertions in a SAML-response Protocols Several protocols exist in SAML that describe the communication between two parties in different contexts. Authentication Request Protocol: A protocol that describes how an entity can request assertions from an assertion-issuing entity. In the Web Browser SSO Profile this protocol is used to initiate the sign-on process where the service provider issues an authentication request to the identity provider. 8

17 2.2. SAML OVERVIEW Single Logout Protocol: This is a protocol that allows a user to be logged out of multiple services nearly simultaneously. The logout process can be initiated from any of the service providers, the identity provider or by the user. Assertion Query and Request Protocol: This describes the protocol used for querying or requesting assertions over an unspecified binding. Artifact Resolution Protocol: This describes a protocol used for resolving artifacts, which are later used for retrieving assertions. An artifact is defined as a small fixed-length value. The party that receives the artifact uses the Artifact Resolution Protocol to ask the creator of the artifact to dereference the artifact in order to receive the actual message, which is typically an assertion. Name Identifier Management Protocol: This specifies the protocol of communicating changes in value or format of a name identifier used to refer to a subject. Name Identifier Mapping Protocol: This specifies the protocol of mapping a previously agreed upon SAML name identifier into a new one between two or more parties Bindings Bindings in SAML are defined as the transport protocols over which the overlying SAML messages can be sent. The bindings defined are: HTTP Redirect Binding A binding which defines how HTTP 302 redirects can be used to send Base64 2 -encoded SAML-messages. HTTP POST Binding A binding which defines how Base64-encoded SAML messages can be transported in HTML forms over HTTP POST 3 requests. HTTP Artifact Binding A binding which defines how artifacts can be sent from a message sender to a message receiver. This is supported via either HTML-form data or via URL-request parameters. SAML SOAP Binding This binding is used for sending SAML-messages over SOAP Reverse SOAP (PAOS) Binding This binding allows an HTTP client to act as a SOAP responder and can be used in some of the SAML profiles. SAML URI Binding A binding which defines how to retrieve an existing SAML assertion by resolving a uniform resource identifier (URI). 2 See appendix A for a brief explanation of Base64-encoding. 3 HTTP POST is a type of command present in the HTTP-protocol. See appendix A for a longer description. 4 SOAP, Simple Object Access Protocol, a protocol for exchanging structured information in web services. 9

18 CHAPTER 2. BACKGROUND Profiles SAML defines a set of profiles which lay down rules and constraints for how assertions and bindings are used in the different SAML scenarios. SAML specifies the following profiles: Web Browser SSO Profile. This profile covers how SAML messages are used for achieving 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 Web Browser SSO Profile which enables specialized clients such as mobile clients to use SOAP and reverse-soap (PAOS). Identity Provider Discovery Profile. This describes a mechanism for letting a service provider automatically find a user s identity provider which the user has previously visited. Single Logout Profile. Tightly coupled with the Web Browser SSO Profile, it describes how to achieve single logout from multiple identity and service providers with use of the SOAP, HTTP Redirect, HTTP POST and HTTP Artifact bindings. Assertion Query/Request Profile. This describes a mechanism for querying or requesting assertions from an asserting party over the SAML SOAP binding. Requesting in this context means asking for an existing assertion given an assertion id while querying means asking for new assertions based on certain criteria. Artifact Resolution Profile. This is a profile which describes how to resolve an artifact over a SAML SOAP binding. Name Identifier Management Profile. This provides details on how to modify or terminate the value or format of a name identifier that identifies a subject with the use of the SOAP, HTTP Redirect, HTTP POST or HTTP Artifact bindings. Both the service provider and the identity provider can issue such a request. Name Identifier Mapping Profile. This is a profile which explains a mechanism for mapping one name identifier to another. A service provider can, for example, request a new mapping for a subject, which it can in turn use for integration with another service provider Metadata SAML metadata is used for connecting different entities in a SAML-enabled configuration. The metadata document contains information such as identifiers, binding 10

19 2.3. SAML SOFTWARE LIBRARIES support, endpoints and certificates for each of the entities. The SAML specification also specifies how this metadata should be formatted with the goal of simplifying configuration when adding new parties to a SAML-enabled system. Each metadata document is XML-based and contains one or more entities that can contain one or more roles. For example a SAML system entity can act as an identity 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 an entity acting as the role identity provider. Each party involved in any SAML configuration has this type of metadata. For an example of metadata for a service provider, please see appendix B Exchange of metadata The exchange of metadata can be accomplished in several different ways. The simplest way of exchanging metadata is by manual means not specified in the SAMLspecification. This could be over secure , various physical media, etc. The SAML metadata-specification, however, also describes ways of automatically and securely retrieving such metadata, something which is necessary if one wants to be able to support anonymous 5 service providers. One way of automatically publishing and resolving metadata is by what the SAML specification refers to as via well-known location [5]. The entity ID of a SAML-enabled entity is typically a valid URL. At this URL the metadata document describing the entity can be placed, and therefore, a partnering SAML-entity can retrieve 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 the use of DNS [5]. The input for resolution of the metadata is still the party s entity id. Instead of accessing the full URI, only the domain name of the URI is used. Once the domain name has been established, the URL of the metadata can be derived through 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 metadata document, which means details of the available publishing methods also exist within the NPATR Resource Records. 2.3 SAML software libraries Since one of the main goals of SAML is to be able to provide a standardized way of communicating authentication data, many implementations of SAML exist. The implementations come both in the form of software libraries, used for generating SAML-messages, as well as stand-alone SAML-compatible products that can be integrated with an existing application. 5 Anonymous here refers to the fact that the identity provider does not know of the service provider beforehand. It does not mean that the service provider is or can be fully anonymous. 11

20 CHAPTER 2. BACKGROUND The following sections describe a few popular software libraries and stand-alone applications OpenSAML OpenSAML is an open source library developed and maintained by the organization Internet2 and is a library that has both Java and C++ bindings [12]. It is a very low-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 generated messages conform to the SAML-specification. It does, however, provide helpful features such as cryptographic validation of signatures and the ability to encrypt, sign and compress messages. The SAML-messages are built using a Document Object Model (DOM 6 ) which is later marshalled to form actual XML-output. This makes the creation of messages extremely versatile Shibboleth Shibboleth is an open source library and, as is OpenSAML, also developed by Internet2 [13]. Shibboleth, however, works at a higher level than OpenSAML, providing native support for all bindings in the SAML-specification. Shibboleth ships in two parts, an IdP (identity provider) and an SP (service provider). Both of these are highly configurable stand-alone applications which means that in order to successfully set up a complete SAML-enabled entity one does not have to program using any libraries, but merely configure the stand-alone identity or service provider. Configuration of the Shibboleth identity provider includes adding relevant service providers together with their corresponding metadata, as well as installing the certificate for the identity provider so that Shibboleth is able to generate the identity provider s metadata JBoss PicketLink JBoss PicketLink is open source software developed by JBoss. As Shibboleth, JBoss PicketLink is stand-alone software that is deployed on a Java server as a web application [1]. The application is then used as a proxy for intercepting requests in order to be able to handle sessions. Configuration therefore consists of similar tasks as for Shibboleth, such as setting up certificates, customizing the login page etc., which makes it a similar alternative to Shibboleth OpenAM OpenAM, previously known as OpenSSO, was originally developed by Sun. When Oracle, with the acquisition of Sun, chose to discontinue the development of OpenSSO 6 See appendix A for a brief explanation. 12

21 2.4. WEB SSO USING SAML ForgeRock announced that it would continue to develop and maintain OpenSSO under 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 and encrypting messages and choosing a user store, a database of users that should be able to sign-in. 2.4 Web SSO using SAML As previously mentioned, the SAML Web Single Sign-On scenario is one of the main driving forces for the creation of SAML. The SAML Web SSO scenario can be used with several different SAML-bindings, most notably, the HTTP Redirect binding, the HTTP POST binding and the HTTP Artifact binding. This section contains a detailed example of two SAML-enabled parties in a SAML Web Browser SSO Profile configuration using multiple bindings and protocols. Figure 2.3 shows the flow of a SAML-setup using the HTTP Redirect and HTTP Post bindings: Access check Service Provider sp1.swedbank.se Assertion Consumer Service Single Sign-On Service Identity Provider idp.swedbank.se Access resource 1 7 Supply resource 2 Redirect with <AuthnRequest> POST signed <Response> 6 Signed <Response> in HTML form 5 GET using <AuthnRequest> 3 Challenge for credentials User login 4 Browser User or automated action Automated action Figure 2.3. Illustration of the message flow during sign-in with relevant entities. 13

22 CHAPTER 2. BACKGROUND 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 corresponding user, and if no such context exists, generates a SAML authentication request which is Base64-encoded (according to RFC4648 [14]) and embedded as a GET-parameter in a URL of the identity provider as described by the SAML HTTP Redirect binding [4]. The web server then issues a HTTP redirect response 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 connection to the identity provider, the SAML authentication request still embedded within the URL of the request. 4. The identity provider receives the authentication request, checks for a local session context for the corresponding user, and if no such context exists, returns HTML that challenges the user for authentication credentials. 5. The user provides necessary credentials, sending them back to the identity provider. 6. The identity provider verifies the credentials, and if correct creates a local session context for the user and then issues a SAML authentication response containing an assertion. The SAML-response contains data of how and when the user was authenticated, by what means the user has authenticated itself as well as potential custom attributes such as what groups the user is a member of, memberships the user has, etc. This response and the assertion are typically signed by the identity provider to avoid tampering. Finally the SAML-response is Base64-encoded and placed as the value of a hidden form in HTML which is returned to the users web browser as described by the SAML HTTP Post binding [4]. 7. The browser receives the HTML and submits the form to the service provider either automatically using Javascript or manually by the user if Javascript has been disabled. 8. The service provider receives the authentication response, validating any signatures present within the response and then creates a local session context for the user, returning the protected content originally requested to the user. 14

23 Chapter 3 Pre-study In order to build a prototype capable of securely authenticating users towards other entities, some questions arise that need to be addressed immediately before the design of the prototype starts. The pre-study chapter of this report formalizes these questions into requirements for the prototype. 3.1 Open questions with SAML Web SSO While SAML is extremely flexible and versatile, using it in the even somewhat basic case of normal web-based browser single sign-on can still be very challenging. Many SAML-implementations today generally require the administrator to have a deep understanding of the SAML-standard. P. Harding, L. Johansson and N. Klingenstein highlight this by bringing forth questions that have to be answered by anyone 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 a single sign-on environment. 3.2 Requirements In addition to the above open questions that need to be answered, in this specific case there exist a number of requirements that are specific for Swedbank. This 15

24 CHAPTER 3. PRE-STUDY is because Swedbank eventually wishes to integrate the developed prototype into its online bank. This integration with Swedbank s online bank in turn creates requirements also for the prototype which are listed below in table 3.1. ID Requirement Motivation 1 Prototype must be implemented in Future integration of prototype with Java. existing IdP software is desired, 2 Prototype must be easily extendable when integration is desired with new service providers. 3 Prototype must be capable of being integrated with the existing identity provider software. 4 Libraries must have support for SAML Communication between identity provider and service provider should be solely via the web browser. 6 Solution for handling metadata of service providers must be scalable in terms of administration effort. 7 Solution should not be vulnerable to a particular sort of phishing attack. 8 Only known service providers should be able to interact with the identity provider. Table 3.1. Table of requirements which is Java-based. Work is reduced if integration with new service providers is uncomplicated. Support for authentication with several authentication methods is already implemented in existing identity provider software. Support for communication with SAML 2.0-speaking peers is desired. If all communication is done via the web browser there is no need to set up new direct connections between parties when adding service providers which eases integration. A scalable solution for adding new service providers should minimize code duplication and allow for simple addition of new service providers. One does not want a malicious site to be able to send users to the identity provider only to return to a malicious phishing site. One wants to ensure with which services the organization is associated. 3.3 Security One of the main points of SAML is that implementers desire their solution to be secure. Secure is a broad term which in this specific case can mean several things: 16

25 3.3. SECURITY Integrity One wants to be able to make sure that messages sent between the parties have not been modified by anyone. Authenticity One wants to know that the message was actually sent by the entity that it was claimed to be sent by. Confidentiality No-one else but the trusted partner entity should be able to read the message. Along with this there are several other potential attacks one might want to be secure against: Replay attacks An evil party that has recorded a message should not be able to resend it and successfully authenticate themselves or someone else. Phishing attacks An evil party should not be able to send a legitimate user to a fraudulent website after the user authenticates itself at the identity provider. Denial-of-service attacks An evil party should not easily be able to take down the system by e.g. generating excessive load. Prior to starting work on the prototype, it had to be decided which of these qualities were required and this is answered in the next chapter. 17

26

27 Chapter 4 Method and implementation This chapter contains the results of the pre-study with a brief discussion and motivation of the choices made. It also describes the implementation and what SAML features should be used. 4.1 Implementation A prototype was implemented that showed functionality of a working identity provider 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), OpenSAML was chosen as the library to use. The main reason for choosing OpenSAML over any of the other libraries is that due to its low-level design it is possible to integrate with Swedbank s existing infrastructure. Since Swedbank already has an identity provider [22], it becomes natural to integrate SAML-support into the existing identity provider software, instead of integrating a stand-alone product (such as Shibboleth, OpenAM or JBoss PicketLink) with the existing software. OpenSAML also has Java bindings and support for SAML 2.0 [12] which was requirement 4 on page 16. Because of the lack of validation routines in OpenSAML, using it requires a relatively deep understanding of the SAML-specification. The SAML-specification itself contains many uses of the keywords SHOULD, MUST, RECOMMENDED as described by RFC2119 [3], something one as a user of the library has to consider when building messages using OpenSAML. This can make programming using the OpenSAML library more time-consuming than using other libraries or stand-alone SAML-implementations. 19

28 CHAPTER 4. METHOD AND IMPLEMENTATION Swedbank Online Bank internetbank.swedbank.se Identity Provider idp.swedbank.se Browser Service Provider sp1.swedbank.se Service Provider sp2.swedbank.se Figure 4.1. Overview of the systems involved with arrows symbolizing communication. The lighter box titled Identity Provider corresponds to the prototype implementation 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 SAML identity 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 identity provider to have carried out whatever authorization checks that are needed. Authentication statements are the fundamental part of an assertion which are used in order to say when and by what means a user has been authenticated. 20

29 4.1. IMPLEMENTATION Attribute statements may be used as they are common practice when the service provider requires more structured data about a user. This could, for example, 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 Request Protocol, which is used when the service provider initiates the authentication procedure, and the optional Single Logout Protocol which is used if a singlelogout 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 and the HTTP Post Binding. The redirect binding is commonly used by the service provider when issuing the authentication request towards the identity provider. It is generally not used if the authentication request is signed since although permissible URL length is theoretically infinite, the limit is often unpredictable and hence the HTTP Post Binding is used instead [4]. The HTTP Post Binding is used by the identity provider in order to send the SAML-response back to the service provider. These two bindings are fully browser based which conforms to the browser requirement (requirement 5). The SOAP and Artifact bindings, which are not (solely) browser based are therefore not relevant. Profiles: The main profile studied for use with the prototype is the SAML Web Browser SSO Profile. Together with the Single Logout Profile they make up the core of providing authentication of a user towards someone else. The Single Logout Profile can be seen as optional if each party keeps track of the local session context themselves. In those cases each entity can log out the user from their own context, even though the login was only done once. Since only browser-based communication is desired (requirement 5) the Artifact Resolution Profile becomes unnecessary. The Assertion Query/Request profile is not used either, since it is utilized for retrieving existing assertions. The Name Identifier Management and Mapping profiles can be seen as optional for more advanced use cases where multiple involved entities want to keep track of a user after the login has been completed. Such use cases typically involve federated identities. The Identity Provider Discovery Profile is not needed either since anonymous service providers are not allowed (requirement 8). Not having anonymous service providers requires each new service provider to be set up manually, which makes the Identity Provider Discovery Profile superfluous Phishing Phishing is a type of online fraud where an attacker, one way or another, tries to trick users into entering their legitimate credentials by creating a fake website 21

30 CHAPTER 4. METHOD AND IMPLEMENTATION very similar to the original website. It can simply be described as the practice of directing users to fraudulent web sites [6]. Most types of phishing are hard to protect against, since a web page can be copied with ease. Often, the best way of mitigating phishing is by educating the users. Some phishing attacks work by using flaws in the original legitimate system, and it is important to avoid creating such flaws when designing an identity provider. An example of such a flaw is described in the next section Anti-phishing features One of the requirements (requirement 7) is that the single sign-on solution should be resilient against a certain type of phishing attack. This phishing attack is possible when an identity provider either does not authenticate the service provider requesting authentication or blindly trusts the contents of the request. This type of phishing-attack can be difficult to counter, and is not always possible in other single sign-on solutions such as OpenID [19], where an identity provider does not have to know a service provider beforehand. An authentication request typically contains information about who is requesting the authentication of a subject, where the identity provider should redirect the user after this authentication is complete, as well as various timestamps. If this message is not signed in any way then this information could be modified by a man-in-the-middle attack, but equally importantly, a malicious site could send identical information, but with a different return URL, thereby sending the user to the malicious site after first authenticating with the real site. This sort of problem is especially tricky for the user to see as the user only briefly visits the malicious site, is then redirected to the real site where they enter their 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=" 4 Destination=" 5 ID="_eb53d3837b82d1f f05e65d625ba49a9" 6 IssueInstant=" T09: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> 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

31 4.1. IMPLEMENTATION The vulnerable field is the AssertionConsumerServiceURL property on line 3 which tells the identity provider where to send the user after it has successfully authenticated itself. Even if the identity provider does not allow anonymous service providers and checks the Issuer-tag on line 9, the identity provider still needs to check the AssertionConsumerServiceURL against the URL found in locally stored metadata for the given entity ID (line 9) which is one way of solving this problem, but, which of course, requires the identity provider to both know about and trust each service provider it wants to interact with. This problem is hence general for all single sign-on solutions that want to use anonymous service providers. Another solution for solving this issue is for the service provider to sign the authentication request with a key belonging to a certificate trusted by the identity provider. In this scenario the identity provider does not need to know about the service provider, as long as the certificate is trusted (perhaps by signature of a trusted certificate authority). Examples of both signed and unsigned authentication requests are further described in the next chapter Functionality The prototype was developed mainly as a developer API. An example application was however also created to showcase the functionality available in the API. The API is extensible for additions of new SAML-features and for modifying the content in the SAML-messages sent. It has support for the SAML Single Sign-on Profile using both the HTTP Post binding and the HTTP Redirect binding. It can easily be configured per service provider with regard to the signing of different parts of the SAML-messages, the addition of custom attributes or modification of other parts of the SAML-messages. The prototype has support for cryptographic verification of signatures in incoming SAML-messages using the certificates present in the locally stored metadata for each service provider. It does not perform trust verification checks of the certificates themselves such as expiry date checks, revocation status, etc., as this is considered outside of the scope of the application. The application assumes that if the certificate has been manually stored for a service provider then that certificate is deemed valid Design The API uses the builder pattern [10] in order to accommodate extensibility for different service providers. Figure 4.2 shows a class diagram of the prototype Signatures and encryption Some security concerns have already been covered in section (Anti-phishing features). This section however describes how to address more general security concerns first discussed in the pre-study chapter (section 3.3). 23

32 CHAPTER 4. METHOD AND IMPLEMENTATION SSOService IDP SP1ResponseAssembler AbstractResponseAssembler SP2ResponseAssembler SP1ResponseBuilder ResponseBuilder XMLObjectFactory SAMLObjectFactory Figure 4.2. A class diagram of the implemented prototype. A solid line represents inheritance while a dashed line represents usage. Below is a list of those concerns that can be addressed to some degree by the sending 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 matching signature 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

33 4.1. IMPLEMENTATION the unique identification number previously sent in the corresponding SAMLauthentication request. In order to provide authenticity for the first authentication request, the request has to contain a unique identification number as well as a timestamp. In order to guarantee that the message has not been recorded by someone and later resent, the identity provider has to check that the unique identification number has not been previously used as well as check the timestamp present in the request. Confidentiality can be solved by encrypting the messages or ensuring that the entire communication channel is encrypted. This typically happens when communicating over HTTPS. Replay attacks: In order to avoid replay-attacks messages should contain timestamps and unique identification numbers which are then signed. If the other party checks that the number has not been used before then this ensures that replay-attacks are not possible. Phishing attacks can, to some degree, be prevented by signing messages and therefore preventing a malicious user from modifying the URL where the user should be sent after authentication. However, if the service providers are nonanonymous, a simpler way of avoiding phishing attacks is to verify the URL against locally stored metadata. Denial-of-service attacks: In order to avoid denial-of-service attack, validation rules should perform simpler checks before more computationally expensive ones. This means that the system should check that the message is sent from a valid service provider (entity id) before cryptographically verifying the signature attached to the message (which is computationally expensive). 25