SAML TechOverviewV20 Draft7874

2 Security Assertion Markup Language
3 (SAML) 2.0 Technical Overview

4 Working Draft 01, 22 July 2004
5 Document identifier:
6 sstc-saml-tech-overview-2.0-draft-01
7 Location:
8 http://www.oasis-open.org/committees/documents.php?wg_abbrev=security
9 Editors:
10 John Hughes, Entegrity Solutions
11 Eve Maler, Sun Microsystems
12 Contributors:
13 TBD
14 Abstract:
15 The Security Assertion Markup Language (SAML) standard defines a framework for exchanging
16 security information between online business partners. It was developed by the Security Services
17 Technical Committee (SSTC) of the standards organization OASIS (the Organization for the
18 Advancement of Structured Information Standards). This document provides a technical
19 description of SAML V2.0.
20 Status:
21 This draft is a non-normative document that is intended to be approved as a Committee Draft by
22 the SSTC. This document is not currently on an OASIS Standard track. Readers should refer to
23 the normative specification suite for precise information concerning SAML V2.0.
24 Committee members should send comments on this specification to the security-
25 services@lists.oasis-open.org list. Others should Others should submit them by filling in the form
26 at http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=security.
27 For information on whether any patents have been disclosed that may be essential to
28 implementing this specification, and any offers of patent licensing terms, please refer to the
29 Intellectual Property Rights section of the Security Services TC web page (http://www.oasis-
30 open.org/committees/security/).
31
sstc-saml-tech-overview-2.0-draft-01 22 July 2004

Copyright © OASIS Open 2004. All Rights Reserved. Page 1 of 36
32 Table of Contents
33 1 Introduction..................................................................................................................................................4
34 2 SAML Use Cases........................................................................................................................................5
35 2.1 Single Sign-On Use Case....................................................................................................................5
36 2.2 Federation Use Case...........................................................................................................................6
37 3 SAML Architecture.......................................................................................................................................7
38 3.1 Basic Concepts....................................................................................................................................7
39 3.2 Summary of SAML Components.........................................................................................................7
40 3.3 SAML Structure and Examples............................................................................................................9
41 3.3.1 Assertions.....................................................................................................................................9
42 3.3.2 SOAP over HTTP Binding..........................................................................................................11
43 3.4 Single Sign-On and Federation Principals.........................................................................................12
44 3.5 Use of SAML in other Frameworks....................................................................................................13
45 3.6 Security in SAML................................................................................................................................13
46 4 Profiles.......................................................................................................................................................14
47 4.1 Web Browser SSO Profile.................................................................................................................14
48 4.1.1 Concept......................................................................................................................................14
49 4.1.2 SP initiated: POST->POST binding...........................................................................................16
50 4.1.3 SP initiated: Redirect->POST binding.......................................................................................18
51 4.1.4 SP initiated: Artifact->POST binding..........................................................................................19
52 4.1.5 SP initiated: POST->Artifact binding..........................................................................................20
53 4.1.6 SP initiated: Redirect->Artifact binding......................................................................................22
54 4.1.7 SP initiated: Artifact->Artifact binding........................................................................................23
55 4.1.8 IdP initiated: POST binding........................................................................................................25
56 4.1.9 IdP initiated: Artifact binding......................................................................................................26
57 4.2 ECP Profile.........................................................................................................................................27
58 4.2.1 Introduction.................................................................................................................................27
59 4.2.2 ECP Profile using PAOS binding................................................................................................27
60 4.3 Kerberos.............................................................................................................................................28
61 4.4 Federation..........................................................................................................................................28
62 4.4.1 Introduction.................................................................................................................................28
63 4.4.2 Federation during <AuthnRequest>...........................................................................................29
64 4.4.3 Federation Termination..............................................................................................................29
65 4.4.4 Accounting Linking......................................................................................................................29
66 5 Documentation roadmap ..........................................................................................................................30
67 6 Comparison Between SAML 2.0 and SAML 1.1.......................................................................................31
68 6.1 Differences in the Organization of the Specifications........................................................................31
69 6.2 Versioning Differences.......................................................................................................................31
70 6.3 Subject and Subject Confirmation Differences..................................................................................31
71 6.4 Encryption-Related Differences.........................................................................................................32
72 6.5 Attribute-Related Differences.............................................................................................................32
73 6.6 Differences in the Request-Response Mechanism........................................................................... 32
74 6.7 Differences in the Protocols for Retrieving Assertions...................................................................... 32
75 6.8 Session-Related Differences.............................................................................................................32
76 6.9 Federation-Related Differences.........................................................................................................33

77 6.10 Differences in Bindings and Profiles................................................................................................33
78 6.11 Other Differences.............................................................................................................................33
79 7 References................................................................................................................................................34
80

81 1 Introduction
82 The Security Assertion Markup Language (SAML) standard defines a framework for exchanging security
83 information between online business partners.
84 More precisely, SAML defines a common XML framework for exchanging security assertions between
85 entities. As stated in the SSTC charter, the purpose of the Technical Committee is:
86 …to define, enhance, and maintain a standard XML-based framework for creating and
87 exchanging authentication and authorization information.
88 SAML is different from other security systems due to its approach of expressing assertions about a
89 subject that other applications within a network can trust. What does this mean? To understand the
90 answer, you need to know the following two concepts used within SAML:
91 Identity Provider (IdP)
92 The system, or administrative domain, that asserts information about a subject. For instance, the
93 Identity Provider asserts that this user has been authenticated and has given associated attributes.
94 For example: This user is John Doe, he has an email address of john.doe@acompany.com, and he
95 was authenticated into this system using a password mechanism. In SAML, Identity Providers are also
96 known as SAML authorities and Asserting Parties.
97 Service Provider (SP)
98 The system, or administrative domain, that relies on information supplied to it by the Identity Provider.
99 It is up to the Service Provider as to whether it trusts the assertions provided to it. SAML defines a
100 number of mechanisms that enable the Service Provider to trust the assertions provided to it. It
101 should be noted that although a Service Provider can trust the provided assertions provided, local
102 access policy defines whether the subject may access local resources. Therefore, although the
103 Service Provider trusts that I'm John Doe – it doesn't mean I'm given carte blanche access to all
104 resources. Service Providers are also known as Relying Parties – due to the fact that they “rely” on
105 information provided by an Identity Provider (Asserting Party).

106 2 SAML Use Cases
107 The Security Assertion Markup Language (SAML) standard defines a framework for exchanging security
108 information between online business partners. It was developed by the Security Services Technical
109 Committee (SSTC) of the standards organization OASIS (the Organization for the Advancement of
110 Structured Information Standards).
111 More precisely, SAML defines a common XML framework for creating, requesting, and exchanging
112 security assertions between entities. As stated on the SSTC website, the purpose of the Technical
113 Committee is:
114
115 …to define, enhance, and maintain a standard XML-based framework for creating and
116 exchanging authentication and authorization information.
117
118 But why is it required? There are four “drivers” behind the creation of the SAML standard:
119 • Limitations of Browser cookies: Most existing Single-Sign On products use browser cookies to
120 maintain state so that re-authentication is not required. Browser cookies are not transferred between
121 DNS domains. So, if you obtain a cookie from www.abc.com, then that cookie will not be sent in any
122 HTTP messages to www.xyz.com. This could even apply within an organization that has separate DNS
123 domains. Therefore, to solve the Cross-Domain SSO (CDSSO) problem requires the application of
124 different technology. All SSO products solve the CDSSO problem by different techniques.
125 • SSO Interoperability: How products implement SSO and CDSSO are completely proprietary. If you
126 are an organization and you want to perform SSO across different DNS domains within the same
127 organization or you want to perform CDSSO to trading partners, then you will have to use the same
128 SSO product in all the domains.
129 • Web Services: Security within Web Services is still being defined. Most of the focus has been on how
130 to provide confidentiality and authentication/integrity services on an end-to-end basis. The SAML
131 standard provides the means by which authentication and authorization assertions can exchanged
132 between communicating parties.
133 • Federation: The need to simplify identity management across organizational boundaries, allowing
134 users to consolidate many local identities into a single (or at least a reduced set) Federated Identity.
135 Prior to examining the details of the SAML standard, its useful to describe two high level use cases. (Later
136 on, more detailed use cases are described based on specific SAML profiles.)
137 2.1 Single Sign-On Use Case

138 This is the original use case as supported in SAML 1.0 and 1.1. It illustrates the support for Cross Domain
139 Single Sign-On. A user has a logon session (that is a security context) on a website (AirlineInc.com) and
140 is accessing resources on that site. At some either explicitly or transparently he is directed over to another
141 web site (in a different DNS domain). The Identity Provider site (AirlineInc.com) asserts to the Service
142 Provider site (CarRentalInc.com) that the user is known to it and provides the user's name and session
143 attributes (e.g. “Gold member”). As CarRentalInc.com trusts AirlineInc.com it knows that the user is valid
144 and creates a session for the user based on the user's name and/or the user attributes. This use case
145 illustrates the fact that the user is not required to re-authenticate when directed over to the
146 CarRentalInc.com site
147 Figure 1 illustrates the SSO high-level use case.
Figure 1: SSO Use Case
148
149 2.2 Federation Use Case

150 There are a number Federation use cases, details of which are explained later. This use case illustrates
151 the “account linking” facet of federation. Figure 2 illustrates one scenario. Two Service Providers exist,

Source Web Site
(AirlineInc.com)
Identity Provider
ticate
en
Auth
1.
Destination Web Site
(CarRentalInc.com)
2.
Web User Ac
ce
ss
Re
so
urce
Service Provider
152 one for car rentals the other for hotel bookings. The same user is registered on both sites, however using
153 different names. On CarRentalInc.com he is registered as jdoe and on HotelBookings.com as johnd.
154 Account Linking enables a pseudonym to be established that links the two accounts.
155 MORE DETAILS TO ADD – JohnH.
AirlineInc.com
Identity Provider
CarRentalInc.com
Service Provider
jdoes
Web User
HotelBooking.com
Service Provider
johnd
Figure 2: Federation Use Case

156

157 3 SAML Architecture
158 This section provides a brief description of the concepts that underlie SAML and the component pieces
159 defined in the standard.
160 3.1 Basic Concepts

161 SAML consists of a number of building-block components that, when put together, allow a number of use
162 cases to be supported. Primarily the components permit transfer of identity, authentication, and
163 authorization information to be exchanged between autonomous organizations. The “core” SAML
164 specification defines the structure and content of Assertions – which carry statements about a Principal
165 as asserted by an Asserting Party. These are defined by an XML Schema. Assertions are either requested
166 or just “pushed” out to the Service Provider. How and which assertions are requested is defined by the
167 SAML Protocols, which have their own XML Schema. The lower-level communication or messaging
168 protocols (such as HTTP or SOAP) that the SAML protocols can be transported over are defined by
169 Bindings. SAML Protocols and Bindings, together with the structure of Assertions, can be combined
170 together to create a Profile. In general Profiles can be thought of a satisfying a particular use case, for
171 example the Web Browser SSO profile. There are also Attribute Profiles (for example, LDAP and DCE
172 profiles), which define how identity and attribute information is carried within an Assertion.
173 Two other SAML components can be used in building a system:
174 • Metadata: Metadata defines how configuration information shared between two communicating
175 entities is defined and shared. For instance, an entity's support for given SAML bindings, identifier
176 information, and PKI information can be defined. Metadata is defined by an XML Schema. The
177 location of Metadata is defined using DNS records
178 • Authentication Context: In a number of situations the Service Provider may wish to have to have
179 additional information in determining the authenticity and confidence they have in the information
180 within an assertion. Authentication Context permits the augmentation of Assertions with additional
181 information pertaining to the authentication of the Principal at the Identity Provider. For instance,
182 details of multi-factor authentication can be included.
183 This document does not go into further detail about Metadata and Authentication Context; for more
184 information, see the specifications that focus on them ([SAML-Meta] [SAML-AuthnCxt] respectively).
185 3.2 Summary of SAML Components

186 The SAML components and their individual parts are as follows:
187 • Assertions: SAML allows for one party to assert characteristics and attributes of an entity. For
188 instance, a SAML assertion could state that the user is “John Doe”, the user has “Gold” status, the
189 user’s email address is john.doe@example.com, and the user is a member of the “engineering”
190 group. SAML assertions are encoded in a XML schema. SAML defines three kinds of statements
191 that can be carried within an assertion:
192 • Authentication statements: are issued by the party that successfully authenticated the user.
193 They define who issued the assertion, the authenticated subject, validity period, plus other
194 authentication related information.
195 • Attribute statements: contain specific details about the user (for example, that they have
196 “Gold” status).
197 • Authorization decision statements: identifies what the user is entitled to do (for example,
198 whether he is permitted to buy a specified item).
199 • Protocols: SAML defines a number of request/response protocols. The protocol is encoded in an
200 XML schema as a set of request-response pairs. The protocols defined are.

201 • Assertion Query and Request Protocol: Defines a set of queries by which existing SAML
202 assertions may be obtained. The query can be on the basis of a reference, subject or the
203 statement type.
204 • Authentication Request Protocol: Defines a <AuthnRequest> message that causes a
205 <Response> to be returned containing one of more assertions pertaining to a Principal.
206 Typically the <AuthnRequest> is issued by a Service Provider with the Identity Provider
207 returning the <Response> message. Used to support the Web Browser SSO Profile.
208 • Artifact Protocol: Provides a mechanism to obtain a previously created assertion by providing
209 a reference. In SAML terms the reference is called an “artifact”. Thus a SAML protocol can
210 refer to an assertion by an artifact, and then when a Service Provider obtains the artifact it can
211 use the artifact Protocol to obtain the actual assertion using this protocol.
212 • Name Identifier Management Protocol: Provides mechanisms to change the value or format
213 of the name of a Principal. The issuer of the request can be either the Service Provider or the
214 Identity Provider. The protocol also provides a mechanism to terminate an association of a
215 name between an Identity Provider and Service Provider.
216 • Single Logout Protocol: Defines a request that allows near-simultaneous logout of all
217 sessions associated by a Principal. The logout can be directly initiated by the Principal or due
218 to a session timeout.
219 • Name Identifier Mapping Protocol: Provides a mechanism to enable “account linking”.
220 Refer to the subsequent sections on Federation.
221 • Bindings: This details exactly how the SAML protocol maps onto the transport protocols. For
222 instance, the SAML specification provides a binding of how SAML request/responses are carried
223 with SOAP exchange messages. The bindings defined are:
224 • SAML SOAP Binding: Defines how SAML protocol messages are transported within SOAP
225 1.1 messages. In addition it also defines how the SOAP messages are transported over HTTP.
226 • Reverse SOAP (PAOS) Binding: Defines a multi-stage SOAP/HTTP message exchange that
227 permits a HTTP client to be a SOAP responder. Used in the Enhanced Client and Proxy Profile
228 and particularly designed to support WAP gateways.
229 • HTTP Redirect Binding: Defines how SAML protocol messages can be transported using
230 HTTP redirect messages (i.e. 302 status code responses)
231 • HTTP POST Binding: Defines how SAML protocol messages can be transported within the
232 base64-encoded content of an HTML form control
233 • HTTP Artifact Binding: Defines how a reference to a SAML request or response (i.e. an
234 artifact) is transported by HTTP. Defines two mechanisms, either an HTML form control, or a
235 query string in the URL.
236 • SAML URI Binding: ?? NOT SURE HOW TO EASILY DEFINE THIS
237 • Profiles: The core of the SAML specification defines how the SAML requests and responses are
238 transported, however, a number of use cases have been developed that require the formulation of
239 Profiles that define how the SAML assertions, protocols and bindings are combined. Some of these
240 described in detail later on in the document, in summary they are:
241 • Web Browser SSO Profile: Defines how a Web Browser supports SSO, when using
242 <AuthnRequest> protocol messages in combination with HTTP Redirect, HTTP POST and
243 HTTP Artifact bindings
244 • Enhanced Client and Proxy (ECP) Profile: Defines how <AuthnRequest> protocol
245 messages are used when combined with the Reverse-SOAP binding (PAOS). Designed to
246 support mobile devices front-ended by a WAP gateway
247 • Identity Provider Discovery Profile: Defines how a service provider can discover which
248 identity providers a principal is using with the Web Server

249 • Single Logout Profile: A profile of the SAML Single Logout protocol is defined. Defines how
250 SOAP, HTTP Redirect, HTTP POST and HTTP Artifact bindings may be used.
251 • Name Identifier Management Profile: Defines how the Name Identifier Management protocol
252 may be used with SOAP, HTTP Redirect, HTTP POST and HTTP Artifact bindings.
253 • Artifact Resolution Profile: Defines how the Artifact Resolution protocol uses a synchronous
254 binding, for example the SOAP binding.
255 • Assertion Query/Request Profile: Defines how the SAML query protocols (used for obtaining
256 SAML assertions) use a synchronous binding such as the SOAP binding.
257 • Name Identifier Mapping Profile: Defines how the Name Identifier Mapping protocol uses a
258 synchronous binding such as the SOAP binding.
259 Figure 3 illustrates the relationship between the components:
PROFILES
(How SAML protocols, bindings and/or assertions combine to support a defined use case)
BINDINGS
(how SAML Protocols map onto standard messaging or communication protocols)
PROTOCOL
(Request/Response pairs for obtaining Assertions and Federation Management)
ASSERTIONS
(Authentication, Attribute and Authorization Information)
Figure 3: SAML Components
260 3.3 SAML Structure and Examples

261 In this section we provide descriptions of some of the SAML structures, bindings and profiles.
262 3.3.1 Assertions

263 An assertion consists of one or more statements. For Single Sign-On, typically a SAML assertion will
264 contain a single authentication statement and possibly a single attribute statement. Figure 4 shows a
265 SAML Assertion being carried within a SAML response, which itself is withing a SOAP Body. Note that a
266 SAML Response could contain multiple assertions, although its more typical to have a single assertion
267 within a response.

SOAP Body
SAML Response
Response Header
SAML Assertion
Authentication
Statement
Other
Statements
Figure 4: SAML Assertion Structure

268 Figure 5 shows an example assertion with a single authentication statement. The authentication statement
269 has been highlighted. Note the following:
270 • The subject (e.g. user) that the authentication pertains to is “joe”. The format of the subject has been
271 defined. In this case its a custom format; however, a number of predefined formats have been
272 provided in the SAML specification, including email addresses and X.509 subject names.
273 • Joe was originally authenticated using a password mechanism at “2002-06-19T17:05:17.706Z".
274 • TO DO – SAML 2.0 VERSION
275 <saml:Assertion
276 xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
277 MajorVersion="1"
278 MinorVersion="1"
279 AssertionID="buGxcG4gILg5NlocyLccDz6iXrUa"
280 Issuer="www.acompany.com"
281 IssueInstant="2002-06-19T17:05:37.795Z">
282 <saml:Conditions NotBefore="2002-06-19T17:00:37.795Z"
283 NotOnOrAfter="2002-06-19T17:10:37.795Z"/>
284 <saml:AuthenticationStatement
285 AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password"
286 AuthenticationInstant="2002-06-19T17:05:17.706Z">
287 <saml:Subject>
288 <saml:NameIdentifier
289 NameQualifier=http://www.acompany.com
290 Format="http://www.customformat.com/">
291 uid=joe
292 </saml:NameIdentifier>
293 <saml:SubjectConfirmation>
294 <saml:ConfirmationMethod>
295 urn:oasis:names:tc:SAML:1.0:cm:artifact-01
296 </saml:ConfirmationMethod>
297 </saml:SubjectConfirmation>
298 </saml:Subject>
299 </saml:AuthenticationStatement>
300 </saml:Assertion>
Figure 5: SAML Assertion

301 3.3.2 SOAP over HTTP Binding
302 In environments where the two communicating end points are SOAP enabled, then the SOAP over HTTP
303 binding can be used to exchange SAML request/query and response protocol messages. Figure 6
304 provides an overview of the structure. The request or response being carried within the SOAP body.
HTTP
SOAP Message
SOAP Header
SOAP Body
SAML
Request or Response
Figure 6: SOAP over HTTP binding

305 Figure 7 shows an example of a SAML request being transported within a SOAP message. In this
306 example, a SAML assertion is being requested pertaining to a supplied artifact. The use of the artifact is
307 explained later in the Use Case and Profiles section. The SAML request has been highlighted. (TO DO:
308 PROVIDE SAML 2.0 EXAMPLE)
309
310 <env:Envelope
311 xmlns:env=”http://www.w3.org/2003/05/soap/envelope/”>
312 <env:Body>
313 <samlp:Request
314 xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol“
315 xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion“
318 RequestID="192.168.16.51.1024506224022"
319 IssueInstant="2002-06-19T17:03:44.022Z">
320 <samlp:AssertionArtifact>
321 AAGZE1RNQJEFzYNCGAGPjWvtDIRSZ4
322 lWDqBphqAEYkgG/RBdHoeMsu1f
323 </samlp:AssertionArtifact>
324 </samlp:Request>
325 </env:Body>
326 </env:Envelope>
Figure 7: SAML Artifact Request

327

328 Figure 8 shows how a SAML response is embedded within a SOAP message. The SAML response
329 provides details as to the version of SAML being used and what request it is responding to. The
330 ResponseID, InResponseTo, version numbers, IssueInstant and the status code represent the SAML
331 response header. Within the response is the SAML assertion and typically one or more statements. The
332 SAML response has been highlighted. NEED SAML 2.0 VERSION
333
334 <env:Envelope
335 xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
336 <env:Body>
337 <samlp:Response
338 xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol“
339 ResponseID="P1YaA+Q/wSM/t/8E3R8rNhcpPTM=”
340 InResponseTo="192.168.16.51.1024506224022"
343 IssueInstant="2002-06-19T17:05:37.795Z">
344 <samlp:Status>
345 <samlp:StatusCode Value="samlp:Success" />
346 </samlp:Status>
347
348 …… SAML ASSERTION AND STATEMENTS
349
350 </samlp:Response>
351 </env:Body>
352 </env:Envelope>
Figure 8: SAML Response with SOAP message
353 3.4 Single Sign-On and Federation Principals

354 Whilst SAML permits transfer of identity and attribute information from an Identity Provider to a Service
355 Provider, one has to consider what the Service Provider does with that information and how user
356 information relates between organizations. SAML enables Single Sign-On between autonomous
357 organizations, however it also enables different facets of Identity Management to be accomplished.
358 SAML 2.0 enables the following to be provided. Where appropriate the relevant SAML mechanisms or
359 schema element(s) are highlighted.
360 • Identity Single Sign-On: In this environment only the Single Sign-On functionality of SAML is being
361 utilized. For those users that can have authenticated sessions across the organizations they will be
362 required to be registered in both organizations. Therefore if jdoe is registered at the Identity provider
363 and wishes to access a resource on a Service Provider in another organization then that same identity
364 will be registered at the Service Provider. The access rights of jdoe to resources on the Service
365 Provider will be based on the jdoe identity. The identity of the Principal is carried in the <NameID>
366 element which is in the <Subject> element of the <Assertion> header.
367 • Attribute Single Sign-On: Similar to Pure Single Sign-On, but the type of session and the access
368 right the user has on the Service Provider is based on attribute information transported in the SAML
369 assertion. Whilst the user name can be used for auditing purposes it is not used for access
370 management purposes. An example of this is using a Role attribute, for example “Gold Member”.
371 Attributes are carried in the <AttributeStatement> of a SAML assertion.
372 • Anonymous Single Sign-On: It is also possible to provide Anonymity. To support this only attribute
373 statements are provided to the Service Provider, the Principal <NameID> element not being sent.
374 • Opt-in account linking: Allows a user with multiple accounts at different autonomous Service
375 Providers to link the accounts for future authentication and sign-on. As in the Federation high-level use
376 case the accounts jdoe and johnd where linked.
377 • Affiliation: Permits grouping of Service Providers to form a set. Allows organizations to form
378 alliances. Affiliations are indicated by the SPNameQualifier attribute in the <NameID> and
379 <NameIDPolicy> elements.
380 • Pseudonyms: When accounts are linking a persistent pseudonym can be used to identity the account
381 linkage.
382 In section 4 a number of Federation use cases are described.

383 3.5 Use of SAML in other Frameworks
384 DESCRIBE REALTIONSHIP WITH SHIBBOLETH, LIBERTY AND WSS and XACML
385 3.6 Security in SAML

386 Just providing assertions from an asserting party to a relying party may not be adequate for a secure
387 system. How does the relying party trust what is being asserted to it? In addition, what prevents a “man-
388 in-the-middle” attack that grabs assertions to be illicitly “replayed” at a later date? SAML defines a number
389 of security mechanisms that prevent or detect such attacks. The primary mechanism is for the relying
390 party and asserting party to have a pre-existing trust relationship, typically involving a Public Key
391 Infrastructure (PKI). Whilst use of a PKI is not mandated, it is recommended. Use of particular
392 mechanisms is described for each profile; however, an overview of what is recommended is provided
393 below:
394 • Where message integrity and message confidentiality are required, then HTTP over SSL 3.0 or
395 TLS 1.0 is recommended.
396 • When a relying party requests an assertion from an asserting party then bi-lateral authentication is
397 required and the use of SSL 3.0 or TLS 1.0 using server and client authentication are recommended.
398 • When an assertion or request “pushed” to a relying party (for example using the HTTP POST binding),
399 then it is mandated that the response message be digitally signed using the XML digital signature
400 standard.
401

402 4 Profiles
403 SAML supports a number of use cases and profiles. The purpose of this section is to describe a number
404 of the more important ones. The following are described:
405 • Web Browser SSO Profile -
406 • Enhanced Client and Proxy (ECP) Profiles
407 • Using Kerberos
408 • Federation
409 4.1 Web Browser SSO Profile

410 4.1.1 Concept
411 This Web Browser SSO profile supports four different types of model, two concerning how SAML
412 assertions are provided to the Service Provider (push or pull) and two concerned with how the message
413 flows are initiated (IdP or SP initiated). A combination of the binding techniques and how the message
414 flow is initiated gives rise to 6 different combinations., all of which are described later. The push
415 approach involves using either HTTP redirects or HTTP POST messages to deliver a SAML message.
416 The pull model involves sending a artifact (a type of “reference”) to the receiver which then uses the
417 artifact to dereference and obtain the related SAML message. An example of using artifacts is as follows:
418 • A user has an authenticated session on the Identity Provider
419 • The user wants to access a resource on the Service Provider web site and is directed there. In the
420 HTTP message, the artifact carried (either as a query variable or as a control in a POST body). The
421 artifact is a base-64 encoded string. It consists of a unique identity of the Identity Provider and a
422 unique reference to the assertion (called the AssertionHandle). The artifact therefore enables the
423 Service Provider to reference an assertion on the Identity Provider
424 • The Service Provider needs to determine the identity and entitlements of the user and sends a
425 SAML request, containing the artifact, to the Identity Provider asking it what it can assert about the
426 user. The assertions are transferred back in a SAML response.
427 • The Service Provider then can make whatever authentication and authorization decisions it needs
428 to, based on the received assertions.
429 This is an example of the HTTP Artifact binding. Figure 9 compares the pull and push approaches.
430
Figure 9: Push and Pull models for Web Browser SSO Profile
431 The Web Browser SSO Profiles supports two different use cases for situations where the user may or
432 may not be already accessing the Service Provider. The two use cases supported are:
433 • IdP Initiated: The user is accessing resources on the Identity Provider, and wishes to access
434 resources on another web site (the Service Provider). The user already has a current security
435 context with the Identity Provider. A SAML assertion is provided to the Service Provider.
436 • SP initiated: The user is accessing resources on the Service Provider and attempts to access a
437 protected resource requiring knowledge of their authentication and authorization attributes. The
438 Service Provider directs the request to their Identity Provider so that it may provider back SAML
439 assertion(s) in order to validate whether they have access rights to the resource.
440 Figure 10 compares the two approaches.

Service Provider Identity Provider Service Provider Identity Provider
Service Provider
(www.abc.com) Identity Provider
(www.xyz.com) Service Provider
(www.abc.com) (www.xyz.com)Identity Provider
(www.abc.com) (www.xyz.com) (www.abc.com) (www.xyz.com)
Browser Browser
PUSH PULL
Browser Browser
IdP-initated SP-initiated
Figure 10: IdP and SP initiated approaches
441 4.1.2 SP initiated: POST->POST binding

442 In this use case the user attempts to access a resource on www.abc.com. However they do not have
443 current logon session on this site and their identity is managed by www.xyz.com. A SAML
444 <AuthnRequest> is sent to their Identity Provider so that the Identity Provider can provide back a SAML
445 assertion concerning the user. HTTP POST messages are used to deliver the SAML <AuthnRequest>
446 to the Identity Provider as well as receive back the SAML response.
447 Figure 11 illustrates the message flow:

Service Provider Identity Provider
(www.abc.com) (www.xyz.com)
Resource
Intersite Assertion Single

Transfer Consumer Sign-On
Service Service Service
Access Check
Transfer to POST
8 Credential
SP ITS 7
1
<Response>
2
9 Challenge
<Response>
Access 5
Resource in HTML Form
Resource User
Login
<AuthnRequest> POST 6
in HTML Form <AuthnRequest>
3
4
Browser
Figure 11: SP initiated: POST->POST binding

449 The processing is as follows:
450 1. The user attempt to access a resource on www.abc.com. The user does not have any current logon
451 session (i.e. security context) on this site, and is unknown to it.
452 2. The application then directs the request to the local Inter-site Transfer Service. The request contains
453 the URL of the resource on the destination site (the TARGET URL). The URL would look something
454 like the following (without the URL encoding):
455 https://www.abc.com:8002/InterSiteTransfer?TARGET=http://www.xyz.com/index.asp
456 3. The Inter-site Transfer Service sends a HTML form back to the browser. The HTML FORM contains a
457 SAML <AuthnRequest> defining the user for which authentication and authorization information is
458 required. Typically the HTML FORM will contain an input or submit action that will result in a HTTP
459 POST.
460 4. The browser, either due to a user action or via an “auto-submit”, issues a HTTP POST containing the
461 SAML <AuthnRequest> to the Identity Provider's Single Sign-On service.
462 5. If the user does not have any current security context on the Identity Provider, or the policy defines that
463 authentication is required, they user will be challenged to provide valid credentials.
464 6. The user provides valid credentials and a security context is created for the user.
465 7. The Single Sign-On Service sends a HTML form back to the browser. The HTML FORM contains a
466 SAML response, within which is a SAML assertion. The SAML specifications mandate that the
467 response must be digitally signed. Typically the HTML FORM will contain an input or submit action that
468 will result in a HTTP POST.
470 SAML response to be sent to the Service Provider's Assertion Consumer service.
471 9. The Service Provider's Assertion Consumer validates the digital signature on the SAML Response. If
472 this validates correctly, it sends a HTTP redirect to the browser causing it to access the TARGET

473 resource, with a cookie that identifies the local session. An access check is then made to establish
474 whether the user has the correct authorization to access the www.abc.com web site and the TARGET
475 resource. The TARGET resource is then returned to the browser.
476 4.1.3 SP initiated: Redirect->POST binding

480 assertion concerning the user. A HTTP redirect message is used to deliver the SAML <AuthnRequest>
481 to the Identity Provider and a HTTP POST is used to return the SAML response.
483
Resource

Access Check
Transfer to
SP ITS 7
Credential
1 Challenge
2 8
POST 4
Access Resource <Response> User
Resource 6
<Response> Login
3
5
in HTML Form
Redirect with
<AuthnRequest>
Browser
Figure 12: SP initiated: Redirect->POST binding

492 3. The Inter-site Transfer Service sends a redirect message to the browser with HTTP status code of
493 either 302 or 303. The Location HTTP header contains the destination URI of the Sign-On Service of
494 the Identity Provider together with the <AuthnRequest> as a query variable named SAMLRequest.
495 The query string is encoded using the DEFLATE encoding. The browser processes the redirect
496 message and issues a GET to the Sign-on Service with the SAMLRequest query parameter.

497 4. The Sign-on Service determines whether the user has any current security context on the Identity
498 Provider, or that the policy defines that authentication is required. If the user requires to be
499 authenticated he will be challenged to provide valid credentials.
512
513 4.1.4 SP initiated: Artifact->POST binding

514 In this use case the user attempts to access a resource on www.abc.com. However they do not have a
515 current logon session on this site and their identity is managed by www.xyz.com. A SAML artifact is sent to
516 the Identity Provider (using a HTTP redirect), which it uses to obtain a SAML <AuthRequest> from the
517 Service Provider's SAML Responder. When the Identity Provider obtains the SAML <AuthRequest> it
518 provides back to the Service Provider the SAML response using the POST binding mechanism.
520
SAML <ArtifactResponse>
Responder
5
Resource
Intersite Assertion <ArtifactResolve> Single

Access Check
Transfer to 9
SP ITS Credential
1 10 POST
Challenge
2 <Response> 6
Access Resource
Resource User
Login
3 8 7
Redirect with <Response>

SAMLart in HTML Form
Browser
Figure 13: SP initiated: Artifact->POST binding

529 3. The Inter-site Transfer Service generates the <AuthnRequest> while also creating an artifact. The
530 artifact contains the source ID of the www.abc.com SAML responder together with a reference to the
531 assertion (the AssertionHandle). The HTTP Artifact binding allows the choice of either HTTP
532 redirection or a HTML form as the delivery mechanism to the Service Provider. The figure shows the
533 use of the HTML form mechanism. The Inter-site Transfer Service sends a HTML form back to the
534 browser. The HTML FORM contains the SAML artifact, the control name being SAMLart. Typically
535 the HTML FORM will contain an input or submit action that will result in a HTTP POST.
536 4. On receiving the HTTP message, the Single Sign-On Service, extracts the source-ID from the SAML
537 artifact. A mapping between source IDs and remote Responders will already have been established
538 administratively. The Assertion Consumer will therefore know that it has to contact the www.abc.com
539 SAML responder at the prescribed URL. It sends the SAML <ArtifactResolve> message to the
540 Service Provider's SAML responder containing the artifact supplied by its Inter-site Transfer Service.
541 5. The SAML responder supplies back a SAML <ArtifactResponse> message containing the <Authn
542 Request> previously generated.
543 6. The Sign-on Service determines whether the user, for which the <AuthnRequest> pertains, has any
544 current security context on the Identity Provider, or that the policy defines that authentication is
545 required. If the user requires to be authenticated he will be challenged to provide valid credentials.
553 10.The Service Provider's Assertion Consumer validates the digital signature on the SAML Response. If
558
559 4.1.5 SP initiated: POST->Artifact binding

563 assertion concerning the user. A HTTP POST message is used to deliver the SAML <AuthRequest> to
564 the Identity Provider. The response is in the form of a SAML Artifact. In this example the SAML Artifact is
565 provided back within a HTTP POST message. The Service Provider uses the SAML artifact to obtain the
566 SAML response (containing the SAML assertion) from the Identity Provider's SAML Responder.
568

<ArtifactResponse> SAML
Responder
Resource 10
Intersite Assertion 9 Single

Transfer Consumer <ArtifactResolve> Sign-On
Access Check
Transfer to
SP ITS 11 Credential
1 Challenge
2 SAMLart
Access in HTML Form 5
Resource
Resource 8
7
User
Login
<AuthnRequest> POST POST 6
in HTML Form SAMLart <AuthnRequest>
3
4
Browser
Figure 14: SP initiated: POST->Artifact binding

578 SAML <AuthnRequest> defining the user for which authentication and authorization information is
579 required. Typically the HTML FORM will contain an input or submit action that will result in a HTTP
580 POST.
582 SAML <AuthnRequest> to the Identity Provider's Single Sign-On service.
583 5. If the user does not have any current security context on the Identity Provider, or the policy defines that
584 authentication is required, they user will be challenged to provide valid credentials.
586 7. The Single Sign-On Service generates an assertion for the user while also creating an artifact. The
587 artifact contains the source ID of the www.xyz.com SAML responder together with a reference to the
590 use of the HTML form mechanism. The Single Sign-On Service sends a HTML form back to the
593 8. On receiving the HTTP message, the Assertion Consumer Service, extracts the source-ID from the
594 SAML artifact. A mapping between source IDs and remote Responders will already have been

595 established administratively. The Assertion Consumer will therefore know that it has to contact the
596 www.xyz.com SAML responder at the prescribed URL.
597 9. The www.abc.com Assertion Consumer will send a SAML <ArtifactResolve> message to the
598 Identity Provider's SAML responder containing the artifact supplied by the Identity Provider.
599 10.The SAML responder supplies back a SAML <ArtifactResponse> message containing the
600 assertion previously generated. In most implementations, if a valid assertion is received back, then a
601 session on www.abc.com is established for the user (the relying party) at this point.
602 11.Typically the Assertion Consumer then sends a redirection message containing a cookie back to the
603 browser. The cookie identifies the session. The browser then processes the redirect message and
604 issues a HTTP GET to the TARGET resource on www.abc.com. The GET message contains the
605 cookie supplied back by the Assertion Consumer . An access check is then back to established
606 whether the user has the correct authorization to access the www.abc.com web site and the index.asp
607 resource.
608
609 4.1.6 SP initiated: Redirect->Artifact binding

613 assertion concerning the user. A HTTP redirect message is used to deliver the SAML <AuthRequest> to
614 the Identity Provider. The response is in the form of a SAML Artifact. In this example the SAML Artifact is
SAML
<ArtifactResponse>
Responder
Resource 9

Transfer Consumer <ArtifactResolve> Sign-On
8
Access Check
Transfer to 10 7
SP ITS Resource Credential

1
POST
Challenge
2 SAMLart
Access 4
Resource User
6
Login
SAMLart
5
Redirect with in HTML Form
<AuthnRequest>
3
Browser
Figure 15: SP initiated: Redirect->Artifact binding

619

627 3. The Inter-site Transfer Service sends a redirect message to the browser with HTTP status code of
628 either 302 or 303. The Location HTTP header contains the destination URI of the Sign-On Service of
629 the Identity Provider together with the <AuthnRequest> as a query variable named SAMLRequest.
630 The query string is encoded using the DEFLATE encoding. The browser processes the redirect
631 message and issues a GET to the Sign-on Service with the SAMLRequest query parameter.
632 4. The Sign-on Service determines whether the user has any current security context on the Identity
633 Provider, or that the policy defines that authentication is required. If the user requires to be
634 authenticated he will be challenged to provide valid credentials.
649 9. The SAML responder supplies back a SAML <ArtifactResponse> message containing the
657 resource.
658
659 4.1.7 SP initiated: Artifact->Artifact binding

660 In this use case the user attempts to access a resource on www.abc.com. However they do not have a
661 current logon session on this site and their identity is managed by www.xyz.com. A SAML artifact is sent to
662 the Identity Provider (using a HTTP redirect), which it uses to obtain a SAML <AuthnRequest> from the
663 Service Provider's SAML Responder. When the Identity Provider obtains the SAML <AuthnRequest> it
664 provides back to the Service Provider another SAML Artifact. In this example the SAML Artifact is
667

SAML SAML
Responder Responder
<ArtifactResponse>
Resource
5
11
<ArtifactResolve>
4
Service Service 10 Service
Access Check
Transfer to 9
12 Credential
SP ITS
1 POST Challenge
2
SAMLart 8 6
Access Resource
Resource SAMLart User
in HTML Form Login
3 7
Redirect with
SAMLart
Browser
Figure 16: SP initiated: Artifact->Artifact binding

677 3. The Inter-site Transfer Service generates the <AuthnRequest> while also creating an artifact. The
678 artifact contains the source ID of the www.abc.com SAML responder together with a reference to the
684 4. On receiving the HTTP message, the Single Sign-On Service, extracts the source-ID from the SAML
685 artifact. A mapping between source IDs and remote Responders will already have been established
686 administratively. The Assertion Consumer will therefore know that it has to contact the www.abc.com
687 SAML responder at the prescribed URL. It sends the SAML <ArtifactResolve> message to the
688 Service Provider's SAML responder containing the artifact supplied by its Inter-site Transfer Service.
689 5. The SAML responder supplies back a SAML <ArtifactResponse> message containing the <Authn
690 Request> previously generated..
691 6. The Sign-on Service determines whether the user, for which the <AuthnRequest> pertains, has any
692 current security context on the Identity Provider, or that the policy defines that authentication is
693 required. If the user requires to be authenticated he will be challenged to provide valid credentials.

706 10.The www.abc.com Assertion Consumer will send a SAML <ArtifactResolve> message to the
708 11.The SAML responder supplies back a SAML <ArtifactResponse> message containing the
716 resource.
717 4.1.8 IdP initiated: POST binding

718 In this use case the user has a security context on the Identity Provider and wishes to access a resource
719 on a remote server (www.abc.com). The SAML assertion is transported to the Service Provider using the
720 POST binding.
721 Figure 17 shows the process flow:
Identity Provider Service Provider
(www.xyz.com) (www.abc.com)
Resource
Intersite Assertion
Transfer Consumer
Service Service
Access Check
Transfer to
IdP ITS 6
Credential 4 7
POST
Challenge
<Response> Resource
1
User Select
2 5
Login Remote
<Response>
Resource
3 in HTMLForm
Browser

Figure 17: IdP initiated: POST binding
724 1. At some point the user will have been challenged to supply their credentials to the site www.xyz.com.
725 2. The user successfully provides their credentials and has a security context with the Identity Provider.
726 3. The user selects a menu option (or function) on the displayed screen that means the user wants to
727 access a resource or application on another web site www.xyz.com.
728 4. The application then directs the request to the local Inter-site Transfer Service (in this example, hosted
729 on the same web site). The request contains the URL of the resource on the destination site (the
730 TARGET URL). The URL would look something like the following (without the URL encoding):
731 https://www.xyz.com:8002/InterSiteTransfer?TARGET=http://www.abc.com/index.asp
737 SAML response to be sent to the Service provider' Assertion Consumer service.
740 resource, withing with a cookie that identifies the local session. An access check is then made to
741 establish whether the user has the correct authorization to access the www.abc.com web site and the
742 TARGET resource. The TARGET resource is then returned to the browser.
743 4.1.9 IdP initiated: Artifact binding

744 In this use case the user has a security context on the Identity Provider and wishes to access a resource
745 on a remote server (www.abc.com). An artifact is provided to the Service Provider, which its can use (that
746 is “de-reference”) to obtain the associated SAML response from the Identity Provider.
747 Figure 18 shows the process flow:

Identity Provider Service Provider
(www.xyz.com) (www.abc.com)
SAML
Responder <ArtifactResponse> Resource
8
Intersite Assertion
7
Transfer Consumer
Service Service
<ArtifactResolve>
Access Check
Transfer to
IdP ITS
Credential 4 6
9
Challenge POST
User Select SAMLart Resource
1
2 5
Login Remote
SAMLart
Resource
3 in HTML Form
Browser
Figure 18: IdP initiated: Artifact binding
749 1. At some point the user will have been challenged to supply their credentials to the site www.xyz.com.
750 2. The user successfully provides their credentials and has a security context with the Identity Provider.
751 3. The user selects a menu option (or function) on the displayed screen that means the user wants to
752 access a resource or application on a destination web site www.abc.com .
753 4. The application causes a HTTP request to be sent to the Identity Provider's Inter-site Transfer Service.
754 The request contains the URL of the resource on the destination site. This is known as the TARGET
755 URL. The URL would look something like the following (without the URL encoding):
756 https://www.xyz.com:8002/InterSiteTransfer?TARGET=http://www.abc.com/index.asp
757 5. The Inter-site Transfer Service generates an assertion for the user while also creating an artifact. The
769 Identity Provider's SAML responder containing the artifact supplied by its Inter-site Transfer Service.
770 8. The SAML responder supplies back a SAML <ArtifactResponse> message containing the
773 9. Typically the Assertion Consumer then sends a redirection message containing a cookie back to the

778 resource.
779 4.2 ECP Profile

780 4.2.1 Introduction
781 The Enhanced Client and Proxy (ECP) Profile supports several use cases, in particular:
782 • Use of a proxy server, for example a WAP gateway in front of a mobile device which has limited
783 functionality
784 • Clients where it is impossible to use redirects
785 • It is impossible for the Identity Provider and Service Provider to directly communicate (and hence the
786 HTTP Artifact binding can not be used)
787 The ECP profile defines a single binding – PAOS (Reserve SOAP). The Profile uses SOAP headers and
788 SOAP bodies to transport SAML <AuthnRequest> and SAML <Response> messages between the
789 Service Provider and the Identity Provider.
790 4.2.2 ECP Profile using PAOS binding

791 Figure 19 shows the message flows between the ECP, Service Provider and Identity Provider. The ECP is
792 shown as a single logical entity.
Resource
Access Check
<Response>
in PAOS
response
1 6 4
5
Access Resource <Response>

Resource in SOAP
2
response 3
<AuthnRequest> <AuthnRequest>
in PAOS request in SOAP request
Enhanced Client and Proxy
Figure 19: ECP with PAOS


794 1. The ECP wishes to gain access to a resource on the Service Provider (www.abc.com). The ECP will
795 issue a HTTP request for the resource. The HTTP request contains a PAOS HTTP header defining
796 that the ECP service is to be used.
797 2. Accessing the resource requires that the principal has a valid security context, and hence a SAML
798 assertion needs to be supplied to the Service Provider. In the HTTP response to the ECP an
799 <AuthnRequest> is carried within a SOAP body. Additional information, using the PAOS binding, is
800 provided back to the ECP
801 3. After some processing in the ECP the <AuthnRequest> is sent to the appropriate Identity Provider
802 using the SAML SOAP binding.
803 4. The Identity Provider validates the <AuthnRequest> and sends back to the ECP a SAML
804 <Response>, again using the SAML SOAP binding.
805 5. The ECP extracts the <Response> and forwards it to the Service Provider as a PAOS response.
806 6. The Service Provider sends to the ECP a HTTP response containing the resource originally requested.
807 4.3 Kerberos

808 TBD - TIM ALSOP
809 4.4 Federation

810 PROVIDE DETAILS OF A FEW FEDERATION SCENARIOS/PROFILES – JOHN HUGHES
811 4.4.1 Introduction

812 This section provides details of a number of use cases when identities are federated. The following use
813 cases are described in the following sections:
814 • Federation during <AuthnRequest>: an Identity Provider federates the Identity Provider's
815 Principal with the Principal's identity at the Service Provider.
816 • Federation Termination: termination of a Federation
817 • Accounting Linking: mapping between two existing accounts on service Providers via an Identity
818 Provider.
819 4.4.2 Federation during <AuthnRequest>

820 TBD – John Hughes
821 4.4.3 Federation Termination

823 4.4.4 Accounting Linking


825 5 Documentation roadmap
826
827 • Security Assertion Markup Language (SAML) 2.0 Executive Overview. (sstc-saml-exec-
828 overview-2.0). Provides a senior executive
829 • Security Assertion Markup Language (SAML) 2.0 Technical Overview. (sstc-saml-tech-
830 overview-2.0) This document
831 • Assertions and Protocol for the OASIS Security Assertions Markup Language (SAML) V2.0
832 (sstc-saml-core-2.0). Defines the syntax and semantics for XML-encoded assertions about
833 authentication, attributes and authorization, and for the protocol that conveys this information.
834 • Security and Privacy Considerations for the OASIS Security Assertions Markup Language
835 (SAML) V2.0 (sstc-saml-sec-consider-2.0). Describes and analyzes the security and privacy
836 properties of SAML
837 • sstc-saml-impl-guidelines-2.0
838 • Bindings for the OASIS Security Assertions Markup Language (SAML) V2.0 (sstc-saml-
839 bindings-2.0). Defines protocol bindings for the use of SAML assertions and request-response
840 messages in communications protocols and frameworks.
841 • Profiles for the OASIS Security Assertions Markup Language (SAML) V2.0 (sstc-saml-profiles-
842 2.0). Defines how the assertions, protocols and bindings combine to define specific profiles.
843 • Conformance Program Specification for the OASIS Security Assertions Markup Language
844 (SAML) V2.0 (sstc-saml-conform-2.0). Describes the program and technical requirements for
845 SAML conformance.
846 • Metadata for the OASIS Security Assertions Markup Language (SAML) V2.0 (sstc-saml-
847 metadata-2.0). Describes metadata format to enable configuration data to be shared in a
848 standardized format.
849 • Glossary for the OASIS Security Assertions Markup Language (SAML) V2.0 (sstc-saml-
850 glossary-2.0). Defines terms used throughout the OASIS Security Assertion Markup Language
851 (SAML) specifications.
852 • Authentication Context for the OASIS Security Assertions Markup Language (SAML) V2.0
853 (sstc-saml-authn-context—2.0). Defines a syntax for the definition of authentication context
854 declarations.
855 • sstc-saml-schema-assertion-2.0
856 • sstc-saml-schema-protocol-2.0

857 6 Comparison Between SAML 2.0 and SAML 1.1
858 Note that this appendix contains information that is known to be out of date; it only covers differences
859 through about core-10 in most cases. To be updated soon with other differences.
860 SAML constitutes a large-scale realization of features derived from the Liberty Alliance Identity Federation
861 Framework (ID-FF) V1.2 specifications that were contributed to the SSTC in 2003, along with other
862 requested features, improvements, and streamlining.
863 The on-the-wire representations of SAML V2.0 assertions and messages is incompatible with SAML V1.x
864 processors. As is explained in the SAML assertions and protocols specification [SAMLCore], only new
865 major versions of SAML (of which this is one) typically cause this sort of incompatibility. However, most
866 such incompatibility is syntactic in nature; the expressiveness of SAML has increased rather than
867 markedly changed.
868 The differences are described in the sections below. Note that these descriptions may not be complete;
869 for a full accounting of precise differences to SAML V1.1 specification text, see [some change-bar version
870 of specs that doesn't exist yet].
871 6.1 Differences in the Organization of the Specifications

872 • The assertion and procotol (“core”) specification is now referred to as Assertions and Protocols,
873 because it now defines a set of protocols.
874 • Processing rules are now clearly called out in each protocol.
875 • Bibliographic references have been divided into normative and non-normative categories.
876 • The single bindings and profiles specification has been split into two documents, one for bindings
877 and one for profiles, and the latter now includes “attribute profiles”.
878 • There is a new authentication context specification and several accompanying schemas.
879 • There is a new metadata specification and an accompanying schema.
880 6.2 Versioning Differences

881 • The SAML assertions namespace (known by its convention prefix saml:) and protocols namespace
882 (known by its conventional prefix samlp:) namespaces now contain the string “2.0” in recognition of
883 this new major version of SAML.
884 • The MajorVersion and MinorVersion attributes that appear on various elements now need to
885 contain the string values “2” and “0”, respectively in recognization of this new major version of
886 SAML.
887 • A series of changes planned during SAML the V1.x design cycles have been made:
888 • The deprecated <AuthorityBinding> element has been removed.
889 • The deprecated <RespondWith> element has been removed.
890 • The deprecated name identifier and artifact URI-based identifiers have been removed.
891 • URI references are now required to be absolute.
892 • The description of appearance of the <Status> element in SOAP messages has been
893 improved.
894 6.3 Subject and Subject Confirmation Differences

895 • The <SubjectStatement> element and its type have been removed.
896 • The <Subject> element has been moved up to appear on the <Assertion> element, where the
897 subject so specified applies to all inner statements. (The <Subject> element is optional for

898 extensibility reasons, but is required for all SAML-specified statement types.)
899 • The <ConfirmationMethod> element is now non-repeatable (it is still required for one to appear
900 inside its parent).
901 • The <ds:KeyInfo> element is now allowed only inside <SubjectConfirmationData>.
902 6.4 Encryption-Related Differences

903 • The XML Encryption schema has been imported into the assertions [also protocols?] schema.
904 • The name identifier structure, the attribute structure, and the assertion structure have all been
905 refactored to allow encryption.
906 6.5 Attribute-Related Differences

907 • The AttributeNamespace field has been removed in favor of NameFormat, and two new URI-
908 based identifiers of attribute name format types have been defined for use in this field. This field can
909 be left blank, as a default has been defined.
910 • The name of the AttributeName field has been changed to just Name.
911 • Arbitrary XML attributes can now appear on the <Attribute> and <AttributeDesignator>
912 elements without a supporting extension schema.
913 • Clearer instructions have been provided for how to represent null and multi-valued attributes.
914 6.6 Differences in the Request-Response Mechanism

915 • The request datatype hierarchy has been reorganized; all queries are now kinds of requests, not
916 inside requests, and the plain <Query> has been removed.
917 • Consent and <Extensions> constructs have been added to all requests.
918 • The Issuer field is now an element and is based on the same datatype that underlies name
919 identifiers, for more unified treatment.
920 • The response type hierarchy has been reorganized; most response elements in the various
921 protocols are simply of StatusResponseType.
922 • New status codes have been added to reflect possible statuses when using the new protocols.
923 6.7 Differences in the Protocols for Retrieving Assertions

924 • Instead of the <AssertionIDReference> in <Request>, the <AssertionIDRequest>
925 element is now used to get an assertion by means of its ID.
926 • Instead of the <AssertionArtifact> element to retrieve assertions in a response message, now
927 a special <ArtifactResolve> protocol is used to get SAML protocol messages by means of an
928 artifact. All types of protocol messages can theoretically be retrieved in this fashion, but in practice
929 only some kinds will appear in profiles.
930 • There is a new <AssertionURIReference> element to go with a new HTTP-based retrieval
931 binding.
932 6.8 Session-Related Differences

933 • A SessionIndex attribute has been added to the <Statement> and <SubjectQuery>
934 elements. Thus, this index is available on all statements, not just <AuthenticationStatement>.
935 • There is a new single logout protocol for near-simultaneous logout from multiple related sessions.

936 6.9 Federation-Related Differences
937 • There is a new protocol for requesting that authentication be performed and a new assertion with an
938 authentication statement returned. As part of this, the policy for the desired form of name identifier
939 can be specified.
940 • In such an assertion, it is now possible to specify many more details about the authentication that
941 was performed using the new authentication context schemas; the old AuthenticationMethod
942 field has been removed.
943 • There is a new federated name management (registration and deregistration) protocol.
944 • There is a new name identifier mapping protocol.
945 6.10 Differences in Bindings and Profiles

946 • A lot of profile detail has been refactored out to become new, more generic bindings; the profiles are
947 much thinner. For example, there's now an HTTP redirect/POST binding.
948 • There is a new HTTP-based binding added for retrieval of assertions by means of URIs.
949 • A PAOS (reverse SOAP) binding has been added.
950 • An enhanced client profile has been added.
951 • The two original browser profiles (browser/artifact and browser/POST) have become a single web
952 SSO profile.
953 • A set of mechanisms for relaying state have been added to most of the bindings.
954 6.11 Other Differences

955 • XSD element substitution has been blocked.
956 • The <ds:Signature> that allows for the digital signing of assertions and messages has been
957 positioned earlier in the respective content models.
958 • The usage of <ds:KeyInfo> has been clarified to more clearly allow for impersonation.
959 • The authorization decision feature (statement and query) has been frozen; if more functionality is
960 desired, it is suggested that XACML [XACML] be used.
961 • A <ProxyRestriction> element and other conditions has been added.
962 TBS: validity period semantics and syntax extended, element and attribute name changes, terminology,
963 wildcarding changes, removal of QNames in content, etc.

964 7 References
965
966 [SAML-ASSERT] Assertions and Protocols for the OASIS Security Assertions Markup Language
967 (SAML) V2.0 (sstc-saml-core-2.0).
968
969 [SAML-BIND] Binding for the OASIS Security Assertions Markup Language (SAML) V2.0 (sstc-
970 saml-bindings-2.0).
971
972 [SAML-PROF] Profiles for the OASIS Security Assertions Markup Language (SAML) V2.0 (sstc-
973 saml-profiles-2.0).
974
975 [SAML-SEC] Security and Privacy Considerations for the OASIS Security Assertions Markup
976 Language (SAML) V2.0 (sstc-saml-sec-consider-2.0)
977
978 [SAML-Meta] Metadata for the OASIS Security Assertions Markup Language (SAML) V2.0
979 (sstc-saml-metadata-2.0).
980
981 [SAML-AuthnCxt] Authentication Context for the OASIS Security Assertions Markup Language
982 (SAML) V2.0 (sstc-saml-authn-context-2.0)
983
984 [XACML] TBD
985
986 Etc etc
987

988 A. Acknowledgments
989 The editors would like to acknowledge the contributions of the OASIS Security Services Technical
990 Committee, whose voting members at the time of publication were:
991 • TBD

992 B. Revision History
Rev Date By Whom What
00 6 Nov 2003 John Hughes Storyboard version
01 22 Jul 2004 John Hughes First draft
993

994 C. Notices
995 OASIS takes no position regarding the validity or scope of any intellectual property or other rights that
996 might be claimed to pertain to the implementation or use of the technology described in this document or
997 the extent to which any license under such rights might or might not be available; neither does it represent
998 that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to
999 rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made
1000 available for publication and any assurances of licenses to be made available, or the result of an attempt
1001 made to obtain a general license or permission for the use of such proprietary rights by implementors or
1002 users of this specification, can be obtained from the OASIS Executive Director.
1003 OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or
1004 other proprietary rights which may cover technology that may be required to implement this specification.
1005 Please address the information to the OASIS Executive Director.
1006 Copyright © OASIS Open 2004. All Rights Reserved.
1007 This document and translations of it may be copied and furnished to others, and derivative works that
1008 comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and
1009 distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and
1010 this paragraph are included on all such copies and derivative works. However, this document itself does
1011 not be modified in any way, such as by removing the copyright notice or references to OASIS, except as
1012 needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights
1013 defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it
1014 into languages other than English.
1015 The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors
1016 or assigns.
1017 This document and the information contained herein is provided on an “AS IS” basis and OASIS
1018 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
1019 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
1020 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


SAML TechOverviewV20 Draft7874

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

SAML TechOverviewV20 Draft7874

Cargado por

Copyright:

Formatos disponibles

2 Security Assertion Markup Language

3 (SAML) 2.0 Technical Overview

sstc-saml-tech-overview-2.0-draft-01 22 July 2004

sstc-saml-tech-overview-2.0-draft-01 22 July 2004

sstc-saml-tech-overview-2.0-draft-01 22 July 2004

sstc-saml-tech-overview-2.0-draft-01 22 July 2004

137 2.1 Single Sign-On Use Case

149 2.2 Federation Use Case

sstc-saml-tech-overview-2.0-draft-01 22 July 2004

Figure 2: Federation Use Case

sstc-saml-tech-overview-2.0-draft-01 22 July 2004

160 3.1 Basic Concepts

185 3.2 Summary of SAML Components

sstc-saml-tech-overview-2.0-draft-01 22 July 2004

sstc-saml-tech-overview-2.0-draft-01 22 July 2004

Figure 3: SAML Components

260 3.3 SAML Structure and Examples

262 3.3.1 Assertions

sstc-saml-tech-overview-2.0-draft-01 22 July 2004

Figure 4: SAML Assertion Structure

Figure 5: SAML Assertion

sstc-saml-tech-overview-2.0-draft-01 22 July 2004

Figure 6: SOAP over HTTP binding

Figure 7: SAML Artifact Request

sstc-saml-tech-overview-2.0-draft-01 22 July 2004

Figure 8: SAML Response with SOAP message

353 3.4 Single Sign-On and Federation Principals

sstc-saml-tech-overview-2.0-draft-01 22 July 2004

385 3.6 Security in SAML

sstc-saml-tech-overview-2.0-draft-01 22 July 2004

409 4.1 Web Browser SSO Profile

sstc-saml-tech-overview-2.0-draft-01 22 July 2004

441 4.1.2 SP initiated: POST->POST binding

sstc-saml-tech-overview-2.0-draft-01 22 July 2004

Intersite Assertion Single

Figure 11: SP initiated: POST->POST binding

sstc-saml-tech-overview-2.0-draft-01 22 July 2004

476 4.1.3 SP initiated: Redirect->POST binding

Intersite Assertion Single

Figure 12: SP initiated: Redirect->POST binding

sstc-saml-tech-overview-2.0-draft-01 22 July 2004

513 4.1.4 SP initiated: Artifact->POST binding

Intersite Assertion <ArtifactResolve> Single

Redirect with <Response>

Figure 13: SP initiated: Artifact->POST binding

sstc-saml-tech-overview-2.0-draft-01 22 July 2004

559 4.1.5 SP initiated: POST->Artifact binding

sstc-saml-tech-overview-2.0-draft-01 22 July 2004

Intersite Assertion 9 Single

Figure 14: SP initiated: POST->Artifact binding

sstc-saml-tech-overview-2.0-draft-01 22 July 2004

609 4.1.6 SP initiated: Redirect->Artifact binding

Intersite Assertion Single

SP ITS Resource Credential

Figure 15: SP initiated: Redirect->Artifact binding

sstc-saml-tech-overview-2.0-draft-01 22 July 2004

659 4.1.7 SP initiated: Artifact->Artifact binding

668 Figure 16 illustrates the message flow:

sstc-saml-tech-overview-2.0-draft-01 22 July 2004

Figure 16: SP initiated: Artifact->Artifact binding

sstc-saml-tech-overview-2.0-draft-01 22 July 2004

717 4.1.8 IdP initiated: POST binding