Securing Web Services With SAML

Carl A. Foster CS-5260 Research Project Securing Web Services With SAML Contents 1.0 Introduction... 2 2.0 What is SAML?... 2 3.0 History of SAML... 3 4.0 The Anatomy of SAML 2.0... 3 4.0.1- Assertion Query and Request Protocol... 3 4.0.2 - Authentication Request Protocol... 3 4.0.3 - Artifact Resolution Protocol... 4 4.0.4 - Name Identifier Management Protocol... 4 4.0.5 - Single Logout Protocol... 4 4.0.6 - SAML Binding... 4 4.0.7 SSO Profile... 4 5.0 How Web Services Interact... 5 6.0 Web Service Choreography... 5 7.0 Web Service Orchestration... 6 8.0 SAML 2.0 Use Case... 7 9.0 Conclusions... 9 10.0 Future Work... 10 11.0 References... 10 Page 1 of 10

1.0 Introduction I decided to do research on the SAML protocol and how it is related to securing web services. This paper is designed to describe SAML and how it is used to an audience who has had little to no exposure securing web services with security policies. A brief introduction describing the contents of this paper is below: Sections 2 4 of this paper first describe what SAML is and why it is important from a security standpoint. This is followed by a brief history of SAML and the anatomy of SAML 2.0. Sections 5 7 introduce the reader to how web services interact. Two main interaction types are described; Web Service Choreography and Web Service Orchestration. Section 8 Ties together sections 2 7. where interactions of a real world use case for SAML 2.0 are described. Lastly, sections 9 and 10 outline conclusions of the research and future work 2.0 What is SAML? SAML stands for Security Access Markup Language. It is an XML-based standard for exchanging authentication and authorization between security domains. In a larger sense security policies using SAML are attached to web services and in turn the web service abides by the rules and assertions that are specified by a particular policy. SAML abstracts the security away from platform architectures and vendor specific software implementations. In situations where you are concerned with securing web services, policies can be attached to the service endpoints without a need to change the underlying application. This makes attaching security policies very desirable in situations where the application developer is not involved in the implementation of system security. The diagram below shows a SAML 2.0 policy that is being selected and bound to a web service during application design time. This particular SAML policy also verifies that the transport protocol use Secure Socket Layer (SSL) be used for message protection. The policy can be applied to any SOAP-based endpoint. Figure 1.0 Example of SAML 2.0 Security Policy Page 2 of 10

3.0 History of SAML Three major versions of SAML have been released. SAML 1.0 in November of 2002, SAML 1.1 in September of 2003, and SAML 2.0 in March of 2005. This research discussed in this paper is primarily concerned with the 2.0 version of SAML. SAML was originally a product of Organization for the Advancement of Structured Information Standards (OASIS) Security Services Technical Committee. OASIS are a not for profit organization. The organization promotes standards for security, cloud computing, Service Oriented Architecture (SOA), web services, emergency management, and many other standards. SAML 2.0 improved the standard in many ways. First, the standard was stabilized. This means that moving forward from version 2.0 no significant changes to the standard will be made. When changes to the standard are made they will be done in a predictable fashion. The Liberty Alliance had been influential in the first part. Secondly, and perhaps most importantly, SAML 2.0 has been more tightly integrated with open source Single Sign On (SSO) and federation services. In particular the Shibboleth project. It is worth mentioning that participants in the Shibboleth project were also authors of the SAML 2.0 Standard. Shibboleth is a standards based open source software package for web single signon across or within organizational boundaries. It allows granular protection of resources across a federation. 4.0 The Anatomy of SAML 2.0 SAML 2.0 is comprised of many things. The Primary Protocols that make up SAML are the Assertion Query and Request Protocol, Authentication and Request Protocol, Artifact Resolution Protocol, Name Identifier Management Protocol, and the Single Logout Protocol. SAML Bindings are SAML SOAP Binding, Reverse SOAP Binding, HTTP Artifact Binding, and the SAML URL Binding. The primary profile that we are concerned with in this paper is the SSO Profile. The information in this section is primarily from the OASIS specification referenced at the end of this document. 4.0.1- Assertion Query and Request Protocol Defines the messaging and processing rules for requesting existing assertions by reference or querying the assertions by subject and statement type 4.0.2 - Authentication Request Protocol Use the authentication request protocol to send an <AuthnRequest> message element to a SAML authority and request that it return a <Response> message containing one or more such assertions. Page 3 of 10

4.0.3 - Artifact Resolution Protocol The artifact resolution protocol provides a mechanism by which SAML protocol messages can be transported in a SAML binding by reference instead of by value. Both requests and responses can be obtained by reference using this specialized protocol. A message sender, instead of binding a message to a transport protocol, sends a small piece of data called an artifact using the binding. An artifact can take a variety of forms, but must support a means by which the receiver can determine who sent it. If the receiver wishes, it can then use this protocol in conjunction with a different (generally synchronous) SAML binding protocol to resolve the artifact into the original protocol message. 4.0.4 - Name Identifier Management Protocol After establishing a name identifier for a principal, an identity provider wishing to change the value and/or format of the identifier that it will use when referring to the principal, or to indicate that a name identifier will no longer be used to refer to the principal, informs service providers of the change by sending them a <ManageNameIDRequest> message. 4.0.5 - Single Logout Protocol The single logout protocol provides a message exchange protocol by which all sessions provided by a particular session authority are near-simultaneously terminated. The single logout protocol is used either when a principal logs out at a session participant or when the principal logs out directly at the session authority. This protocol may also be used to log out a principal due to a timeout. The reason for the logout event can be indicated through the Reason attribute. 4.0.6 - SAML Binding SOAP Binding [SAMLBind] supports the use of SSL/TLS (see [RFC 2246]/[SSL3]) or SOAP Message Security mechanisms for confidentiality 4.0.7 SSO Profile The specification calls out a SAMLv2 lightweight Web Browser Single Sign-On Profile. This profile is modeled on the OASIS SAMLv2 Web Browser SSO profile, adding various constraints, and using a new lighter weight SAMLv2 HTTP POST binding offering an optional signature technique that is more simple-to-implement than the optional XML Digital Signature approach. XML digital signature (XMLdsig) [W3C.xmldsig core] is made optional because it is asserted by various implementers that implementation support for it is essentially non-existent in so-called "scripting" environments, e.g. PERL/PYTHON/PHP/Ruby, and/or different implementations of it are not very interoperable as yet, due to the inherent complexity of the specification and its required behaviors. Security Assertion Markup Language (SAML) v2.0, "SAMLv2", is an XML-based framework for creating and exchanging security information. [OASIS.sstc saml exec overview 2.0 cd 01] and OASIS.sstc saml tech overview 2.0 cd 01] provide non-normative overviews of SAMLv2. The SAMLv2 specification set is normatively defined by [OASIS.saml conformance 2.0 os]. Page 4 of 10

5.0 How Web Services Interact As described earlier, security policies are attached to a web service endpoint. In the case of this research the security policy being attached to the web service endpoint uses SAML 2.0 with message protection (SSL.) In order to better understand the use case for SAML 2.0 presented in section 8.0 of this paper, it is important to understand the two major types of web service interaction at a high level. Web Service Choreography is described in section 6.0 and Web Service Orchestration is described in section 7.0. In both examples are primary concern is attaching the SAML 2.0 Policy to each service end point for requests and responses. 6.0 Web Service Choreography In web service choreography the relationships between web services are dynamic. Decisions are typically made between individual web services. This means that no single web service is in control of the actions of all of the other web services. This is a common implementation in cloud computing environments where information is shared between domains. In a web service choreography scenario, the SAML 2.0 Security Policy would be attached to each of the web services in the figure below. This means the exact same policy would be attached to Bank Service, External Bank Service A, External Bank service C, and External Bank Service D. The challenge in this scenario is in getting all parties, both internal and external businesses, to agree upon the type of security policy to apply, and how to regulate change to the system. Page 5 of 10

Figure 2.0 High Level Example Web Service Choreography 7.0 Web Service Orchestration In web service orchestration the relationships between web services are relatively static. Decisions are typically controlled by a single service. This means that other web services in the orchestration could be dependent on the web service that is responsible for the orchestration. This is a common design when web services are within the same domain. In a web service orchestration scenario, the SAML 2.0 Security Policy would be attached to each of the web services in the figure below much the same as in the choreography scenario. This means the exact same policy would be attached to Internal Bank Service, Internal Bank Service A, Internal Bank service B, Internal Bank Service C, and Internal Bank Service D. The challenges in setting up this scenario are not as great as those of choreography. This is because all agreements are internal to the business that is implementing the web services. However, If service Bank Service has to rely on any external information provided by an outside web service the challenges of setting up a choreography would than apply. Page 6 of 10

Figure 3.0 High Level Example Web Service Orchestration 8.0 SAML 2.0 Use Case The steps below walk through a use case of SAML 2.0. This use case can apply regardless of web service interaction type. It will work in a choreography or orchestration scenario if policy agreements allow. Figure 4.0 shows the flow of events. This use case is nearly identical to one that is provided on Wikipedia. The diagram is from that use case and the steps needed very little tweaking. The SSO provider could be any SSO provider. In this case when we mean SSO provider we are referring to Shibboleth. 1. Request a Resource A resource can be any URI (Uniform Resource Identifier). In this example we are using a URL. We are requesting something from a bank. In the example we use the principal is an HTTP user agent. https://my.bank.com/myaccount 2. Respond with a form In the case of SAML 2.0 the service provider will respond with an XHTML (extensible HyperText Markup Language) form. <form method="post" action="https://idp.some.org/saml2/sso/post"...> <input type="hidden" name="samlrequest" value="request" /> Page 7 of 10

..... <input type="submit" value="submit" /> </form> 3. The Single Sign on Service is requested at the Identity Provider. The user agent issues a POST request at the SSO identity provider. The SAMLRequest is taken from the form in the previous step. If the user does not have a valid security context they are issued one, or, if the security request does not meet the requirements of the provider access is denied. 4. An XHTML form is given in response. If the request is valid the SSO responds with a document containing an XHTML Form. <form method="post" action="https://sp.some.com/saml2/sso/post"...> <input type="hidden" name="samlresponse" value="response" />... <input type="submit" value="submit" /> </form> 5. Request the assertion provider at the Service Provider. The user agent issues a POST request to the assertion provider, the value of SAMLResponse is taken from the XHTML form. 6. User Agent is re-directed to the target resource. In our case the user agent is asking for whatever resource myaccount in step #1 actually is. 7. The resource is requested at the Service Provider again. This request is for the original request in step #1 https://my.bank.com/myaccount 8. Requested Resource is returned. In our case we know the security context already exists. The service provider returns the requested resource back to the user agent. Page 8 of 10

Figure 4.0 Flow of Events SSO SAML 2.0 Use Case 9.0 Conclusions Nothing is truly mandated. Even if all parties agree upon the type of security policy that will be used between services from different business partners nothing can remove the human element. For example, a SAML security policy can be attached to a web service endpoint but the web service policy can be disabled. Disabling a policy has the same impact as it not being bound to the service at all, the policy is completely ignored. Securing web services with SAML on the surface seems fairly straight forward. You attach (bind) a SAML security policy to a web service that has already been deployed, or you can attach it via a development environment during design time. However, if you take a look at the use case in Section 8.0 you begin to appreciate the amount of configuration involved. For the use case to work you need to install and configure an Identity provider such as Microsoft Active Directory, an SSO solution, a KeyStore, and possibly a ticket management system. This is not to mention device security for network devices such as routers. Although the configuration aspects are quite a challenge, SAML itself provides a good solution for assuring identity and proper authorization across federations. When used in conjunction with Page 9 of 10

SSO it can provide fine-grade access to resources while allowing the consumer of the resource to remain virtually anonymous. 10.0 Future Work Develop large scale generic deployment solutions. I think this would be particularly useful in cloud computing environments. Such environments are dynamic in nature and I think the real issue comes into play when resources have to be dynamically scaled. For example, you may access a web service that is available within a virtual machine created at a particular point in time based on the amount of requests coming into the system. How do we know the services on the machine are the most current in an automatic fashion? How can the resource be dynamically identified so that the SSO service does not reject the request even when the remainder of the service has been configured correctly? 11.0 References NIST: Guide to Secure Web Services http://csrc.nist.gov/publications/nistpubs/800-95/sp800-95.pdf OASIS: Authorization Context for the OASIS Security Service Markup Language (SAML) V2.0 http://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf PAPERS: Information Assurance Challenges and Strategies for Securing SOA Environments and Web Services IEEE SysCon 2009 3rd Annual IEEE International Systems Conference, 2009 Vancouver, Canada, March 23 26, 2009 Combining Identity Federation With Payment: The SAML Based Payment Protocol 2010 IEEE/IFIP Network Operations and Management Symposium - NOMS 2010 Wikipedia: http://en.wikipedia.org/wiki/security_assertion_markup_language Page 10 of 10