oasis-wss–saml-2.0-token-profile-1.0saml-token-profile-1.1 175 MayJan 2005
Copyright © OASIS Open 2003-2005. All Rights Reserved. Page 1 of 3736
1
Web Services Security: 2
SAML 2.0 Token Profile 1.10 3
Working Draft 021, 179 MayJan. 2005 4
Document identifier: 5
oasis-wss–saml-2.0-token-profile-1.10(PDF)(Word) 6
Location: 7
http://docs.oasis-open.org/wss/oasis-wss-saml-2.0-token-profile-1.10.pdf 8
Errata Location: 9
http://www.oasis-open.org/committees/wss 10
Editors: 11
Ronald Monzillo Sun 12
Chris Kaler Microsoft 13
Anthony Nadalin IBM 14
Phillip Hallam-Baker VeriSign 15
Contributors (voting members of the WSS TC as of Sept 8, 2004) 16
Gene Thurston AmberPoint 17
Frank Siebenlist Argonne National Laboratory 18
Hal Lockhart BEA Systems, Inc. 19
Corinna Witt BEA Systems, Inc. 20
Merlin Hughes Betrusted (Baltimore Technologies) 21
Davanum Srinivas Computer Associates 22
Thomas DeMartini ContentGuard 23
Guillermo Lao ContentGuard 24
Sam Wei Documentum 25
Tim Moses Entrust 26
Dana Kaufman Forum Systems, Inc. 27
Toshihiro Nishimura Fujitsu 28
Kefeng Chen GeoTrust 29
Irving Reid Hewlett-Packard 30
Kojiro Nakayama Hitachi 31
Paula Austel IBM 32
Derek Fu IBM 33
oasis-wss–saml-2.0-token-profile-1.0saml-token-profile-1.1 175 MayJan 2005
Copyright © OASIS Open 2003-2005. All Rights Reserved. Page 2 of 3736
Maryann Hondo IBM 34
Kelvin Lawrence IBM (TC Chair) 35
Michael McIntosh IBM 36
Anthony Nadalin IBM 37
Nataraj Nagaratnam IBM 38
Ron Williams IBM 39
Don Flinn Individual 40
Bob Morgan Internet2 41
Kate Cherry Lockheed Martin 42
Paul Cotton Microsoft Corporation 43
Vijay Gajjala Microsoft Corporation 44
Alan Geller Microsoft Corporation 45
Chris Kaler Microsoft Corporation (TC Chair) 46
Rich Levinson Netegrity, Inc. 47
Prateek Mishra Netegrity, Inc. 48
Frederick Hirsch Nokia 49
Senthil Sengodan Nokia 50
Abbie Barbir Nortel Networks 51
Lloyd Burch Novell 52
Charles Knouse Oblix 53
Steve Anderson OpenNetwork (Secretary) 54
Vamsi Motukuru Oracle 55
Ramana Turlapati Oracle 56
Ben Hammond RSA Security 57
Andrew Nash RSA Security 58
Rob Philpott RSA Security 59
Martijn de Boer SAP 60
Blake Dournaee Sarvega 61
Coumara Radja Sarvega 62
Pete Wenzel SeeBeyond Technology Corporation 63
Jeff Hodges Sun Microsystems 64
Ronald Monzillo Sun Microsystems 65
Jan Alexander Systinet 66
Symon Chang Tibco 67
J Weiland US Dept of the Navy 68
Phillip Hallam-Baker Verisign 69
Maneesh Sahu Westbridge Technology 70
Contributors of input Documents (if not already listed above): 71
Hiroshi Maruyama IBM 72
Chris McLaren Netegrity 73
Jerry Schwarz Oracle 74
Eve Maler Sun Microsystems 75
Hemma Prafullchandra VeriSign 76
oasis-wss–saml-2.0-token-profile-1.0saml-token-profile-1.1 175 MayJan 2005
Copyright © OASIS Open 2003-2005. All Rights Reserved. Page 3 of 3736
Abstract: 77
This document describes how to use Security Assertion Markup Language 78
(SAML) V1.1 and V2.0 assertions with the Web Services Security (WSS): 79
SOAP Message Security V1.1 specification. 80
With respect to the description of the use of SAML V1.1, this document 81
subsumes and is totally consistent with the Web Services Security: SAML 82
Token Profile 1.0. 83
Based on the predicted date of standardization of the 1.1 version of the Web 84
Services Security core specification, the first version of this profile may 85
change such that it based on the 1.1 version of the core. 86
Status: 87
This is a working draft. Please send comments to the editors. 88
Committee members should send comments on this specification to 89
[email protected] list. Others should subscribe to and send comments 90
to the [email protected] list. To subscribe, visit 91
http://lists.oasis-open.org/ob/adm.pl. 92
For information on the disclosure of Intellectual Property Rights or licensing 93
terms related to the work of the Web Services Security TC please refer to the 94
Intellectual Property Rights section of the TC web page at http://www.oasis-95
open.org/committees/wss/. The OASIS policy on Intellectual Property Rights 96
is described at http://www.oasis-open.org/who/intellectualproperty.shtml.97
oasis-wss–saml-2.0-token-profile-1.0saml-token-profile-1.1 175 MayJan 2005
Copyright © OASIS Open 2003-2005. All Rights Reserved. Page 4 of 3736
Table of Contents 98
1 Introduction..............................................................................................6 99
1.1 Goals .....................................................................................................6 100
1.1.1 Non-Goals ........................................................................................6 101
2 Notations and Terminology .........................................................................7 102
2.1 Notational Conventions ............................................................................7 103
2.2 Namespaces ...........................................................................................7 104
2.3 Terminology ...........................................................................................8 105
3 Usage ......................................................................................................9 106
3.1 Processing Model.....................................................................................9 107
3.2 SAML Version Differences .........................................................................9 108
3.2.1 Assertion Identifier ........................................................................ 109 109
3.2.2 Relationship of Subjects to Statements ..............................................10 110
3.2.3 Assertion URI Reference Replaces AuthorityBinding .............................12 111
3.2.4 Attesting Entity Identifier .................................................................12 112
3.3 Attaching Security Tokens ......................................................................12 113
3.4 Identifying and Referencing Security Tokens.............................................13 114
3.4.1 SAML Assertion Referenced from Header or Element........................ 1615 115
3.4.2 SAML Assertion Referenced from KeyInfo ...........................................17 116
3.4.3 SAML Assertion Referenced from SignedInfo................................... 1918 117
3.4.4 SAML Assertion Referenced from Encrypted Data Reference ............. 2019 118
3.5 Subject Confirmation of SAML Assertions ............................................. 2120 119
3.5.1 Holder-of-key Subject Confirmation Method.................................... 2221 120
3.5.2 Sender-vouches Subject Confirmation Method ................................ 2625 121
3.6 Error Codes ...................................................................................... 3029 122
4 Threat Model and Countermeasures (non-normative)............................... 3231 123
4.1 Eavesdropping .................................................................................. 3231 124
4.2 Replay ............................................................................................. 3231 125
4.3 Message Insertion ............................................................................. 3332 126
4.4 Message Deletion .............................................................................. 3332 127
4.5 Message Modification ......................................................................... 3332 128
4.6 Man-in-the-Middle ............................................................................. 3332 129
5 References ......................................................................................... 3433 130
oasis-wss–saml-2.0-token-profile-1.0saml-token-profile-1.1 175 MayJan 2005
Copyright © OASIS Open 2003-2005. All Rights Reserved. Page 5 of 3736
Appendix A: Revision History ......................................................................... 3635 131
Appendix B: Notices ..................................................................................... 3736 132
133
oasis-wss–saml-2.0-token-profile-1.0saml-token-profile-1.1 175 MayJan 2005
Copyright © OASIS Open 2003-2005. All Rights Reserved. Page 6 of 3736
1 Introduction 134
The WSS: SOAP Message Security specification defines a standard set of SOAP 135
extensions that implement SOAP message authentication and encryption. This 136
specification defines the use of Security Assertion Markup Language (SAML) 137
assertions as security tokens from the <wsse:Security> header block defined by the 138
WSS: SOAP Message Security specification. 139
1.1 Goals 140
The goal of this specification is to define the use of SAML V1.1 and V2.0 assertions in 141
the context of WSS: SOAP Message Security including for the purpose of securing 142
SOAP messages and SOAP message exchanges. To achieve this goal, this profile 143
describes how: 144
1. SAML assertions are carried in and referenced from <wsse:security> Headers. 145
2. SAML assertions are used with XML signature to bind the subjects and statements 146
of the assertions (i.e. i.e., the claims) to a SOAP message. 147
1.1.1 Non-Goals 148
The following topics are outside the scope of this document: 149
3.1. Defining SAML statement syntax or semantics. 150
4.2. Describing the use of SAML assertions other than for SOAP Message Security. 151
5.3. Describing the use of SAML V1.0 assertions with the Web Services Security 152
(WSS): SOAP Message Security specification. 153
oasis-wss–saml-2.0-token-profile-1.0saml-token-profile-1.1 175 MayJan 2005
Copyright © OASIS Open 2003-2005. All Rights Reserved. Page 7 of 3736
2 Notations and Terminology 154
This section specifies the notations, namespaces, and terminology used in this 155
specification. 156
2.1 Notational Conventions 157
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159
document are to be interpreted as described in RFC2119. 160
This document uses the notational conventions defined in the WS-Security SOAP 161
Message Security document. 162
Namespace URIs (of the general form "some-URI") represent some application-163
dependent or context-dependent URI as defined in RFC2396. 164
This specification is designed to work with the general SOAP message structure and 165
message processing model, and should be applicable to any version of SOAP. The 166
current SOAP 1.2 namespace URI is used herein to provide detailed examples, but 167
there is no intention to limit the applicability of this specification to a single version 168
of SOAP. 169
Readers are presumed to be familiar with the terms in the Internet Security 170
Glossary. 171
2.2 Namespaces 172
The appearance of the following [XML-ns] namespace prefixes in the examples within 173
this specification should be understood to refer to the corresponding namespaces 174
(from the following table) whether or not an XML namespace declaration appears in 175
the example: 176
Prefix Namespace
S11 http://schemas.xmlsoap.org/soap/envelope/
S12 http://www.w3.org/2003/05/soap-envelope
ds http://www.w3.org/2000/09/xmldsig#
xenc http://www.w3.org/2001/04/xmlenc
wsse http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-01.xsd
wsse11 TBD
oasis-wss–saml-2.0-token-profile-1.0saml-token-profile-1.1 175 MayJan 2005
Copyright © OASIS Open 2003-2005. All Rights Reserved. Page 8 of 3736
wsu http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
saml uUrn: oasis:names:tc:SAML:1.0:assertion
saml2 uUrn: oasis:names:tc:SAML:2.0:assertion
samlp uUrn: oasis:names:tc:SAML:1.0:protocol
Table-1 Namespace Prefixes 177
2.3 Terminology 178
This specification employs the terminology defined in the WSS: SOAP Message 179
Security specification. The definitions for additional terminology used in this 180
specification appear below. 181
182
Attesting Entity – the entity that provides the confirmation evidence that will be used 183
to establish the correspondence between the subjects and claims of SAML 184
statements (in SAML assertions) and SOAP message content. 185
186
Confirmation Method Identifier – the value within a SAML SubjectConfirmation 187
element that identifies the subject confirmation process to be used with the 188
corresponding statements. 189
190
Subject Confirmation – the process of establishing the correspondence between the 191
subject and claims of SAML statements (in SAML assertions) and SOAP message 192
content by verifying the confirmation evidence provided by an attesting entity. 193
194
SAML Assertion Authority - An abstract system entity that issues assertions. 195
196
Subject – A representation of the entity to which the claims in one or more SAML 197
statements apply. 198
oasis-wss–saml-2.0-token-profile-1.0saml-token-profile-1.1 175 MayJan 2005
Copyright © OASIS Open 2003-2005. All Rights Reserved. Page 9 of 3736
3 Usage 199
This section defines the specific mechanisms and procedures for using SAML 200
assertions as security tokens. 201
3.1 Processing Model 202
This specification extends the token-independent processing model defined by the 203
WSS: SOAP Message Security specification. 204
When a receiver processes a <wsse:Security> header containing or referencing 205
SAML assertions, it selects, based on its policy, the signatures and assertions that it 206
will process. It is assumed that a receiver’s signature selection policy MAY rely on 207
semantic labeling1 of <wsse:SecurityTokenReference> elements occurring in the 208
<ds:KeyInfo> elements within the signatures. It is also assumed that the assertions 209
selected for validation and processing will include those referenced from the 210
<ds:KeyInfo> and <ds:SignedInfo> elements of the selected signatures. 211
As part of its validation and processing of the selected assertions, the receiver MUST2 212
establish the relationship between the subject and claims of the SAML statements (of 213
the referenced SAML assertions) and the entity providing the evidence to satisfy the 214
confirmation method defined for the statements (i.e. i.e., the attesting entity). Two 215
methods for establishing this correspondence, holder-of-key and sender-vouches 216
are described below. Systems implementing this specification MUST implement the 217
processing necessary to support both of these subject confirmation methods. 218
3.2 SAML Version Differences 219
The following sub-sections describe the differences between SAML V1.1 and V2.0 220
that apply to this specification. 221
1 The optional Usage attribute of the <wsse:SecurityTokenReference> element
MAY be used to associate one of more semantic usage labels (as URIs) with a
reference and thus use of a Security Token. Please refer to WSS: SOAP Message
Security for the details of this attribute.
2 When the confirmation method is urn:oasis:names:tc:SAML:1.0:cm:bearer, proof
of the relationship between the attesting entity and the subject of the statements in
the assertion is implicit and no steps need be taken by the receiver to establish this
relationship.
oasis-wss–saml-2.0-token-profile-1.0saml-token-profile-1.1 175 MayJan 2005
Copyright © OASIS Open 2003-2005. All Rights Reserved. Page 10 of 3736
3.2.1 Assertion Identifier 222
In SAML V1.1 the name of the assertion identifier attribute is “AssertionID. In SAML 223
v2.0 the name of the assertion identifier attribute is “ID”. In both versions the type 224 of the identifier attribute is xs:ID. 225
3.2.2 Relationship of Subjects to Statements 226
A SAML assertion contains a collection of 0 or more statements. In SAML V1.1, a 227
separate subject with separate subject confirmation methods may be specified for 228
each statement of an assertion. In SAML V2.0, at most one subject and at most one 229
set of subject confirmation methods may be specified for all the statements of the 230
assertion. These distinctions are described in more detail by the following 231
paragraphs. 232
A SAML V1.1 statement that contains a <saml:Subject> element (i.e., a subject 233
statement) may contain a <saml:SubjectConfimation> element that defines the 234
rules for confirming the subject and claims of the statement. If present, the 235
<saml:SubjectConfirmation> element occurs within the subject element, and 236
defines one or more methods (i.e., <saml:ConfirmationMethod> elements) by which 237
the statement may be confirmed and will include a <ds:KeyInfo>3 element when any 238
of the specified methods are based on demonstration of a confirmation key. The 239
<saml:SubjectConfirmation> element also provides for the inclusion of additional 240
information to be applied in the confirmation method processing via the optional 241
<saml:SubjectConfirmationData> element. The following example depicts a SAML 242
V1.1 assertion containing two subject statements with different subjects and 243
different subject confirmation elements. 244
<saml:Assertion 245 … 246
<saml:SubjectStatement> 247 <saml:Subject> 248 <saml:NameIdentifier 249 … 250 </saml:NameIdentifier> 251 <saml:SubjectConfirmation> 252 <saml:ConfirmationMethod> 253 urn:oasis:names:tc:SAML:1.0:cm:sender-vouches 254 </saml:ConfirmationMethod> 255 <saml:ConfirmationMethod> 256 urn:oasis:names:tc:SAML:1.0:cm:holder-of-key 257 </saml:ConfirmationMethod> 258 <ds:KeyInfo> 259 <ds:KeyValue>…</ds:KeyValue> 260 </ds:KeyInfo> 261 </saml:SubjectConfirmation> 262 </saml:Subject> 263 …. 264 </saml:SubjectStatement> 265
<saml:SubjectStatement> 266
3 When a <ds:keyInfo> element is specified, it identifies the key that applies to all
the key confirmed methods of the confirmation element.
oasis-wss–saml-2.0-token-profile-1.0saml-token-profile-1.1 175 MayJan 2005
Copyright © OASIS Open 2003-2005. All Rights Reserved. Page 11 of 3736
<saml:Subject> 267 <saml:NameIdentifier 268 … 269 </saml:NameIdentifier> 270 <saml:SubjectConfirmation> 271 <saml:ConfirmationMethod> 272 urn:oasis:names:tc:SAML:1.0:cm:sender-vouches 273 </saml:ConfirmationMethod> 274 </saml:SubjectConfirmation> 275 </saml:Subject> 276 …. 277 </saml:SubjectStatement> 278 … 279 </saml:Assertion> 280
A SAML V2.0 assertion may contain a single <saml2:Subject> that applies to all the 281
statements of the assertion. When a subject is included in A SAML V2.0 assertion, it 282
may contain any number of <saml2:SubjectConfimation> elements, satisfying any 283
of which is sufficient to confirm the subject and all the statements of the assertion. 284
Each <saml2:SubjectConfirmation> element identifies a single confirmation 285
method (by attribute value) and may include an optional 286
<saml2:SubjectConfirmationData> element that is used to specify optional 287
confirmation method independent condition attributes and to define additional 288
method specific confirmation data. In the case of a key dependent confirmation 289
method, a <saml2:KeyInfoConfirmationDataType> that includes 1 or more 290
<ds:KeyInfo> elements is included as <saml2:SubjectConfirmationData>. In this 291
case, each <ds:KeyInfo> element identifies a key that may be demonstrated to 292
confirm the assertion. The following example depicts a SAML V2.0 assertion 293
containing a subject with multiple confirmation elements that apply to all the 294
statements of the assertion. 295
<saml2:Assertion 296 … 297
<saml2:Subject> 298 <saml2:NameID> 299 … 300 </saml2:NameID> 301 <saml2:SubjectConfirmation 302 Method=”urn:oasis:names:tc:SAML:2.0:cm:sender-vouches”> 303 <saml2:SubjectConfirmationData> 304 Address=”129.148.9.42” 305 </saml2:SubjectConfirmationData> 306 </saml2:SubjectConfirmation> 307 <saml2:SubjectConfirmation 308 Method=”urn:oasis:names:tc:SAML:2.0:cm:holder-of-key”> 309 <saml2:KeyInfoSubjectConfirmationData> 310 <ds:KeyInfo> 311 <ds:KeyValue>…</ds:KeyValue> 312 </ds:KeyInfo> 313 </saml2:KeyInfoSubjectConfirmationData> 314 <saml2:SubjectConfirmation> 315 </saml2:Subject> 316 …. 317
<saml2:Statement> 318 … 319
</saml2:Statement> 320 321
oasis-wss–saml-2.0-token-profile-1.0saml-token-profile-1.1 175 MayJan 2005
Copyright © OASIS Open 2003-2005. All Rights Reserved. Page 12 of 3736
<saml2:Statement> 322 … 323
</saml2:Statement> 324 … 325 326 </saml2:Assertion> 327
3.2.3 Assertion URI Reference Replaces AuthorityBinding 328
SAML V1.1 defines the (deprecated) <saml:AuthorityBinding> element so that a 329
relying party can locate and communicate with an assertion authority to acquire a 330
referenced assertion. 331
The <saml:AuthorityBinding> element was removed from SAML V2.0. 332
[SAMLBindV2] requires that an assertion authority support a URL endpoint at which 333
an assertion will be returned in response to an HTTP request with a single query 334
string parameter named ID. 335
For example, if the documented endpoint at an assertion authority is: 336
https://saml.example.edu/assertion-authority 337
then the following request will cause the assertion with ID “abcde” to be returned: 338
https://saml.example.edu/assertion-authority?ID=abcde 339
3.2.4 Attesting Entity Identifier 340
The <saml2:SubjectConfirmation> element of SAML V2.0 provides for the optional 341
inclusion of an element (i.e., NameID) to identify the expected attesting entity as 342
distinct from the subject of the assertion. 343
<saml2:SubjectConfirmation 344 Method=”urn:oasis:names:tc:SAML:2.0:cm:sender-vouches”> 345 <NameID> 346 gateway 347 </NameID> 348 <saml2:SubjectConfirmationData> 349 Address=”129.148.9.42” 350 </saml2:SubjectConfirmationData> 351 </saml2:SubjectConfirmation> 352
3.3 Attaching Security Tokens 353
SAML assertions are attached to SOAP messages using WSS: SOAP Message Security 354
by placing assertion elements or references to assertions inside a <wsse:Security> 355
header. The following example illustrates a SOAP message containing a bearer 356
confirmed SAML V1.1 assertion in a <wsse:Security> header. 357
<S12:Envelope> 358 <S12:Header> 359 <wsse:Security> 360 361 <saml:Assertion 362 AssertionID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc" 363 IssueInstant="2003-04-17T00:46:02Z" 364
oasis-wss–saml-2.0-token-profile-1.0saml-token-profile-1.1 175 MayJan 2005
Copyright © OASIS Open 2003-2005. All Rights Reserved. Page 13 of 3736
Issuer=”www.opensaml.org” 365 MajorVersion="1" 366 MinorVersion="1" 367 . . . 368 <saml:AuthenticationStatement> 369 <saml:Subject> 370 <saml:NameIdentifier 371 NameQualifier="www.example.com" 372 Format="…"> 373 uid=joe,ou=people,ou=saml-demo,o=baltimore.com 374 </saml:NameIdentifier> 375 <saml:SubjectConfirmation> 376 <saml:ConfirmationMethod> 377 urn:oasis:names:tc:SAML:1.0:cm:bearer 378 </saml:ConfirmationMethod> 379 </saml:SubjectConfirmation> 380 </saml:Subject> 381 </saml:AuthenticationStatement> 382 383 </saml:Assertion> 384 385 <saml:Assertion 386 AssertionID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc" 387 IssueInstant="2003-04-17T00:46:02Z" 388 Issuer=”www.opensaml.org” 389 MajorVersion="1" 390 MinorVersion="1" 391 . . . 392 </saml:Assertion> 393 . . . 394
</wsse:Security> 395 396
397 </S12:Header> 398 <S12:Body> 399 . . . 400 </S12:Body> 401 </S12:Envelope> 402
3.4 Identifying and Referencing Security Tokens 403
The WSS: SOAP Message Security specification defines the 404
<wsse:SecurityTokenReference> element for referencing security tokens. Three 405
forms of token references are defined by this element and the element schema 406
includes provision for defining additional reference forms should they be necessary. 407
The three forms of token references defined by the 408
<wsse:SecurityTokenReference> element are defined as follows: 409
• A key identifier reference – a generic element (i.e. i.e., <wsse:KeyIdentifier>) 410
that conveys a security token identifier as an <wsse:EncodedString> and 411
indicates in its attributes (as necessary) the key identifier type (i.e. i.e., the 412
ValueType), the identifier encoding type (i.e. i.e., the EncodingType), and 413
perhaps other parameters used to reference the security token. 414
oasis-wss–saml-2.0-token-profile-1.0saml-token-profile-1.1 175 MayJan 2005
Copyright © OASIS Open 2003-2005. All Rights Reserved. Page 14 of 3836
When a key identifier is used to reference a SAML assertion, it MUST contain as 415
its element value the corresponding SAML assertion identifier. The key identifier 416
MUST also contain a ValueType attribute and the value of this attribute MUST be 417
the value from Table 2 corresponding to the version of the referenced assertion. 418
The key identifier MUST NOT include an EncodingType4 attribute and the element 419
content of the key identifier MUST be encoded as xsi:string. 420
When a key identifier is used to reference a V1.1 SAML assertion that is not 421
contained in the same message as the key identifier, a 422
<saml:AuthorityBinding> element MUST be contained in the 423
<wsse:SecurityTokenReference> element containing the key identifier. The 424
contents of the <saml:AuthorityBinding> element MUST contain values 425
sufficient for the intended recipients of the <wsse:SecurityTokenReference> to 426
acquire the identified assertion from the intended Authority. To this end, the 427
value of the AuthorityKind attribute of the <saml:AuthorityBinding> element 428
MUST be “samlp:AssertionIdReference”. 429
A key identifier MAY only be used to reference a SAML V2.0 assertion if the 430
assertion is contained in the same message as the key identifier. 431
When a key Identifier is used to reference a SAML assertion contained in the 432
same message as the key identifier, a <saml:AuthorityBinding> element MUST 433
NOT be included in the <wsse:SecurityTokenReference> containing the key 434
identifier. 435
A key identifier MAY only be used to reference a SAML V2.0 assertion if the 436
assertion is contained in the same message as the key identifier. 437
438
• A Direct or URI reference – a generic element (i.e. i.e., <wsse:Reference>) that 439
identifies a security token by URI. If only a fragment identifier is specified, then 440
the reference is to the security token within the document whose local identifier 441
(e.g., <wsu:Id> attribute) matches the fragment identifier. Otherwise, the 442
reference is to the (potentially external) security token identified by the URI. 443
A reference to a SAML V2.0 assertion that is NOT contained in the same message 444
MUST be a Direct or URI reference. In this case, tThe value of the URI attribute 445
must conform to the URI syntax defined in section 3.7.5.1 of [SAMLBindV2]. That 446
is, an HTTP or HTTPS request with a single query string parameter named ID. 447
The reference MUST also contain a wsse11:TokenValueType attribute and the 448
value of this attribute MUST be the value from Table 3 identifying the assertion 449
as a SAML V2.0 security token. When a Direct reference is made to a SAML V2.0 450
4 "The Errata for Web Services Security: SOAP Message Security Version 1.0" (at
http://www.oasis-open.org/committees/wss) removed the default designation from
the #Base64Binary value for the EncodingType attribute of the KeyIdentifier
element. Therefore, omitting a value for EncodingType and requiring that Base64
encoding not be performed, as specified by this profile, is consistent with the errata.
oasis-wss–saml-2.0-token-profile-1.0saml-token-profile-1.1 175 MayJan 2005
Copyright © OASIS Open 2003-2005. All Rights Reserved. Page 15 of 3836
Assertion, the Direct reference SHOULD NOT contain a ValueType attribute. 451
corresponding to the version of the referenced assertion. 452
This profile does not describe the use of Direct or URI references to reference 453
V1.1 SAML assertions. 454
• An Embedded reference – a reference that encapsulates a security token. 455
When an Embedded reference is used to encapsulate a SAML assertion, the SAML 456
assertion MUST be included as a contained element within a <wsse:Embedded> 457
element within a <wsse:SecurityTokenReference>. 458
This specification describes how SAML assertions may be referenced in four contexts: 459
• A SAML assertion may be referenced directly from a <wsse:Security> header 460
element. In this case, the assertion is being conveyed by reference in the 461
message. 462
• A SAML assertion may be referenced from a <ds:KeyInfo> element of a 463
<ds:Signature> element in a <wsse:Security> header. In this case, the 464
assertion contains a SubjectConfirmation element that identifies the key used 465
in the signature calculation. 466
• A SAML assertion reference may be referenced from a <ds:Reference> element 467
within the <ds:SignedInfo> element of a <ds:Signature> element in a 468
<wsse:Security> header. In this case, the doubly-referenced assertion is signed 469
by the containing signature. 470
• A SAML assertion reference may occur as encrypted content within an 471
<xenc:EncryptedData> element referenced from a <xenc:DataReference> 472
element within an <xenc:ReferenceList> element. In this case, the assertion 473
reference (which may contain an embedded assertion) is encrypted. 474
In each of these contexts, the referenced assertion may be: 475
• local – in which case, it is included in the <wsse:Security> header containing 476
the reference. 477
• remote – in which case it is not included in the <wsse:Security> header 478
containing the reference, but may occur in another part of the SOAP message or 479
may be available at the location identified by the reference which may be an 480
assertion authority. 481
A SAML key identifier references, MUST be used for all (local and remote) for local 482
references to SAML 1.1 and for remote references to V1.1 SAML assertions. All (local 483
and remote) references to SAML V2.0 assertions SHOULD be by Direct reference and 484
all rRemote references to V2.0 assertions MUST be by Direct reference URI. A key 485
identifier reference MAY be used to reference a local V2.0 assertion. 486
To maintain compatibility with Web Services Security: SOAP Message Security 1.0, 487
the practice of referencing local SAML 1.1 assertions by Direct 488
<wsse:SecurityTokenReference> reference is not included in this profile. 489
Every key identifier, direct, or embedded reference to a SAML assertion SHOULD 490
contain a wsse11:TokenType attribute and the value of this attribute MUST be the 491
oasis-wss–saml-2.0-token-profile-1.0saml-token-profile-1.1 175 MayJan 2005
Copyright © OASIS Open 2003-2005. All Rights Reserved. Page 16 of 3836
value from Table 3 that identifies the type and version of the referenced security 492
token. When the referenced assertion is a SAML V2.0 Assertion the reference MUST 493
contain a wsse11:TokenType attribute (as described above). The 1.1 version of this 494
profile will include the use of such references. 495
Assertion
Version Value
V1.1 http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID
V2.0 http://docs.oasis-open.org/wss/oasis-wss-saml-2.0-token-profile-1.0saml-token-profile-
1.1#SAMLID
Table-2 Key Identifier ValueType Attribute Values 496
Assertion
Version Value
V1.1 http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1
V2.0 http://docs.oasis-open.org/wss/oasis-wss-saml-2.0-token-profile-1.0saml-token-profile-
1.1#SAMLV2.0
Table-3 Direct Reference TokenValueType Attribute Values 497
The following subsjections define the SAML assertion references that MUST be 498
supported by conformant implementations of this profile. A compatible 499
implementation may choose to support the reference forms corresponding to either 500
or both V1.1 or V2.0 SAML assertions.These reference forms MUST be supported for 501
both SAML V1.1 and SAML v2.0 assertions. 502
3.4.1 SAML Assertion Referenced from Header or Element 503
All conformant implementations MUST be able to process SAML assertion references 504
occurring in a <wsse:Security> header or in a header element other than a 505
signature to acquire the corresponding assertion. A conformant implementation 506
MUST be able to process any such reference independent of the confirmation method 507
of the referenced assertion. 508
A SAML assertion may be referenced from a <wsse:Security> header or from an 509
element (other than a signature) in the header. The following example demonstrates 510
the use of a key identifier in a <wsse:Security> header to reference a local SAML 511
V1.1 assertion. 512
<S12:Envelope> 513 <S12:Header> 514 <wsse:Security> 515 <saml:Assertion 516 AssertionID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc" 517 IssueInstant="2003-04-17T00:46:02Z" 518
oasis-wss–saml-2.0-token-profile-1.0saml-token-profile-1.1 175 MayJan 2005
Copyright © OASIS Open 2003-2005. All Rights Reserved. Page 17 of 3836
Issuer=”www.opensaml.org” 519 MajorVersion="1" 520 MinorVersion="1" 521 . . . 522 </saml:Assertion> 523 <wsse:SecurityTokenReference wsu:Id=”STR1”> 524 wsse11:TokenType=”http://docs.oasis-open.org/wss/oasis-wss-525 saml-token-profile-1.1#SAMLV1.1”> 526 <wsse:KeyIdentifier wsu:Id=”…” 527 ValueType=”http://docs.oasis-open.org/wss/oasis-wss-saml-528 token-profile-1.0#SAMLAssertionID”> 529 _a75adf55-01d7-40cc-929f-dbd8372ebdfc 530 </wsse:KeyIdentifier> 531 </wsse:SecurityTokenReference> 532 </wsse:Security> 533 </S12:Header> 534 <S12:Body> 535 . . . 536 </S12:Body> 537 </S12:Envelope> 538
The following example depicts the use of form a key identifier reference to reference 539
a local SAML V2.0 assertion. 540
<wsse:SecurityTokenReference 541 wsu:Id=”STR1” 542
wsse11:TokenType=”http://docs.oasis-open.org/wss/oasis-wss-saml-543 token-profile-1.1#SAMLV2.0”> 544 <wsse:KeyIdentifier wsu:Id=”…” 545 ValueType=”http://docs.oasis-open.org/wss/oasis-wss-saml-2.0-546 token-profile-1.0saml-token-profile-1.1#SAMLID”> 547 _a75adf55-01d7-40cc-929f-dbd8372ebdfc 548 </wsse:KeyIdentifier> 549 </wsse:SecurityTokenReference> 550
A SAML V1.1 assertion that exists outside of a <wsse:Security> header may be 551
referenced from the <wsse:Security> header element by including (in the 552
<wsse:SecurityTokenReference>) a <saml:AuthorityBinding> element that 553
defines the location, binding, and query that may be used to acquire the identified 554
assertion at a SAML assertion authority or responder. 555
<wsse:SecurityTokenReference wsu:Id=”STR1” 556 wsse11:TokenType=”http://docs.oasis-open.org/wss/oasis-wss-saml-557 token-profile-1.1#SAMLV1.1”> 558 <saml:AuthorityBinding> 559 Binding=”urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding” 560 Location=”http://www.opensaml.org/SAML-Authority” 561 AuthorityKind= “samlp:AssertionIdReference” 562 </saml:AuthorityBinding> 563 <wsse:KeyIdentifier 564 wsu:Id=”…” 565 ValueType=”http://docs.oasis-open.org/wss/oasis-wss-saml-token-566 profile-1.0#SAMLAssertionID”> 567 _a75adf55-01d7-40cc-929f-dbd8372ebdfc 568 </wsse:KeyIdentifier> 569 </wsse:SecurityTokenReference> 570
The following example depicts the use of a Direct or URI reference to reference a 571
SAML V2.0 assertion that exists outside of a <wsse:Security> header. 572
oasis-wss–saml-2.0-token-profile-1.0saml-token-profile-1.1 175 MayJan 2005
Copyright © OASIS Open 2003-2005. All Rights Reserved. Page 18 of 3836
</wsse:SecurityTokenReference> 573 wsu:Id=”…” 574 wsse11:TokenType=”http://docs.oasis-open.org/wss/oasis-wss-saml-575 token-profile-1.1#SAMLV2.0”> 576 <wsse:Reference 577 wsu:Id=”…” 578 ValueType=”http://docs.oasis-open.org/wss/oasis-wss-saml-2.0-token-579 profile-1.0#SAMLV2.0” 580 URI=”https://saml.example.edu/assertion-authority?ID=abcde”> 581 </wsse:Reference> 582 </wsse:SecurityTokenReference> 583
3.4.2 SAML Assertion Referenced from KeyInfo 584
All conformant implementations MUST be able to process SAML assertion references 585
occurring in the <ds:KeyInfo> element of a <ds:Signature> element in a 586
<wsse:Security> header as defined by the holder-of-key confirmation method. 587
The following example depicts the use of a key identifier to reference a local V1.1 588
assertion from <ds:KeyInfo>. 589
<ds:KeyInfo> 590 <wsse:SecurityTokenReference wsu:Id=”STR1” 591 wsse11:TokenType=”http://docs.oasis-open.org/wss/oasis-wss-saml-592 token-profile-1.1#SAMLV1.1”>>> 593 <wsse:KeyIdentifier wsu:Id=”…” 594 ValueType=”http://docs.oasis-open.org/wss/oasis-wss-saml-token-595 profile-1.0#SAMLAssertionID”> 596 _a75adf55-01d7-40cc-929f-dbd8372ebdfc 597 </wsse:KeIdentifier> 598 </wsse:SecurityTokenReference> 599 </ds:KeyInfo> 600
A local, V2.0 assertion may beis referenced by replacing the values of the Key 601
Identifier ValueType and reference TokenType attributes with the values defined in 602
tables 2 and 3 (respectively) for SAML V2.0 (and repeated below)and (repeated 603
below): 604
wsse11:TokenType=”http://docs.oasis-open.org/wss/oasis-wss-saml-token-605 profile-1.1#SAMLV2.0” 606 ValueType=”http://docs.oasis-open.org/wss/oasis-wss-saml-2.0-token-607 profile-1.0saml-token-profile-1.1#SAMLID” 608
The following example demonstrates the use of a <wsse:SecurityTokenReference> 609
containing a key identifier and a <saml:AuthorityBinding> to communicate 610
information (location, binding, and query) sufficient to acquire the identified V1.1 611
assertion at an identified SAML assertion authority or responder. 612
<ds:KeyInfo> 613 <wsse:SecurityTokenReference wsu:Id=”STR1”> 614 wsse11:TokenType=”http://docs.oasis-open.org/wss/oasis-wss-saml-615 token-profile-1.1#SAMLV1.1”> 616 <saml:AuthorityBinding> 617 Binding=”urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding” 618 Location=”http://www.opensaml.org/SAML-Authority” 619 AuthorityKind= “samlp:AssertionIdReference” 620 </saml:AuthorityBinding> 621 <wsse:KeyIdentifier wsu:Id=”…” 622
oasis-wss–saml-2.0-token-profile-1.0saml-token-profile-1.1 175 MayJan 2005
Copyright © OASIS Open 2003-2005. All Rights Reserved. Page 19 of 3836
ValueType=”http://docs.oasis-open.org/wss/oasis-wss-saml-token-623 profile-1.0#SAMLAssertionID”> 624 _a75adf55-01d7-40cc-929f-dbd8372ebdfc 625 </wsse:KeyIdentifier> 626 </wsse:SecurityTokenReference> 627 </ds:KeyInfo> 628
Remote references to V2.0 assertions are made by Direct reference URI. The 629
following example depicts the use of a Direct reference URI to reference a remote 630
V2.0 assertion from <ds:KeyInfo>. 631
<ds:KeyInfo> 632 <wsse:SecurityTokenReference wsu:Id=”STR1” 633 wsu:id=”STR1” 634 wsse11:TokenType=”http://docs.oasis-open.org/wss/oasis-wss-saml-635 token-profile-1.1#SAMLV2.0”> 636 <wsse:Reference 637 wsu:id=”…” 638 ValueType=http://docs.oasis-open.org/wss/oasis-wss-saml-2.0-639 token-profile-1.0#SAMLV2.0 640 URI=”https://saml.example.edu/assertion-authority?ID=abcde”> 641 </wsse:Reference> 642 </wsse:SecurityTokenReference> 643 </ds:KeyInfo> 644
<ds:KeyInfo> elements may also occur in <xenc:EncryptedData> and 645
<xenc:EncryptedKey> elements where they serve to identify the encryption key. 646
<ds:KeyInfo> elements may also occur in SAML SubjectConfirmation elements 647
where they identify a key that MUST be demonstrated to confirm the subject of the 648
corresponding statement(s). 649
Conformant implementations of this profile are not required to process SAML 650
assertion references occurring within the <ds:keyInfo> elements within 651
<xenc:EncryptedData>, <xenc:EncryptedKey>, or SAML SubjectConfirmation 652
elements. 653
3.4.3 SAML Assertion Referenced from SignedInfo 654
Independent of the confirmation method of the referenced assertion, all conformant 655
implementations MUST be able to process SAML assertions referenced by 656
<wsse:SecurityTokenReference> from <ds:Reference> elements within the 657
<ds:SignedInfo> element of a <ds:Signature> element in a <wsse:Security> 658
header. Embedded references may be digested directly, thus effectively digesting the 659
encapsulated assertion. Other <wsse:SecurityTokenReference> forms must be 660
dereferenced for the referenced assertion to be digested. 661
The core specification, WSS: SOAP Message Security, defines the STR Dereference 662
transform to cause the replacement (in the digest stream) of a 663
<wsse:SecurityTokenReference> with the contents of the referenced token. The 664
STR Dereference transform MUST be specified and applied to digest any SAML 665
assertion that is referenced by a <wsse:SecurityTokenReference> that is not an 666
embedded reference. The STR Dereference transform SHOULD NOT be applied to an 667
embedded reference. 668
oasis-wss–saml-2.0-token-profile-1.0saml-token-profile-1.1 175 MayJan 2005
Copyright © OASIS Open 2003-2005. All Rights Reserved. Page 20 of 3836
The following example demonstrates the use of the STR Dereference transform to 669
dereference a reference to a SAML V1.1 Assertion (i.e. i.e., Security Token) such that 670
the digest operation is performed on the security token not its reference. 671
<wsse:SecurityTokenReference wsu:Id=”STR1”> 672 wsse11:TokenType=”http://docs.oasis-open.org/wss/oasis-wss-saml-673 token-profile-1.1#SAMLV1.1”> 674 <saml:AuthorityBinding> 675 Binding=”urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding” 676 Location=”http://www.opensaml.org/SAML-Authority” 677 AuthorityKind= “samlp:AssertionIdReference” 678 </saml:AuthorityBinding> 679 <wsse:KeyIdentifier wsu:Id=”…” 680 ValueType=”http://docs.oasis-open.org/wss/oasis-2004XX-wss-saml-681 token-profile-1.0#SAMLAssertionID”> 682 _a75adf55-01d7-40cc-929f-dbd8372ebdfc 683 </wsse:KeyIdentifier> 684 </wsse:SecurityTokenReference> 685 . . . 686 <ds:SignedInfo> 687 <ds:CanonicalizationMethod 688 Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> 689 <ds:SignatureMethod 690 Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> 691 <ds:Reference URI="#STR1"> 692 <Transforms> 693 <ds:Transform 694 Algorithm="http://docs.oasis-open.org/wss/2004/01/oasis-200401-695 wss-soap-message-security-1.0#STR-Transform”/> 696 <wsse:TransformationParameters> 697 <ds:CanonicalizationMethod 698 Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> 699 </wsse:TransformationParameters> 700 </ds:Transform> 701 </Transforms> 702 <ds:DigestMethod 703 Algorithm= "http://www.w3.org/2000/09/xmldsig#sha1"/> 704 705
<ds:DigestValue>...</ds:DigestValue> 706 </ds:Reference> 707 </ds:SignedInfo> 708
Note that the URI appearing in the <ds:Reference> element identifies the 709
<wsse:SecurityTokenReference> element by its wsu:Id value. Also note that the 710
STR Dereference transform MUST contain (in <wsse:TransformationParameters>) a 711
<ds:CanonicalizationMethod> that defines the algorithm to be used to serialize the 712
input node set (of the referenced assertion). 713
As depicted in the other examples of this section, this profile establishes 714
<wsse:SecurityTokenReference> forms for referencing V1.1, local V2.0, and 715
remote V2.0 assertions. 716
oasis-wss–saml-2.0-token-profile-1.0saml-token-profile-1.1 175 MayJan 2005
Copyright © OASIS Open 2003-2005. All Rights Reserved. Page 21 of 3836
3.4.4 SAML Assertion Referenced from Encrypted Data 717
Reference 718
Independent of the confirmation method of the referenced assertion, all conformant 719
implementations MUST be able to process SAML assertion references occurring as 720
encrypted content within the <xenc:EncryptedData> elements referenced by Id 721
from the <xenc:DataReference> elements of <xenc:ReferenceList> elements. An 722
<xenc:ReferenceList> element may occur either as a top-level element in a 723
Security header, or embedded within an <xenc:EncryptedKey> element. In either 724
case, the <xenc:ReferenceList> identifies the encrypted content. 725
Such references are similar in format to the references that MAY appear in the 726
<ds:Reference> element within <ds:SignedInfo>, except the STR Dereference 727
transform does not apply. As shown in the following example, an encrypted 728
<wsse:SecurityTokenReference> (which may contain an embedded assertion) is 729
referenced from an <xenc:DataReference> by including the identifier of the 730
<xenc:EncryptedData> element that contains the encrypted 731
<wsse:SecurityTokenReference> in the <xenc:DataReference>. 732
<xenc:EncryptedData Id=”EncryptedSTR1”> 733 <ds:keyInfo> 734 . . . 735 </ds:KeyInfo> 736 <xenc:CipherData> 737 <xenc:CipherValue>...</xenc:CipherValue> 738 </xenc:CipherData> 739 /xenc:EncryptedData> 740 <xenc:ReferenceList> 741 <xenc:DataReference URI="#EncryptedSTR1"/> 742 </xenc:ReferenceList> 743
3.5 Subject Confirmation of SAML Assertions 744
The SAML profile of WSS: SOAP Message Security requires that systems support the 745
holder-of-key and sender-vouches methods of subject confirmation. It is strongly 746
RECOMMENDED that an XML signature be used to establish the relationship between 747
the message and the statements of the attached assertions. This is especially 748
RECOMMENDED whenever the SOAP message exchange is conducted over an 749
unprotected transport. 750
Any processor of SAML assertions MUST conform to the required validation and 751
processing rules defined in the corresponding SAML specification including the 752
validation of assertion signatures, the processing of <saml:Condition> elements 753
within assertions, and the processing of <saml2:SubjectConfirmationData> 754
attributes. [SAMLCoreV1] defines the validation and processing rules for V1.1 755
assertions, while [SAMLCoreV2] is authoritative for V2.0 assertions. 756
The following table enumerates the mandatory subject confirmation methods and 757
summarizes their associated processing models: 758
Mechanism RECOMMENDED Processing
oasis-wss–saml-2.0-token-profile-1.0saml-token-profile-1.1 175 MayJan 2005
Copyright © OASIS Open 2003-2005. All Rights Reserved. Page 22 of 3836
Rules
urn:oasis:names:tc:SAML:1.0:cm:holder-
of-key
Or
urn:oasis:names:tc:SAML:2.0:cm:holder-
of-key
The attesting entity demonstrates
knowledge of a confirmation key
identified in a holder-of-key
SubjectConfirmation element
within the assertion.
urn:oasis:names:tc:SAML:1.0:cm:sender-
vouches
Or
urn:oasis:names:tc:SAML:2.0:cm:sender-
vouches
The attesting entity, (presumed to
be) different from the subject,
vouches for the verification of the
subject. The receiver MUST have an
existing trust relationship with the
attesting entity. The attesting entity
MUST protect the assertion in
combination with the message
content against modification by
another party. See also section 4.
Note that the high level processing model described in the following sections does 759
not differentiate between the attesting entity and the message sender as would be 760
necessary to guard against replay attacks. The high-level processing model also does 761
not take into account requirements for authentication of receiver by sender, or for 762
message or assertion confidentiality. These concerns must be addressed by means 763
other than those described in the high-level processing model (i.e. i.e., section 3.1). 764
3.5.1 Holder-of-key Subject Confirmation Method 765
The following sections describe the holder-of-key method of establishing the 766
correspondence between a SOAP message and the subject and claims of SAML 767
assertions added to the SOAP message according to this specification. 768
3.5.1.1 Attesting Entity 769
An attesting entity demonstrates that it is authorized to act as the subject of a 770
holder-of-key confirmed SAML statement by demonstrating knowledge of any key 771
identified in a holder-of-key SubjectConfirmation element associated with the 772
statement by the assertion containing the statement. Statements attested for by the 773
holder-of-key method MUST be associated, within their containing assertion, with 774
one or more holder-of-key SubjectConfirmation elements. 775
oasis-wss–saml-2.0-token-profile-1.0saml-token-profile-1.1 175 MayJan 2005
Copyright © OASIS Open 2003-2005. All Rights Reserved. Page 23 of 3836
The SubjectConfirmation elements MUST include a <ds:KeyInfo> element that 776
identifies a public or secret key5 that can be used to confirm the identity of the 777
subject. 778
To satisfy the associated confirmation method processing to be performed by the 779
message receiver, the attesting entity MUST demonstrate knowledge of the 780
confirmation key. The attesting entity MAY accomplish this by using the confirmation 781
key to sign content within the message and by including the resulting 782
<ds:Signature> element in the <wsse:Security> header. <ds:Signature> 783
elements produced for this purpose MUST conform to the canonicalization and 784
token pre-pending rules defined in the WSS: SOAP Message Security specification. 785
SAML assertions that contain a holder-of-key SubjectConfirmation element 786
SHOULD contain a <ds:Signature> element that protects the integrity of the 787
confirmation <ds:KeyInfo> established by the assertion authority. 788
The canonicalization method used to produce the <ds:Signature> elements used 789
to protect the integrity of SAML assertions MUST support the validation of these 790
<ds:Signature> elements in contexts (such as <wsse:Security> header elements) 791
other than those in which the signatures were calculated. 792
3.5.1.2 Receiver 793
Of the SAML assertions it selects for processing, a message receiver MUST NOT 794
accept statements of these assertions based on a holder-of-key 795
SubjectConfirmation element defined for the statements (within the assertion) 796
unless the receiver has validated the integrity of the assertion and the attesting 797
entity has demonstrated knowledge of a key identified within the confirmation 798
element. 799
If the receiver determines that the attesting entity has demonstrated knowledge of a 800
subject confirmation key, then the subjects and claims of the SAML statements 801
confirmed by the key MAY be attributed to the attesting entity and any content of the 802
message whose integrity is protected by the key MAY be considered to have been 803
provided by the attesting entity. 804
5[SAMLCoreV1] defines KeyInfo of SubjectConfirmation as containing a
“cryptographic key held by the subject”. Demonstration of this key is sufficient to
establish who is (or may act as the) subject. Moreover, since it cannot be proven
that a confirmation key is known (or known only) by the subject whose identity it
establishes, requiring that the key be held by the subject is an untestable
requirement that adds nothing to the strength of the confirmation mechanism. In
[SAMLCoreV2], the OASIS Security Services Technical Committee agreed to remove
the phrase “held by the subject” from the definition of KeyInfo within
SubjectConfirmation(Data).
oasis-wss–saml-2.0-token-profile-1.0saml-token-profile-1.1 175 MayJan 2005
Copyright © OASIS Open 2003-2005. All Rights Reserved. Page 24 of 3836
3.5.1.3 Example V1.1 805
The following example illustrates the use of the holder-of-key subject confirmation 806
method to establish the correspondence between the SOAP message and the subject 807
of statements of the SAML V1.1 assertions in the <wsse:Security> header: 808
<?xml:version="1.0" encoding="UTF-8"?> 809 <S12:Envelope> 810 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 811 xmlns:xsd="http://www.w3.org/2001/XMLSchema"> 812 <S12:Header> 813 814 <wsse:Security> 815 <saml:Assertion 816 AssertionID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc" 817 IssueInstant="2003-04-17T00:46:02Z" 818 Issuer=”www.opensaml.org” 819 MajorVersion="1" 820 MinorVersion="1" 821 xmlns="urn:oasis:names:tc:SAML:1.0:assertion"> 822 <saml:Conditions> 823 NotBefore="2002-06-19T16:53:33.173Z" 824 NotOnOrAfter="2002-06-19T17:08:33.173Z"/> 825 <saml:AttributeStatement> 826 <saml:Subject> 827 <saml:NameIdentifier 828 NameQualifier="www.example.com" 829 Format="…"> 830 uid=joe,ou=people,ou=saml-demo,o=baltimore.com 831 </saml:NameIdentifier> 832 <saml:SubjectConfirmation> 833 <saml:ConfirmationMethod> 834 urn:oasis:names:tc:SAML:1.0:cm:holder-of-key 835 </saml:ConfirmationMethod> 836 <ds:KeyInfo> 837 <ds:KeyValue>…</ds:KeyValue> 838 </ds:KeyInfo> 839 </saml:SubjectConfirmation> 840 </saml:Subject> 841 <saml:Attribute 842 AttributeName="MemberLevel" 843 AttributeNamespace="http://www.oasis.open. 844 org/Catalyst2002/attributes"> 845 <saml:AttributeValue>gold</saml:AttributeValue> 846 </saml:Attribute> 847 <saml:Attribute 848 AttributeName="E-mail" 849 AttributeNamespace="http://www.oasis.open. 850 org/Catalyst2002/attributes"> 851 <saml:AttributeValue>[email protected]</saml:AttributeValue> 852 </saml:Attribute> 853 </saml:AttributeStatement> 854 <ds:Signature>…</ds:Signature> 855 </saml:Assertion> 856 857 <ds:Signature> 858 <ds:SignedInfo> 859 <ds:CanonicalizationMethod 860 Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> 861
oasis-wss–saml-2.0-token-profile-1.0saml-token-profile-1.1 175 MayJan 2005
Copyright © OASIS Open 2003-2005. All Rights Reserved. Page 25 of 3836
<ds:SignatureMethod 862 Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> 863 <ds:Reference 864 URI="#MsgBody"> 865 <ds:DigestMethod 866 Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> 867 <ds:DigestValue>GyGsF0Pi4xPU...</ds:DigestValue> 868 </ds:Reference> 869 </ds:SignedInfo> 870 <ds:SignatureValue>HJJWbvqW9E84vJVQk…</ds:SignatureValue> 871 <ds:KeyInfo> 872 <wsse:SecurityTokenReference wsu:Id=”STR1”> 873 wsse11:TokenType=”http://docs.oasis-open.org/wss/oasis-wss-874 saml-token-profile-1.1#SAMLV1.1”> 875 <wsse:KeyIdentifier wsu:Id=”…” 876 ValueType=”http://docs.oasis-open.org/wss/oasis-wss-saml-877 token-profile-1.0#SAMLAssertionID”> 878 _a75adf55-01d7-40cc-929f-dbd8372ebdfc 879 </wsse:KeyIdentifier> 880 </wsse:SecurityTokenReference> 881 </ds:KeyInfo> 882 </ds:Signature> 883 </wsse:Security> 884 </S12:Header> 885 886 <S12:Body wsu:Id="MsgBody"> 887 <ReportRequest> 888 <TickerSymbol>SUNW</TickerSymbol> 889 </ReportRequest> 890 </S12:Body> 891 </S12:Envelope> 892
3.5.1.4 Example V2.0 893
The following example illustrates the use of the holder-of-key subject confirmation 894
method to establish the correspondence between the SOAP message and the subject 895
of the SAML V2.0 assertion in the <wsse:Security> header: 896
<?xml:version="1.0" encoding="UTF-8"?> 897 <S12:Envelope> 898 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 899 xmlns:xsd="http://www.w3.org/2001/XMLSchema"> 900 <S12:Header> 901 902 <wsse:Security> 903 <saml2:Assertion 904 … 905 ID=”_a75adf55-01d7-40cc-929f-dbd8372ebdfc” 906 …> 907 <saml2:subject> 908 <saml2:NameID> 909 … 910 </saml2:NameID> 911 <saml2:SubjectConfirmation 912 Method=”urn:oasis:names:tc:SAML:2.0:cm:holder-of-key”> 913 <saml2:KeyInfoSubjectConfirmationData> 914 <ds:KeyInfo> 915 <ds:KeyValue>…</ds:KeyValue> 916
oasis-wss–saml-2.0-token-profile-1.0saml-token-profile-1.1 175 MayJan 2005
Copyright © OASIS Open 2003-2005. All Rights Reserved. Page 26 of 3836
</ds:KeyInfo> 917 </saml2:KeyInfoSubjectConfirmationData> 918 <saml2:SubjectConfirmation> 919 </saml2:Subject> 920 <saml2:Statement> 921 … 922 </saml2:Statement> 923 <ds:Signature>…</ds:Signature> 924 </saml2:Assertion> 925 926 <ds:Signature> 927 <ds:SignedInfo> 928 <ds:CanonicalizationMethod 929 Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> 930 <ds:SignatureMethod 931 Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> 932 <ds:Reference 933 URI="#MsgBody"> 934 <ds:DigestMethod 935 Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> 936 <ds:DigestValue>GyGsF0Pi4xPU...</ds:DigestValue> 937 </ds:Reference> 938 </ds:SignedInfo> 939 <ds:SignatureValue>HJJWbvqW9E84vJVQk…</ds:SignatureValue> 940 <ds:KeyInfo> 941 <wsse:SecurityTokenReference wsu:Id=”STR1” 942 wsse11:TokenType=”http://docs.oasis-open.org/wss/oasis-wss-943 saml-token-profile-1.1#SAMLV2.0”> 944 <wsse:KeyIdentifier wsu:Id=”…” 945 ValueType=”http://docs.oasis-open.org/wss/oasis-wss-saml-946 2.0-token-profile-1.0saml-token-profile-1.1#SAMLID”> 947 _a75adf55-01d7-40cc-929f-dbd8372ebdfc 948 </wsse:KeyIdentifier> 949 </wsse:SecurityTokenReference> 950 </ds:KeyInfo> 951 </ds:Signature> 952 </wsse:Security> 953 </S12:Header> 954 955 <S12:Body wsu:Id="MsgBody"> 956 <ReportRequest> 957 <TickerSymbol>SUNW</TickerSymbol> 958 </ReportRequest> 959 </S12:Body> 960 </S12:Envelope> 961
3.5.2 Sender-vouches Subject Confirmation Method 962
The following sections describe the sender-vouches method of establishing the 963
correspondence between a SOAP message and the SAML assertions added to the 964
SOAP message according to the SAML profile of WSS: SOAP Message Security. 965
3.5.2.1 Attesting Entity 966
An attesting entity uses the sender-vouches confirmation method to assert that it is 967
acting on behalf of the subject of SAML statements attributed with a sender-vouches 968
oasis-wss–saml-2.0-token-profile-1.0saml-token-profile-1.1 175 MayJan 2005
Copyright © OASIS Open 2003-2005. All Rights Reserved. Page 27 of 3836
SubjectConfirmation element. Statements attested for by the sender-vouches 969
method MUST be associated, within their containing assertion, with one or more 970
sender-vouches SubjectConfirmation elements. 971
To satisfy the associated confirmation method processing of the receiver, the 972
attesting entity MUST protect the vouched for SOAP message content such that the 973
receiver can determine when it has been altered by another party. The attesting 974
entity MUST also cause the vouched for statements (as necessary) and their binding 975
to the message contents to be protected such that unauthorized modification can be 976
detected. The attesting entity MAY satisfy these requirements by including in the 977
corresponding <wsse:Security> header a <ds:Signature> element that it prepares 978
by using its key to sign the relevant message content and assertions. As defined by 979
the XML Signature specification, the attesting entity MAY identify its key by including 980
a <ds:KeyInfo> element within the <ds:Signature> element. 981
A <ds:Signature> element produced for this purpose MUST conform to the 982
canonicalization and token pre-pending rules defined in the WSS: SOAP Message 983
Security specification. 984
3.5.2.2 Receiver 985
Of the SAML assertions it selects for processing, a message receiver MUST NOT 986
accept statements of these assertions based on a sender-vouches 987
SubjectConfirmation element defined for the statements (within the assertion) 988
unless the assertions and SOAP message content being vouched for are protected 989
(as described above) by an attesting entity who is trusted by the receiver to act as 990
the subjects and with the claims of the statements. 991
3.5.2.3 Example V1.1 992
The following example illustrates an attesting entity’s use of the sender-vouches 993
subject confirmation method with an associated <ds:Signature> element to 994
establish its identity and to assert that it has sent the message body on behalf of the 995
subject(s) of the V1.1 assertion referenced by “STR1”. 996
The assertion referenced by “STR1” is not included in the message. “STR1” is 997
referenced by <ds:reference> from <ds:SignedInfo>. The ds:reference> 998
includes the STR-transform to cause the assertion, not the 999
<SecurityTokeReference> to be included in the digest calculation. “STR1” includes a 1000
<saml:AuthorityBinding> element that utilizes the remote assertion referencing 1001
technique depicted in the example of section 3.3.3. 1002
The SAML V1.1 assertion embedded in the header and referenced by “STR2” from 1003
<ds:KeyInfo> corresponds to the attesting entity. The private key corresponding to 1004
the public confirmation key occurring in the assertion is used to sign together the 1005
message body and assertion referenced by “STRI”. 1006
<?xml:version="1.0" encoding="UTF-8"?> 1007 <S12:Envelope> 1008 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 1009 xmlns:xsd="http://www.w3.org/2001/XMLSchema"> 1010 <S12:Header> 1011
oasis-wss–saml-2.0-token-profile-1.0saml-token-profile-1.1 175 MayJan 2005
Copyright © OASIS Open 2003-2005. All Rights Reserved. Page 28 of 3836
<wsse:Security> 1012 1013 <saml:Assertion 1014 AssertionID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc" 1015 IssueInstant="2003-04-17T00:46:02Z" 1016 Issuer=”www.opensaml.org” 1017 MajorVersion="1" 1018 MinorVersion="1" 1019 xmlns="urn:oasis:names:tc:SAML:1.0:assertion"> 1020 <saml:Conditions> 1021 NotBefore="2002-06-19T16:53:33.173Z" 1022 NotOnOrAfter="2002-06-19T17:08:33.173Z"/> 1023 <saml:AttributeStatement> 1024 <saml:Subject> 1025 <saml:NameIdentifier 1026 NameQualifier="www.example.com" 1027 Format="…"> 1028 uid=proxy,ou=system,ou=saml-demo,o=baltimore.com 1029 </saml:NameIdentifier> 1030 <saml:SubjectConfirmation> 1031 <saml:ConfirmationMethod> 1032 urn:oasis:names:tc:SAML:1.0:cm:holder-of-key 1033 </saml:ConfirmationMethod> 1034 <ds:KeyInfo> 1035 <ds:KeyValue>…</ds:KeyValue> 1036 </ds:KeyInfo> 1037 </saml:SubjectConfirmation> 1038 </saml:Subject> 1039 <saml:Attribute 1040 . . . 1041 </saml:Attribute> 1042 . . . 1043 </saml:AttributeStatement> 1044 </saml:Assertion> 1045 1046 <wsse:SecurityTokenReference wsu:Id=”STR1”> 1047 wsse11:TokenType=”http://docs.oasis-open.org/wss/oasis-wss-1048 saml-token-profile-1.1#SAMLV1.1”> 1049 <saml:AuthorityBinding> 1050 saml:Binding=”urn:oasis:names:tc:SAML:1.0:bindings:SOAP-1051 binding” 1052 saml:Location=”http://www.opensaml.org/SAML-Authority” 1053 saml:AuthorityKind= “samlp:AssertionIdReference” 1054 </saml:AuthorityBinding> 1055 <wsse:KeyIdentifier wsu:Id=”…” 1056 ValueType=”http://docs.oasis-open.org/wss/oasis-wss-saml-1057 token-profile-1.0#SAMLAssertionID”> 1058 _a75adf55-01d7-40cc-929f-dbd8372ebdbe 1059 </wsse:KeyIdentifier> 1060 </wsse:SecurityTokenReference> 1061 1062 <ds:Signature> 1063 <ds:SignedInfo> 1064 <ds:CanonicalizationMethod 1065 Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> 1066 <ds:SignatureMethod 1067 Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> 1068 <ds:Reference URI="#STR1"> 1069 <Transforms> 1070
oasis-wss–saml-2.0-token-profile-1.0saml-token-profile-1.1 175 MayJan 2005
Copyright © OASIS Open 2003-2005. All Rights Reserved. Page 29 of 3836
<ds:Transform 1071 1072
Algorithm="http://docs.oasis-open.org/wss/2004/01/oasis-1073 200401-wss-soap-message-security-1.0#STR-Transform"/> 1074 <wsse:TransformationParameters> 1075 <ds:CanonicalizationMethod 1076 Algorithm="http://www.w3.org/2001/10/xml-exc-1077 c14n#"/> 1078 </wsse:TransformationParameters> 1079 </ds:Transform> 1080 </Transforms> 1081 <ds:DigestMethod 1082 Algorithm= "http://www.w3.org/2000/09/xmldsig#sha1"/> 1083 <ds:DigestValue>...</ds:DigestValue> 1084 </ds:Reference> 1085 <ds:Reference URI="#MsgBody"> 1086 <ds:DigestMethod 1087 Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> 1088 <ds:DigestValue>...</ds:DigestValue> 1089 </ds:Reference> 1090 </ds:SignedInfo> 1091 <ds:SignatureValue>HJJWbvqW9E84vJVQk…</ds:SignatureValue> 1092 <ds:KeyInfo> 1093 <wsse:SecurityTokenReference wsu:Id=”STR2” 1094 wsse11:TokenType=”http://docs.oasis-open.org/wss/oasis-wss-1095 saml-token-profile-1.1#SAMLV1.1”>> 1096 <wsse:KeyIdentifier wsu:Id=”…” 1097 ValueType=”http://docs.oasis-open.org/wss/oasis-wss-saml-1098 token-profile-1.0#SAMLAssertionID-1.1”> 1099 _a75adf55-01d7-40cc-929f-dbd8372ebdfc 1100 </wsse:KeyIdentifier> 1101 </wsse:SecurityTokenReference> 1102 </ds:KeyInfo> 1103 </ds:Signature> 1104 </wsse:Security> 1105 </S12:Header> 1106 1107 <S12:Body wsu:Id="MsgBody"> 1108 <ReportRequest> 1109 <TickerSymbol>SUNW</TickerSymbol> 1110 </ReportRequest> 1111 </S12:Body> 1112 </S12:Envelope> 1113
3.5.2.4 Example V2.0 1114
The following example illustrates the mapping of the preceding example to SAML 1115
V2.0 assertions. 1116
<?xml:version="1.0" encoding="UTF-8"?> 1117 <S12:Envelope> 1118 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 1119 xmlns:xsd="http://www.w3.org/2001/XMLSchema"> 1120 <S12:Header> 1121 1122 <wsse:Security> 1123 <saml2:Assertion 1124 … 1125 ID=”_a75adf55-01d7-40cc-929f-dbd8372ebdfc” 1126
oasis-wss–saml-2.0-token-profile-1.0saml-token-profile-1.1 175 MayJan 2005
Copyright © OASIS Open 2003-2005. All Rights Reserved. Page 30 of 3836
…> 1127 <saml2:subject> 1128 <saml2:NameID> 1129 … 1130 </saml2:NameID> 1131 <saml2:SubjectConfirmation 1132 Method=”urn:oasis:names:tc:SAML:2.0:cm:holder-of-key”> 1133 <saml2:KeyInfoSubjectConfirmationData> 1134 <ds:KeyInfo> 1135 <ds:KeyValue>…</ds:KeyValue> 1136 </ds:KeyInfo> 1137 </saml2:KeyInfoSubjectConfirmationData> 1138 <saml2:SubjectConfirmation> 1139 </saml2:Subject> 1140 <saml2:Statement> 1141 … 1142 </saml2:Statement> 1143 <ds:Signature>…</ds:Signature> 1144 </saml2:Assertion> 1145 1146 <wsse:SecurityTokenReference wsu:Id=”STR1”> 1147 wsse11:TokenType=”http://docs.oasis-open.org/wss/oasis-wss-1148 saml-token-profile-1.1#SAMLV2.0”> 1149 <wsse:Reference wsu:Id=”…” 1150 ValueType=”http://docs.oasis-open.org/wss/oasis-wss-saml-2.0-1151 token-profile-1.0#SAMLV2.0” 1152 URI=”https://www.opensaml.org?_a75adf55-01d7-40cc-929f-1153 dbd8372ebdbe”> 1154 </wsse:Reference> 1155 </wsse:SecurityTokenReference> 1156 1157 <ds:Signature> 1158 <ds:SignedInfo> 1159 <ds:CanonicalizationMethod 1160 Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> 1161 <ds:SignatureMethod 1162 Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> 1163 <ds:Reference URI="#STR1"> 1164 <Transforms> 1165 <ds:Transform 1166 1167
Algorithm="http://docs.oasis-open.org/wss/2004/01/oasis-1168 200401-wss-soap-message-security-1.0#STR-Transform"/> 1169 <wsse:TransformationParameters> 1170 <ds:CanonicalizationMethod 1171 Algorithm="http://www.w3.org/2001/10/xml-exc-1172 c14n#"/> 1173 </wsse:TransformationParameters> 1174 </ds:Transform> 1175 </Transforms> 1176 <ds:DigestMethod 1177 Algorithm= "http://www.w3.org/2000/09/xmldsig#sha1"/> 1178 <ds:DigestValue>...</ds:DigestValue> 1179 </ds:Reference> 1180 <ds:Reference URI="#MsgBody"> 1181 <ds:DigestMethod 1182 Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> 1183 <ds:DigestValue>...</ds:DigestValue> 1184 </ds:Reference> 1185
oasis-wss–saml-2.0-token-profile-1.0saml-token-profile-1.1 175 MayJan 2005
Copyright © OASIS Open 2003-2005. All Rights Reserved. Page 31 of 3836
</ds:SignedInfo> 1186 <ds:SignatureValue>HJJWbvqW9E84vJVQk…</ds:SignatureValue> 1187 <ds:KeyInfo> 1188 <wsse:SecurityTokenReference wsu:Id=”STR2”> 1189 wsse11:TokenType=”http://docs.oasis-open.org/wss/oasis-wss-1190 saml-token-profile-1.1#SAMLV2.0”> 1191 <wsse:KeyIdentifier wsu:Id=”…” 1192 ValueType=”http://docs.oasis-open.org/wss/oasis-wss-saml-1193 2.0-token-profile-1.0saml-token-profile-1.1#SAMLID”> 1194 _a75adf55-01d7-40cc-929f-dbd8372ebdfc 1195 </wsse:KeyIdentifier> 1196 </wsse:SecurityTokenReference> 1197 </ds:KeyInfo> 1198 </ds:Signature> 1199 </wsse:Security> 1200 </S12:Header> 1201 1202 <S12:Body wsu:Id="MsgBody"> 1203 <ReportRequest> 1204 <TickerSymbol>SUNW</TickerSymbol> 1205 </ReportRequest> 1206 </S12:Body> 1207 </S12:Envelope> 1208
3.6 Error Codes 1209
When a system that implements the SAML token profile of WSS: SOAP Message 1210
Security does not perform its normal processing because of an error detected during 1211
the processing of a security header, it MAY choose to report the cause of the error 1212
using the SOAP fault mechanism. The SAML token profile of WSS: SOAP Message 1213
Security does not require that SOAP faults be returned for such errors, and systems 1214
that choose to return faults SHOULD take care not to introduce any security 1215
vulnerabilities as a result of the information returned in error responses. 1216
Systems that choose to return faults SHOULD respond with the error codes and fault 1217
strings defined in the WSS: SOAP Message Security specification. The 1218
RECOMMENDED correspondence between the common assertion processing failures 1219
and the error codes defined in WSS: SOAP Message Security are defined in the 1220
following table: 1221
Assertion Processing Error RECOMMENDED Error(Faultcode)
A referenced SAML assertion could not be
retrieved.
wsse:SecurityTokenUnavailable
An assertion contains a <saml:Condition>
element that the receiver does not
understand.
wsse:UnsupportedSecurityToken
A signature within an assertion or referencing
an assertion is invalid.
wsse:FailedCheck
oasis-wss–saml-2.0-token-profile-1.0saml-token-profile-1.1 175 MayJan 2005
Copyright © OASIS Open 2003-2005. All Rights Reserved. Page 32 of 3836
The issuer of an assertion is not acceptable to
the receiver.
wsse:InvalidSecurityToken
The receiver does not understand the
extension schema used in an assertion.
wsse:UnsupportedSecurityToken
The preceding table defines fault codes in a form suitable for use with SOAP 1.1. The 1222
WSS: SOAP Message Security specification describes how to map SOAP 1.1 fault 1223
constructs to the SOAP 1.2 fault constructs. 1224
oasis-wss–saml-2.0-token-profile-1.0saml-token-profile-1.1 175 MayJan 2005
Copyright © OASIS Open 2003-2005. All Rights Reserved. Page 33 of 3836
4 Threat Model and Countermeasures 1225
(non-normative) 1226
This document defines the mechanisms and procedures for securely attaching SAML 1227
assertions to SOAP messages. SOAP messages are used in multiple contexts, 1228
specifically including cases where the message is transported without an active 1229
session, the message is persisted, or the message is routed through a number of 1230
intermediaries. Such a general context of use suggests that users of this profile must 1231
be concerned with a variety of threats. 1232
In general, the use of SAML assertions with WSS: SOAP Message Security introduces 1233
no new threats beyond those identified for SAML or by the WSS: SOAP Message 1234
Security specification. The following sections provide an overview of the 1235
characteristics of the threat model, and the countermeasures that SHOULD be 1236
adopted for each perceived threat. 1237
4.1 Eavesdropping 1238
Eavesdropping is a threat to the SAML token profile of WSS: SOAP Message Security 1239
in the same manner as it is a threat to any network protocol. The routing of SOAP 1240
messages through intermediaries increases the potential incidences of 1241
eavesdropping. Additional opportunities for eavesdropping exist when SOAP 1242
messages are persisted. 1243
To provide maximum protection from eavesdropping, assertions, assertion 1244
references, and sensitive message content SHOULD be encrypted such that only the 1245
intended audiences can view their content. This approach removes threats of 1246
eavesdropping in transit, but MAY not remove risks associated with storage or poor 1247
handling by the receiver. 1248
Transport-layer security MAY be used to protect the message and contained SAML 1249
assertions and/or references from eavesdropping while in transport, but message 1250
content MUST be encrypted above the transport if it is to be protected from 1251
eavesdropping by intermediaries. 1252
4.2 Replay 1253
Reliance on authority protected (e.g. e.g., signed) assertions with a holder-of-key 1254
subject confirmation mechanism precludes all but a holder of the key from binding 1255
the assertions to a SOAP message. Although this mechanism effectively restricts 1256
data origin to a holder of the confirmation key, it does not, by itself, provide the 1257
means to detect the capture and resubmission of the message by other parties. 1258
Assertions that contain a sender-vouches confirmation mechanism introduce another 1259
dimension to replay vulnerability if the assertions impose no restriction on the 1260
entities that may use or reuse the assertions. 1261
oasis-wss–saml-2.0-token-profile-1.0saml-token-profile-1.1 175 MayJan 2005
Copyright © OASIS Open 2003-2005. All Rights Reserved. Page 34 of 3836
Replay attacks can be detected by receivers if message senders include additional 1262
message identifying information (e.g. e.g., timestamps, nonces, and or recipient 1263
identifiers) within origin protected message content and receivers check this 1264
information against previously received values. 1265
4.3 Message Insertion 1266
The SAML token profile of WSS: SOAP Message Security is not vulnerable to 1267
message insertion attacks. 1268
4.4 Message Deletion 1269
The SAML token profile of WSS: SOAP Message Security is not vulnerable to 1270
message deletion attacks. 1271
4.5 Message Modification 1272
Messages constructed according to this specification are protected from message 1273
modification if receivers can detect unauthorized modification of relevant message 1274
content. Therefore, it is strongly RECOMMENDED that all relevant and immutable 1275
message content be signed by an attesting entity. Receivers SHOULD only consider 1276
the correspondence between the subject of the SAML assertions and the SOAP 1277
message content to have been established for those portions of the message that are 1278
protected by the attesting entity against modification by another entity. 1279
To ensure that message receivers can have confidence that received assertions have 1280
not been forged or altered since their issuance, SAML assertions appearing in or 1281
referenced from <wsse:Security> header elements MUST be protected against 1282
unauthorized modification (e.g. e.g., signed) by their issuing authority or the 1283
attesting entity (as the case warrants). It is strongly RECOMMENDED that an 1284
attesting entity sign any <saml:Assertion> elements that it is attesting for and that 1285
are not signed by their issuing authority. 1286
Transport-layer security MAY be used to protect the message and contained SAML 1287
assertions and/or assertion references from modification while in transport, but 1288
signatures are required to extend such protection through intermediaries. 1289
4.6 Man-in-the-Middle 1290
Assertions with a holder-of-key subject confirmation method are not vulnerable to a 1291
MITM attack. Assertions with a sender-vouches subject confirmation method are 1292
vulnerable to MITM attacks to the degree that the receiver does not have a trusted 1293
binding of key to the attesting entity’s identity. 1294
oasis-wss–saml-2.0-token-profile-1.0saml-token-profile-1.1 175 MayJan 2005
Copyright © OASIS Open 2003-2005. All Rights Reserved. Page 35 of 3836
5 References 1295
[GLOSSARY] Informational RFC 2828, "Internet Security Glossary," May 1296
2000. 1297
[KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate Requirement 1298 Levels," RFC 2119, Harvard University, March 1997 1299
[SAMLBindV1] Oasis StandardCommittee Specification 01, E. Maler, P.Mishra, 1300
and R. Philpott (Editors), Bindings and Profiles for the OASIS 1301
Security Assertion Markup Language (SAML) V1.1, September 1302
2003. 1303
[SAMLBindV2] Oasis StandardCommittee Draft 02, S. Cantor, F. Hirsch, J. 1304
Kemp, R. Philpott, E. Maler (Editors), Bindings for the OASIS 1305
Security Assertion Markup Language (SAML) V2.0, 1306
MarchSeptember 20054. 1307
[SAMLCoreV1] Oasis StandardCommittee Specification 01, E. Maler, P.Mishra, 1308
and R. Philpott (Editors), Assertions and Protocols for the 1309
OASIS Security Assertion Markup Language (SAML) V1.1, 1310 September 2003. 1311
[SAMLCoreV2] Oasis StandardCommittee Draft 02, S. Cantor, J. Kemp, R. 1312
Philpott, E. Maler (Editors), Assertions and Protocol for the 1313
OASIS Security Assertion Markup Language (SAML) V2.0, 1314 MarchSeptember 20054. 1315
[SOAP] W3C Note, "SOAP: Simple Object Access Protocol 1.1," 08 May 1316 2000. 1317
W3C Working Draft, Nilo Mitra (Editor), SOAP Version 1.2 Part 1318
0: Primer, June 2002. 1319
W3C Working Draft, Martin Gudgin, Marc Hadley, Noah 1320
Mendelsohn, Jean-Jacques Moreau, Henrik Frystyk Nielsen 1321
(Editors), SOAP Version 1.2 Part 1: Messaging Framework, June 1322 2002. 1323
W3C Working Draft, Martin Gudgin, Marc Hadley, Noah 1324
Mendelsohn, Jean-Jacques Moreau, Henrik Frystyk Nielsen 1325 (Editors), SOAP Version 1.2 Part 2: Adjuncts, June 2002. 1326
[URI] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource 1327
Identifiers (URI): Generic Syntax," RFC 2396, MIT/LCS, U.C. 1328 Irvine, Xerox Corporation, August 1998. 1329
[WS-SAML] Contribution to the WSS TC, P. Mishra (Editor), WS-Security 1330
Profile of the Security Assertion Markup Language (SAML) 1331 Working Draft 04, Sept 2002. 1332
oasis-wss–saml-2.0-token-profile-1.0saml-token-profile-1.1 175 MayJan 2005
Copyright © OASIS Open 2003-2005. All Rights Reserved. Page 36 of 3936
[WSS: SAML Token Profile] Oasis Standard, P. Hallem-Baker, A. Nadalin, C. 1333
Kaler, R. Monzillo (Editors), Web Services Security: SAML 1334
Token Profile 1.0, December 2004. 1335
[WSS: SOAP Message Security] Oasis Standard, A. Nadalin, C.Kaler, P. 1336
Hallem-Baker, R. Monzillo (Editors), Web Services Security: 1337 SOAP Message Security 1.0 (WS-Security 2004), August 2003. 1338
[XML-ns] W3C Recommendation, "Namespaces in XML," 14 January 1339 1999. 1340
[XML Signature] W3C Recommendation, "XML Signature Syntax and 1341
Processing," 12 February 2002. 1342
[XML Token] Contribution to the WSS TC, Chris Kaler (Editor), 1343
WS-Security Profile for XML-based Tokens, August 2002. 1344
oasis-wss–saml-2.0-token-profile-1.0saml-token-profile-1.1 175 MayJan 2005
Copyright © OASIS Open 2003-2005. All Rights Reserved. Page 37 of 3836
Appendix A: Revision History 1345
Rev Date What
00 07-Oct-04 Initial draft produced from cd-03 of version 1.0
of the profile. Version 1.1 was created to add
support for SAML V2.0 Assertions.
01 19-Jan-05 Expert group draft submitted to TC.
02 17-May-2005 1. Designated as V1.1 profile.
2. Incorporated resolution to issue 250 (which
created the TokenType attribute).
3. Began transition of compatibility
requirements to allow an implementation to
support V1.1, V2.0, or both versions of
SAML assertions.
4. Added footnote to clarify processing of
bearer confirmation mechanism, and also
depicted use of bearer in example.
oasis-wss–saml-2.0-token-profile-1.0saml-token-profile-1.1 175 MayJan 2005
Copyright © OASIS Open 2003-2005. All Rights Reserved. Page 38 of 3836
Appendix B: Notices 1346
OASIS takes no position regarding the validity or scope of any intellectual property 1347
or other rights that might be claimed to pertain to the implementation or use of the 1348
technology described in this document or the extent to which any license under such 1349
rights might or might not be available; neither does it represent that it has made any 1350
effort to identify any such rights. Information on OASIS's procedures with respect to 1351
rights in OASIS specifications can be found at the OASIS website. Copies of claims of 1352
rights made available for publication and any assurances of licenses to be made 1353
available, or the result of an attempt made to obtain a general license or permission 1354
for the use of such proprietary rights by implementors or users of this specification, 1355
can be obtained from the OASIS Executive Director. 1356
OASIS invites any interested party to bring to its attention any copyrights, patents or 1357
patent applications, or other proprietary rights which may cover technology that may 1358
be required to implement this specification. Please address the information to the 1359
OASIS Executive Director. 1360
Copyright © OASIS Open 2003-2004. All Rights Reserved. 1361
This document and translations of it may be copied and furnished to others, and 1362
derivative works that comment on or otherwise explain it or assist in its 1363
implementation may be prepared, copied, published and distributed, in whole or in 1364
part, without restriction of any kind, provided that the above copyright notice and 1365
this paragraph are included on all such copies and derivative works. However, this 1366
document itself does not be modified in any way, such as by removing the copyright 1367
notice or references to OASIS, except as needed for the purpose of developing 1368
OASIS specifications, in which case the procedures for copyrights defined in the 1369
OASIS Intellectual Property Rights document must be followed, or as required to 1370
translate it into languages other than English. 1371
The limited permissions granted above are perpetual and will not be revoked by 1372
OASIS or its successors or assigns. 1373
This document and the information contained herein is provided on an “AS IS” basis 1374
and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 1375
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 1376
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1377
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1378
Top Related