Security Assertion Markup Language (SAML) 2.0 Technical .

Transcription

3Security Assertion Markup Language(SAML) 2.0 Technical Overview4Working Draft 01, 22 July 200456Document ents.php?wg abbrev security291011Editors:John Hughes, Entegrity SolutionsEve Maler, Sun ct:The Security Assertion Markup Language (SAML) standard defines a framework for exchangingsecurity information between online business partners. It was developed by the Security ServicesTechnical Committee (SSTC) of the standards organization OASIS (the Organization for theAdvancement of Structured Information Standards). This document provides a technicaldescription of SAML V2.0.20212223Status:242526This draft is a non-normative document that is intended to be approved as a Committee Draft bythe SSTC. This document is not currently on an OASIS Standard track. Readers should refer tothe normative specification suite for precise information concerning SAML V2.0.Committee members should send comments on this specification to the securityservices@lists.oasis-open.org list. Others should Others should submit them by filling in the format .php?wg abbrev security.27282930For information on whether any patents have been disclosed that may be essential toimplementing this specification, and any offers of patent licensing terms, please refer to theIntellectual Property Rights section of the Security Services TC web page sstc-saml-tech-overview-2.0-draft-01Copyright OASIS Open 2004. All Rights Reserved.22 July 2004Page 1 of 36

5758596061626364656667686970717273747576Table of Contents1 Introduction.42 SAML Use Cases.52.1 Single Sign-On Use Case.52.2 Federation Use Case.63 SAML Architecture.73.1 Basic Concepts.73.2 Summary of SAML Components.73.3 SAML Structure and Examples.93.3.1 Assertions.93.3.2 SOAP over HTTP Binding.113.4 Single Sign-On and Federation Principals.123.5 Use of SAML in other Frameworks.133.6 Security in SAML.134 Profiles.144.1 Web Browser SSO Profile.144.1.1 Concept.144.1.2 SP initiated: POST- POST binding.164.1.3 SP initiated: Redirect- POST binding.184.1.4 SP initiated: Artifact- POST binding.194.1.5 SP initiated: POST- Artifact binding.204.1.6 SP initiated: Redirect- Artifact binding.224.1.7 SP initiated: Artifact- Artifact binding.234.1.8 IdP initiated: POST binding.254.1.9 IdP initiated: Artifact binding.264.2 ECP Profile.274.2.1 Introduction.274.2.2 ECP Profile using PAOS binding.274.3 Kerberos.284.4 Federation.284.4.1 Introduction.284.4.2 Federation during AuthnRequest .294.4.3 Federation Termination.294.4.4 Accounting Linking.295 Documentation roadmap .306 Comparison Between SAML 2.0 and SAML 1.1.316.1 Differences in the Organization of the Specifications.316.2 Versioning Differences.316.3 Subject and Subject Confirmation Differences.316.4 Encryption-Related Differences.326.5 Attribute-Related Differences.326.6 Differences in the Request-Response Mechanism. 326.7 Differences in the Protocols for Retrieving Assertions. 326.8 Session-Related Differences.326.9 Federation-Related Copyright OASIS Open 2004. All Rights Reserved.22 July 2004Page 2 of 36

7778796.10 Differences in Bindings and Profiles.336.11 Other Differences.337 1Copyright OASIS Open 2004. All Rights Reserved.22 July 2004Page 3 of 36

81828384851IntroductionThe Security Assertion Markup Language (SAML) standard defines a framework for exchanging securityinformation between online business partners.More precisely, SAML defines a common XML framework for exchanging security assertions betweenentities. As stated in the SSTC charter, the purpose of the Technical Committee is:8687 to define, enhance, and maintain a standard XML-based framework for creating andexchanging authentication and authorization information.888990SAML is different from other security systems due to its approach of expressing assertions about asubject that other applications within a network can trust. What does this mean? To understand theanswer, you need to know the following two concepts used within SAML:919293949596979899100101102103104105Identity Provider (IdP)The system, or administrative domain, that asserts information about a subject. For instance, theIdentity Provider asserts that this user has been authenticated and has given associated attributes.For example: This user is John Doe, he has an email address of john.doe@acompany.com, and hewas authenticated into this system using a password mechanism. In SAML, Identity Providers are alsoknown as SAML authorities and Asserting Parties.Service Provider (SP)The system, or administrative domain, that relies on information supplied to it by the Identity Provider.It is up to the Service Provider as to whether it trusts the assertions provided to it. SAML defines anumber of mechanisms that enable the Service Provider to trust the assertions provided to it. Itshould be noted that although a Service Provider can trust the provided assertions provided, localaccess policy defines whether the subject may access local resources. Therefore, although theService Provider trusts that I'm John Doe – it doesn't mean I'm given carte blanche access to allresources. Service Providers are also known as Relying Parties – due to the fact that they “rely” oninformation provided by an Identity Provider (Asserting ht OASIS Open 2004. All Rights Reserved.22 July 2004Page 4 of 36

1061071081091101111121132SAML Use CasesThe Security Assertion Markup Language (SAML) standard defines a framework for exchanging securityinformation between online business partners. It was developed by the Security Services TechnicalCommittee (SSTC) of the standards organization OASIS (the Organization for the Advancement ofStructured Information Standards).More precisely, SAML defines a common XML framework for creating, requesting, and exchangingsecurity assertions between entities. As stated on the SSTC website, the purpose of the TechnicalCommittee is:114 to define, enhance, and maintain a standard XML-based framework for creating andexchanging authentication and authorization information.115116117118But why is it required? There are four “drivers” behind the creation of the SAML standard:119120121122123124 Limitations of Browser cookies: Most existing Single-Sign On products use browser cookies tomaintain state so that re-authentication is not required. Browser cookies are not transferred betweenDNS domains. So, if you obtain a cookie from www.abc.com, then that cookie will not be sent in anyHTTP messages to www.xyz.com. This could even apply within an organization that has separate DNSdomains. Therefore, to solve the Cross-Domain SSO (CDSSO) problem requires the application ofdifferent technology. All SSO products solve the CDSSO problem by different techniques.125126127128 SSO Interoperability: How products implement SSO and CDSSO are completely proprietary. If youare an organization and you want to perform SSO across different DNS domains within the sameorganization or you want to perform CDSSO to trading partners, then you will have to use the sameSSO product in all the domains.129130131132 Web Services: Security within Web Services is still being defined. Most of the focus has been on howto provide confidentiality and authentication/integrity services on an end-to-end basis. The SAMLstandard provides the means by which authentication and authorization assertions can exchangedbetween communicating parties.133134135136 Federation: The need to simplify identity management across organizational boundaries, allowingusers to consolidate many local identities into a single (or at least a reduced set) Federated Identity.Prior to examining the details of the SAML standard, its useful to describe two high level use cases. (Lateron, more detailed use cases are described based on specific SAML profiles.)1372.1138139140141142143144145146This is the original use case as supported in SAML 1.0 and 1.1. It illustrates the support for Cross DomainSingle Sign-On. A user has a logon session (that is a security context) on a website (AirlineInc.com) andis accessing resources on that site. At some either explicitly or transparently he is directed over to anotherweb site (in a different DNS domain). The Identity Provider site (AirlineInc.com) asserts to the ServiceProvider site (CarRentalInc.com) that the user is known to it and provides the user's name and sessionattributes (e.g. “Gold member”). As CarRentalInc.com trusts AirlineInc.com it knows that the user is validand crea

Web Services: Security within Web Services is still being defined. Most of the focus has been on how to provide confidentiality and authentication/integrity services on an end-to-end basis. The SAML standard provides the means by which authentication and authorization assertions can exchanged between communicating parties. Federation: The need to simplify identity management across .