OASIS Specification Template

2WS-SecurityPolicy Examples

3Working Draft 17, 16 October 2007

4Specification URIs: 5This Version: 6 http://docs.oasis-open.org/ws-sx/ws-sp-usecases-examples-draft-17-03.doc 7Previous Version: 8 http://docs.oasis-open.org/ws-sx/ws-sp-usecases-examples-draft-16-01.doc 9Latest Version: 10 http://docs.oasis-open.org/ws-sx/ws-sp-usecases-examples-draft-17-03.doc 11Latest Approved Version: 12 13Technical Committee: 14 OASIS Web Services Secure Exchange TC 15Chair(s): 16 Kelvin Lawrence, IBM 17 Chris Kaler, Microsoft 18Editor(s): 19 Rich Levinson, Oracle Corporation 20 Tony Gullotta, SOA Software Inc. 21 Symon Chang, BEA Systems Inc. 22 Martin Raepple, SAP AG 23Related work: 24 N/A 25Declared XML Namespace(s): 26 27Abstract: 28 This document contains examples of how to set up WS-SecurityPolicy [WSSP] policies for a 29 variety of common token types that are described in WS-Security 1.0 [WSS10] and WS-Security 30 1.1 [WSS11] token profiles [WSSTC]. Particular attention is focused on the different “security 31 bindings” (defined in [WSSP]) within the example policies. Actual messages that have been 32 documented in WS-Security TC [WSSTC]and other WS-Security-based Interops 33 [WSSINTEROPS, WSSXINTEROPS, OTHERINTEROPS] that conform to some of the example 34 policies are referenced when appropriate. 35 The purpose of this document is to give examples of how policies may be defined for several 36 existing use cases that have been part of the WS-Security Interops that have been conducted 37 (see References section for Interop documents [INTEROPS]). In addition, some example use 38 cases have been included which show some variations from the WS-Security Interop use cases 39 in order to demonstrate how different options and security bindings impact the structure of the 40 policies. 41

1ws-sp-usecases-examples-draft-17-03.doc 16 October 2007 2Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 1 of 116 42Status: 43 This document was last revised or approved by the WS-SX TC on the above date. The level of 44 approval is also listed above. Check the “Latest Version” or “Latest Approved Version” location 45 noted above for possible later revisions of this document. 46 Technical Committee members should send comments on this specification to the Technical 47 Committee’s email list. Others should send comments to the Technical Committee by using the 48 “Send A Comment” button on the Technical Committee’s web page at http://www.oasis- 49 open.org/committees/ws-sx. 50 For information on whether any patents have been disclosed that may be essential to 51 implementing this specification, and any offers of patent licensing terms, please refer to the 52 Intellectual Property Rights section of the Technical Committee web page (http://www.oasis- 53 open.org/committees/ws-sx/ipr.php. 54 The non-normative errata page for this specification is located at http://www.oasis- 55 open.org/committees/ws-sx.

57Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. 58All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual 59Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website. 60This document and translations of it may be copied and furnished to others, and derivative works that 61comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, 62and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice 63and this section are included on all such copies and derivative works. However, this document itself may 64not be modified in any way, including by removing the copyright notice or references to OASIS, except as 65needed for the purpose of developing any document or deliverable produced by an OASIS Technical 66Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must 67be followed) or as required to translate it into languages other than English. 68The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors 69or assigns. 70This document and the information contained herein is provided on an "AS IS" basis and OASIS 71DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 72WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 73OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 74PARTICULAR PURPOSE. 75OASIS requests that any OASIS Party or any other party that believes it has patent claims that would 76necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, 77to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to 78such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that 79produced this specification. 80OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of 81any patent claims that would necessarily be infringed by implementations of this specification by a patent 82holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR 83Mode of the OASIS Technical Committee that produced this specification. OASIS may include such 84claims on its website, but disclaims any obligation to do so. 85OASIS takes no position regarding the validity or scope of any intellectual property or other rights that 86might be claimed to pertain to the implementation or use of the technology described in this document or 87the extent to which any license under such rights might or might not be available; neither does it represent 88that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to 89rights in any document or deliverable produced by an OASIS Technical Committee can be found on the 90OASIS website. Copies of claims of rights made available for publication and any assurances of licenses 91to be made available, or the result of an attempt made to obtain a general license or permission for the 92use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS 93Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any 94information or list of intellectual property rights will at any time be complete, or that any claims in such list 95are, in fact, Essential Claims. 96The names "OASIS", [insert specific trademarked names and abbreviations here] are trademarks of 97OASIS, the owner and developer of this specification, and should be used only to refer to the organization 98and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, 99while reserving the right to enforce its marks against misleading uses. Please see http://www.oasis- 100open.org/who/trademark.php for above guidance. 101

1031 Introduction...... 6 104 1.1 Terminology and Concepts...... 7 105 1.1.1 Actors...... 7 106 1.1.2 Concepts...... 9 107 1.1.2.1 X509 Certificates...... 9 108 1.2 Terminology...... 11 109 1.3 Normative References...... 11 110 1.4 Non-Normative References...... 11 1112 Scenarios...... 12 112 2.1 UsernameToken...... 12 113 2.1.1 UsernameToken – no security binding...... 12 114 2.1.1.1 UsernameToken with plain text password...... 12 115 2.1.1.2 UsernameToken without password...... 13 116 2.1.1.3 UsernameToken with timestamp, nonce and password hash...... 14 117 2.1.2 Use of SSL Transport Binding...... 15 118 2.1.2.1 UsernameToken as supporting token...... 16 119 2.1.3 (WSS 1.0) UsernameToken with Mutual X.509v3 Authentication, Sign, Encrypt...... 18 120 2.1.3.1 (WSS 1.0) Encrypted UsernameToken with X.509v3...... 22 121 2.1.4 (WSS 1.1), User Name with Certificates, Sign, Encrypt...... 26 122 2.2 X.509 Token Authentication Scenario Assertions...... 30 123 2.2.1 (WSS1.0) X.509 Certificates, Sign, Encrypt...... 30 124 2.2.2 (WSS1.0) Mutual Authentication with X.509 Certificates, Sign, Encrypt...... 33 125 2.2.3 (WSS1.1) Anonymous with X.509 Certificate, Sign, Encrypt...... 37 126 2.2.4 (WSS1.1) Mutual Authentication with X.509 Certificates, Sign, Encrypt...... 41 127 2.3 SAML Token Authentication Scenario Assertions...... 47 128 2.3.1 WSS 1.0 SAML Token Scenarios...... 49 129 2.3.1.1 (WSS1.0) SAML1.1 Assertion (Bearer)...... 49 130 2.3.1.2 (WSS1.0) SAML1.1 Assertion (Sender Vouches) over SSL...... 51 131 2.3.1.3 (WSS1.0) SAML1.1 Assertion (HK) over SSL...... 54 132 2.3.1.4 (WSS1.0) SAML1.1 Sender Vouches with X.509 Certificates, Sign, Optional Encrypt...... 55 133 2.3.1.5 (WSS1.0) SAML1.1 Holder of Key, Sign, Optional Encrypt...... 61 134 2.3.2 WSS 1.1 SAML Token Scenarios...... 67 135 2.3.2.1 (WSS1.1) SAML 2.0 Bearer...... 67 136 2.3.2.2 (WSS1.1) SAML2.0 Sender Vouches over SSL...... 71 137 2.3.2.3 (WSS1.1) SAML2.0 HoK over SSL...... 73 138 2.3.2.4 (WSS1.1) SAML1.1/2.0 Sender Vouches with X.509 Certificate, Sign, Encrypt...... 78 139 2.3.2.5 (WSS1.1) SAML1.1/2.0 Holder of Key, Sign, Encrypt...... 83 140 2.4 Secure Conversation Scenarios...... 100 141 2.4.1 (WSS 1.0) Secure Conversation bootstrapped by Mutual Authentication with X.509 Certificates 142 ...... 100 1433 References...... 109 144 3.1 Specifications...... 109 145 3.2 Interops and Sample Messages...... 110 146A. Acknowledgements...... 111 10ws-sp-usecases-examples-draft-17-03.doc 16 October 2007 11Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 4 of 116 147B. Non-Normative Text...... 112 148C. Revision History...... 113 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192

16ws-sp-usecases-examples-draft-17-03.doc 16 October 2007 17Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 6 of 116 1981 Introduction 199[All text is normative unless otherwise labeled] 200This document describes several WS-SecurityPolicy [WS-SECURITYPOLICY] examples. An example 201typically consists of the security aspects of a high-level Web Service use-case with several variable 202components. Many of the examples are based on existing use cases that have been conducted during 203WS-Security Interops [WSS-INTEROPS]. In those examples a reference is included to identify the 204specific use case in the specific interop document that is being demonstrated. 205In the policy examples below, the “wsp” prefix refers to the elements defined in the WS-Policy 206namespace: 207 xmlns:wsp=”http://www.w3.org/ns/ws-policy/” 208and the “sp” prefix to the elements defined in the WS-SecurityPolicy (WS-SP) namespace: 209 xmlns:sp=“http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702” 210 211 Where uses cases are based on existing scenarios, those scenarios are referenced at the 212 beginning of the use case section. The explicit documents describing the scenarios are 213 identified by links in [Section 3.2]. 214

19ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 20Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 7 of 116 2151.1 Terminology and Concepts 216This section describes the logical “actors” that participate in the examples. In addition, there is a 217discussion on general concepts that describes how the logical actors typically relate to the physical 218message exchanges that take place.

2191.1.1 Actors 220The following diagram shows the actors and the relationships that may be typically involved in a network 221security scenario: 222 223

WS-SP Examples

Requestor Initiator Recipient Relying (+ WSDL Party policy)

Issuing Validating Authority Authority (STS) (STS)

224 Figure 1.

225 226The diagram is intended to show the possible interactions that may occur between actors in any given 227scenario, although, in general, depending on the policy specified by the recipient, only a subset of the 228possible interactions will actually occur in a given scenario. 229First, a brief narrative will describe the diagram, then the actors will be defined in more detail. 230In a typical example interaction, a Requestor wants to issue a Web Service request to a Web Service that 231is hosted by the “Recipient” web site on behalf of a RelyingParty, who is actually the business entity 232responsible for making the service available and with whom any business arrangements with the 233Requestor are made. One may think of this as an end to end interaction between a Requestor and a 234RelyingParty, with technical resources being provided by the Initiator on the Requestor side and the 235Recipient on the RelyingParty side. 236Technically, what occurs is that the Requestor hands the request to the Initiator, which in turn issues a 237query to the Recipient and is returned the WSDL [WSDL] describing the Web Service, which generally 238includes WS-SP policy Assertions [WS-POLICY, WS-POLICYATTACHMENT] that describe the security 239policies supported by the Recipient for this Web Service (Note: it is not necessary that the information in 240the Assertions be obtained this way. It may also be stored locally based on out of band agreements 241between the Requestor and RelyingParty). This interaction is shown by the upper pair of arrows between 242the Initiator and the Recipient. 243Upon receipt of the WS-SP WSDL policy assertions, the Initiator then interacts with the Requestor and 244the Issuing Authority, as needed in order to meet the requirements specified by the WS-SP. Generally, 245what is required here is that credentials and tokens are obtained from the Requestor and Issuing

22ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 23Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 8 of 116 246Authority and assembled as required in a new WS-Security request message that is to be issued to the 247Recipient. 248(For example, if a UsernameToken is required by the Recipient, one possibility is that the Initiator will 249query the Requestor for Username and Password and create the appropriate token to include in the 250Request. 251 Other possibilities exist as well, but WS-SP only governs what the final message must contain. How it 252 gets constructed and how the pieces are assembled are specific to the system environment that is 253 being used. 254 In general, the examples in this document will explain the interactions that might occur to meet the 255 policy requirements, but the actual sequences and specifics will be determined by the setup of the 256 systems involved.)

257Finally, after assembling the necessary tokens, the Initiator will sign and encrypt the message as required 258by the WS-SP policy and send it to the Recipient.

259Similar to the Requestor side, on the Recipient side, the details of how the Recipient processes the 260message and uses a Validating Authority to validate the tokens and what basis the RelyingParty uses to 261accept or reject the request is system specific. However, in a general sense, the 3 actors identified on the 262Recipient side will be involved to accept and process a request.

263 (For example, the Recipient may decrypt an encrypted UsernameToken containing a clear text 264 password and username and pass it to the Validating Authority for validation and authentication, 265 then the Recipient may pass the Request to the RelyingParty, which may in turn issue a request 266 for authorization to the Validating Authority.

267These details are beyond the scope of WS-SP and the examples in this document, however, knowing that 268this is the context in which WS-SP operates can be useful to understanding the motivation and usefulness 269of different examples.)

270The following list is a reference to identify the logical actors in Figure 1. (In general, these actors may 271physically be implemented such that more than one actor is included in the physical entity, such as a 272Security Token Service (STS) [WS-TRUST] that implements both an IssuingAuthority and a 273ValidatingAuthority. Similarly, in a scenario where a user is at a security-enabled work station, the work 274station may combine a Requestor and Initiator in a single physical entity.) 275 276  Requestor: the person or entity requesting the service and who will be supplying credentials 277 issued by the IssuingAuthority and will be validated by a ValidatingAuthority. 278  IssuingAuthority: a Security Token Service (STS), which is an organization or entity that 279 typically issues authentication credentials for Requestors. Examples include X509 Certificate 280 Authority, Saml Token Authority, Kerberos Token Authority. (For user passwords, the 281 IssuingAuthority may be thought of as the entity the user contacts for password services, such as 282 changing password, setting reminder phrases, etc.) 283  Initiator: the system or entity that sends the message(s) to the Recipient requesting use of the 284 service on behalf of the Requestor. Typically, the Initiator will first contact the Recipient on behalf 285 of the Requestor and obtain the WS-SP policy and determine what tokens from what kind of 286 IssuingAuthority (X509, SAML, Kerberos, etc) that the Requestor will require to access the 287 service and possibly assist the Requestor to obtain those credentials. In addition, based on the 288 WS-SP policy, the Initiator determines how to format the WS-Security headers of the messages 289 being sent and how to use the security binding required by the policy. 290  Recipient: the system or entity or organization that provides a web service for use and is the 291 supplier of the WS-SP policy that is contained in each example and is the recipient of messages 292 sent by Initiators.

25ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 26Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 9 of 116 293  ValidatingAuthority: the organization or entity that typically validates Requestor credentials for 294 Relying Parties, and, in general, maintains those credentials in an ongoing reliable manner. 295  RelyingParty: the organization or entity that relies on the security tokens contained in the 296 messages sent by the Initiator as a basis for providing the service. For this document, the 297 Recipient and RelyingParty may be considered the same entity. 298 299Of these actors, the Requestor and Initiator can generally being regarded as “client-side” or “requestor- 300side” actors. The Recipient and RelyingParty can be regarded as “server-side” actors.

3011.1.2 Concepts 302Physical message exchanges are between the Initiator and Recipient. For the purposes of this document 303the Initiator and Recipient may be considered to be the physical systems that exchange the messages. 304The Initiator and Recipient use the keys that are involved in the WS-SP security binding that protects the 305messages. 306The Requestor should generally be thought of as a separate physical entity from the Initiator, although in 307some cases, such as a user at a client workstation equipped with signing and encryption capabilities, the 308Requestor may actually also be the Initiator. 309Similarly, the IssuingAuthority should generally be thought of as a separate physical entity from the 310Initiator. However, in some cases, such as SAML sender-vouches, the IssuingAuthority and the Initiator 311may be the same entity. 312In some other cases, such as the case where user passwords are involved, the ValidatingAuthority 313system entity may also comprise the Recipient and the Relying Party, since passwords are typically 314checked locally for validity. 315The focus of WS-SP is the general policy and detailed policy assertions that are sent from the Recipient 316to the Initiator, however, the concepts in those policies generally require understanding specifically the 317relation of the Requestor and IssuingAuthority to the Initiator. This is because the Requestor in general 318does not know in advance what policies each Web Service provider requires and it is necessary for 319practical purposes to have a front end Initiator resolve the policy and coordinate whatever actions are 320required to exchange the Requestor tokens for the tokens required by the service. This token exchange 321may be done using WS-Trust [WS-TRUST] to prepare the necessary requests and process responses 322from an STS IssuingAuthority. Examples of these WS-Trust token exchanges may be found in [WSSX- 323INTEROP]. 324Typically both the Requestor/Initiator and Recipient/RelyingParty will have relations with the 325IssuingAuthority/ValidatingAuthority and often establish contact with those Authorities using WS-Trust for 326the purpose of obtaining and validating tokens used in their Web Service interactions. The policies for 327using the Authority may also be represented using WS-SP, but they are typically no different from the 328policies shown in the examples in this document. The policies in this document may be used for any kind 329of request, whether it be a request to a service provider for general content or operations or a request to 330an Authority for authentication tokens. 331In each example the relations between these actors and how the request message is prepared will be 332described, because, in general, the policy requirements will imply these relationships. Generally, each of 333the 3 client side actors, the Requestor, the Initiator, and the IssuingAuthority will contribute to the 334preparation of the request message, which is the primary focus of this document. For validation of the 335message, the Recipient, the RelyingParty, and the ValidatingAuthority are generally involved, but for this 336document the focus is simply that the Recipient provides the WS-SP policy that dictates the preparation of 337the request message. 338

3391.1.2.1 X509 Certificates 340The specifics of whom is trusted for X509 certificates depends on the specific organization’s PKI (Public 341Key Infrastructure) setup. For this document, we shall assume the Subject of the X509 certificate

28ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 29Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 10 of 116 342identifies the actor, which may be the IssuingAuthority, or the Initiator, or the Requestor, depending on the 343example. We shall also assume that the issuer of the X509 certificates is a general Certificate Authority 344not directly involved in any authorization of the web service transactions, but is relied on for the validity of 345the X509 certificate in a manner out of scope of the scenarios covered. In addition, this document does 346not explicitly address the case of X509 certificates issued by the IssuingAuthority actor. Such use cases 347are generally implicitly covered if one assumes that such relations are automatically covered by the 348specifics of the organization PKI setups. 349However, the IssuingAuthority may issue tokens, such as SAML holder-of-key that contain X509 350certificates. In these cases, the basis of trust is that the X509 Certificate of the IssuingAuthority was used 351to protect the X509 certificate of the Requestor which is contained in the signed SAML holder-of-key 352token. I.e. any “chaining” of tokens is done by referencing those tokens within signed XML structures and 353not by issuing actual X509 certificates

31ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 32Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 11 of 116 3541.2 Terminology 355The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD 356NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described 357in [RFC2119].

3581.3 Normative References 359 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, 360 http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997. 361 [Reference] [Full reference citation]

3621.4 Non-Normative References 363 [Reference] [Full reference citation]

34ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 35Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 12 of 116 3642 Scenarios

3652.1 UsernameToken 366UsernameToken authentication scenarios that use simple username password token for authentication. 367There are several sub-cases.

3682.1.1 UsernameToken – no security binding 369In this model a UsernameToken is placed within a WS-Security header in the SOAP Header [WSS10- 370USERNAME, WSS11-USERNAME]. No other security measure is used. 371Because no security binding is used, there is no explicit distinction between the Requestor, who is 372identified in the UsernameToken and the Initiator, who physically sends the message. They may be one 373and the same or distinct parties. The lack of a security binding indicates that any direct URL access 374method (ex. HTTP) may be used to access the service.

3752.1.1.1 UsernameToken with plain text password 376This scenario is based on the first WS-Security Interop Scenarios Document [WSS10-INTEROP-01 377Scenario 1 – section 3.4.4] 378(http://www.oasis-open.org/committees/download.php/11374/wss-interop1-draft-06-merged-changes.pdf). 379This policy says that Requestor/Initiator must send a password in a UsernameToken in a WS-Security 380header to the Recipient (who as the Authority will validate the password). The password is required 381because that is the default requirement for the Web Services Security Username Token Profile 1.x 382[WSS10-USERNAME, WSS11-USERNAME]. 383This setup is only recommended where confidentiality of the password is not an issue, such as a pre- 384production test scenario with dummy passwords, which might be used to establish that the Initiator can 385read the policy and prepare the message correctly, and that connectivity and login to the service can be 386performed. 387 388 (P01) 389 (P02) 390 (P03) 391 (P04) 392 (P05) 393 (P06) 394 (P07) 395 396An example of a message that conforms to the above stated policy is as follows. 397 398 (M01) 399 (M02) 400 (M03) 401 (M04) 402 (M05) 403 (M06) Chris 404 (M07) sirhC 406 (M08) pN...= 408 (M010) 2007-03-28T18:42:03Z 37ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 38Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 13 of 116 409 (M011) 410 (M012) 411 (M013) 412 (M014) 413 (M015) 414 (M016) EchoString 415 (M017) 416 (M018) 417 (M019) 418 419The UsernameToken element starting on line (M005) satisfies the UsernameToken assertion on line 420(P004). By default, a Password element is included in the UsernameToken on line (M007) holding a plain 421text password. Lines (M008-M010) contain an optional Nonce element and Created timestamp, which, 422while optional, are recommended to improve security of requests against replay and other attacks 423[WSS10-USERNAME]. All WS-Security compliant service implementations should support the 424UsernameToken with cleartext password with or without the Nonce and Created elements. 425 4262.1.1.2 UsernameToken without password 427This policy is the same as 2.1.1.1 except no password is to be placed in the UsernameToken. There are 428no credentials to further establish the identity of the Requestor and no security binding that the Initiator is 429required to use. This is a possible production scenario where all the service provider wants is a 430UsernameToken to associate with the request. There is no explicit Authority implied in this scenario, 431except possibly that the username extracted from the UsernameToken would be evaluated by a server- 432side “Authority” that maintained a list of valid username values. 433 434(P01) 435(P02) 436(P03) 437(P04) 438(P05) 439(P06) 440(P07) 441(P08) 442(P09) 443(P010) 444(P011) 445Lines (P002) – (P010) contain the SupportingToken assertion which includes a UsernameToken 446indicating that a UsernameToken must be included in the security header. 447Line (P006) requires that the wsse:Password element must not be present in the UsernameToken. 448An example of an input message that conforms to the above stated policy is as follows: 449 450(M01) 451(M02) 452(M03) 453(M04) 455(M05) 456(M06) Chris 457(M07) 458(M08) 459(M09) 460(M010) 461(M011) 462(M012) EchoString

40ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 41Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 14 of 116 463(M013) 464(M014) 465(M015) 466Lines (M005) – (M007) hold the unsecured UsernameToken which only contains the name of user 467(M006), but no password. 468

4692.1.1.3 UsernameToken with timestamp, nonce and password hash 470This scenario is similar to 2.1.1.1, except it is more secure, because the Requestor password is protected 471by combining it with a nonce and timestamp, and then hashing the combination. Therefore, this may be 472considered as a potential production scenario where passwords may be safely used. It may be assumed 473that the password must be validated by a server-side ValidatingAuthority and so must meet whatever 474requirements the specific Authority has established. 475 476 (P01) 477 (P02) 478 (P03) 479 (P04) 480 (P05) 481 (P06) 482 (P07) 483 (P08) 484 (P09) 485 (P010) 486 (P011) 487 488An example of a message that conforms to the above stated policy is as follows. 489 490 (M01) 491 (M02) 492 (M03) 493 (M04) 494 (M05) 496 (M06) Chris 497 (M07) weYI3nXd8LjMNVksCKFV8t3rgHh3Rw== 500 (M08) WScqanjCEAC4mQoBE07sAQ== 501 (M09) 2007-05-01T01:15:30Z 502 (M010) 503 (M011) 504 (M012) 505 (M013) 506 (M014) 507 (M015) EchoString 508 (M016) 509 (M017) 510 (M018) 511 512This message is very similar to the one in section 2.1.1.1. A UsernameToken starts on line (M005) to 513satisfy the UserNameToken assertion. However, in this example the Password element on line (M007) is 514of type PasswordDigest to satisfy the HashPassword assertion on line (P006). The Nonce (M008) and

43ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 44Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 15 of 116 515Created timestamp (M009) are also included as dictated by the HashPassword assertion. The Nonce and 516timestamp values are included in the password digest on line (M007).

46ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 47Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 16 of 116 5172.1.2 Use of SSL Transport Binding 518Both server authentication and mutual (client AND server) authentication SSL [SSL] are supported via 519use of the sp:TransportBinding policy assertion. (For mutual authentication, a RequireClientCertificate 520assertion may be inserted within the HttpsToken assertion. The ClientCertificate may be regarded as a 521credential token for authentication of the Initiator, which in the absence of any additional token 522requirements would generally imply the Initiator is also the Requestor. The Authority would be the issuer 523of the client certificate.) 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546

49ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 50Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 17 of 116 5472.1.2.1 UsernameToken as supporting token 548Additional credentials can be included as supporting tokens. Each of the UsernameTokens described in 549section 2.1.1 may be used in this scenario and any clear text information or password will be protected by 550SSL. So, for example, including a user name token over server authentication SSL we have: 551 552 (P01) 553 (P02) 554 (P03) 555 (P04) 556 (P05) 557 (P06) 558 (P07) 559 (P08) 560 (P09) 561 (P010) 562 (P011) 563 (P012) 564 (P013) 565 (P014) 566 (P015) 567 (P016) 568 (P017) 569 (P018) 570 (P019) 571 (P020) 572 (P021) 573 (P022) 574 (P023) 575 (P024) 576 (P025) 577 (P026) 578 (P027) 579Lines (P002) – (P021) contain the TransportBinding assertion which indicates that the message must be 580protected by a secure transport protocol like SSL or TLS. 581Lines (P004) – (P008) hold the TransportToken assertion, indicating that the transport is secured by 582means of an HTTPS Transport Token, requiring to perform cryptographic operations based on the 583transport token using the Basic256 algorithm suite (P011). 584In addition, the Layout assertion in lines (P014) – (P018) require that the order of the elements in the 585SOAP message security header must conform to rules defined by WSSECURITYPOLICY that follow the 586general principle of 'declare before use'. 587Line (P019) indicates that the wsu:Timestamp element must be present in the SOAP message security 588header. 589Lines (P022) – (P026) Lines contain the SupportingToken assertion which includes a UsernameToken 590indicating that a UsernameToken must be included in the security header. 591An example of an input message prior to the transport encryption that conforms to the above stated policy 592is as follows: 593(M01) 594(M02) 595(M03) 596(M04) 599(M05) 600(M06) 2001-09-13T08:42:00Z 601(M07)

52ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 53Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 18 of 116 602(M08) 604(M09) Chris 605(M010) sirhC 607(M011) 608(M012) 609(M013) 610(M014) 611(M015) 612(M016) EchoString 613(M017) 614(M018) 615(M019) 616Lines (M005) – (M007) hold Timestamp element according to the IncludeTimestamp assertion. 617Lines (M008) – (M011) hold the UsernameToken which contains the name (M009) and password (M010) 618of the user sending this message. 619 620

55ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 56Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 19 of 116 6212.1.3 (WSS 1.0) UsernameToken with Mutual X.509v3 Authentication, Sign, 622 Encrypt 623 624This scenario is based on WS-I SCM Security Architecture Technical requirements for securing the SCM 625Sample Application, March 2006 [WSI-SCM-SAMPLEAPPL – GetCatalogRequest, SubmitOrderRequest]. 626This use case corresponds to the situation where both parties have X.509v3 certificates (and public- 627private key pairs). The Initiator includes a user name token that may stand for the Requestor on-behalf-of 628which the Initiator is acting. The UsernameToken is included as a SupportingToken; this is also 629encrypted. The Authority for this request is generally the Subject of the Initiator’s trusted X.509 Certificate. 630We model this by using the asymmetric security binding [WSSP] with a UsernameToken 631SupportingToken. 632The message level policies cover a different scope of the web service definition than the security binding 633level policy and so appear as separate policies and are attached at Message Policy Subject. These are 634shown below as input and output policies. Thus, we need a set of coordinated policies one with endpoint 635subject and two with message subjects to achieve this use case. 636The policy is as follows: 637 (P01) 638 (P02) 639 (P03) 640 (P04) 641 (P05) 642 (P06) 643 (P07) 644 (P08) 646 (P09) 647 (P010) 648 (P011) 649 (P012) 650 (P013) 651 (P014) 652 (P015) 653 (P016) 654 (P017) 656 (P018) 657 (P019) 658 (P020) 659 (P021) 660 (P022) 661 (P023) 662 (P024) 663 (P025) 664 (P026) 665 (P027) 666 (P028) 667 (P029) 668 (P030) 669 (P031) 670 (P032) 671 (P033) 672 (P034) 673 (P035) 674 (P036) 675 (P037) 676 (P038)

58ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 59Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 20 of 116 677 (P039) 678 (P040) 679 (P041) 680 (P042) 681 (P043) 682 (P044) 683 (P045) 685 (P046) 686 (P047) 687 (P048) 688 (P049) 689 (P050) 690 (P051) 691 (P052) 692 (P053) 693 (P054) 694 695 (P055) 696 (P056) 697 (P057) 698 (P058) 699 (P059) 700 (P060) 701 (P061) 702 (P062) 703 (P063) 704 (P064) 705 (P065) 706 (P066) 707 708 (P067) 709 (P068) 710 (P069) 711 (P070) 712 (P071) 713 (P072) 714 (P073) 715 (P074) 716 (P075) 717 (P076) 718 (P077) 719 (P078) 720Lines (P004) – (P037) contain the AsymmetricBindingAssertion which indicates that the initiator’s token 721must be used for the message signature and the recipient’s token must be used for message encryption. 722Lines (P006) – (P014) contain the InitiatorToken assertion. Within that assertion lines (P008) – (P012) 723indicate that the initiator token must be an X.509 token that must be included with all messages sent to 724the recipient. Line (P010) dictates the X.509 token must be an X.509v3 security token as described in the 725WS-Security 1.0 X.509 Token Profile. 726Lines (P015) – (P023) contain the RecipientToken assertion. Within that assertion lines (P017) – (P021) 727dictate the recipient token must also be an X.509 token as described in the WS-Security 1.0 X.509 Token 728Profile, however as stated on line (P017) it must not be included in any message. Instead, according to 729the MustSupportKeyRefIdentitier assertion on line (P040) a KeyIdentifier must be used to identify the 730token in any messages where the token is used. 731Line (P034) requires the inclusion of a timestamp. 732Lines (P043) – (P051) contain a SignedEncryptedSupportingTokens assertion which identifies the 733inclusion of an additional token which must be included in the message signature and encrypted. Lines 734(P045) – (P049) indicate that the supporting token must be a UsernameToken and must be included in all

61ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 62Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 21 of 116 735messages to the recipient. Line (P047) dictates the UsernameToken must conform to the WS-Security 1.0 736UsernameToken Profile. 737Lines (P055) – (P066) contain a policy that is attached to the input message. Lines (P058) – (P060) 738require that the body of the input message must be signed. Lines (P061) – (P063) require the body of the 739input message must be encrypted. 740Lines (P067) – (P078) contain a policy that is attached to the output message. Lines (P070) – (P072) 741require that the body of the output message must be signed. Lines (P073) – (P075) require the body of 742the output message must be encrypted. 743An example of an input message that conforms to the above stated policy is as follows. 744 (M01) 745 (M02) 746 (M03) 747 (M04) 749 (M05) 750 (M06) 751 (M07) 752 (M08) 753 (M09) 754 (M010) 2001-09-13T08:42:00Z 755 (M011) 756 (M012) 758 (M013) MIIEZzCCA9CgAwIBAgIQEmtJZc0… 759 (M014) 760 (M015) 761 (M016) 762 (M017) 763 (M018) 765 (M019) MIGfMa0GCSq… 766 (M020) 767 (M021) 768 (M022) 769 (M023) 770 (M024) ... 771 (M025) 772 (M026) 773 (M027) 774 (M028) … 775 (M029) … 776 (M030) … 777 (M031) … 778 (M032) 779 (M033) HFLP… 780 (M034) 781 (M035) 782 (M036) 783 (M037) 784 (M038) 785 (M039) 786 (M040) 787 (M041) 788 (M042) 789 (M043) 790 (M044)

64ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 65Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 22 of 116 791 (M045) 792 (M046) 794 (M047) MIGfMa0GCSq… 795 (M048) 796 (M049) 797 (M050) 798 (M051) 799 (M052) ... 800 (M053) 801 (M054) 802 (M055) 803 (M056) 804Line (M006) is an encryption data reference that references the encrypted UsernameToken on lines 805(M015) – (M024) which was required to be included by the SignedEncryptedSupportingTokens assertion. 806Lines (M018) – (M020) hold a KeyIdentifier of the recipient’s token used to encrypt the UsernameToken 807as required by the AsymmetricBinding assertion. Because the RecipientToken assertion disallowed the 808token from being inserted into the message, a KeyIdentifier is used instead of a reference to an included 809token. 810Line (M007) is an encryption data reference that references the encrypted body of the message on lines 811(M043) – (M054). The encryption was required by the EncryptedParts assertion of the input message 812policy. It also uses the recipient token as identified by the KeyIdentifier. 813Lines (M009) – (M011) contain a timestamp for the message as required by the IncludeTimestamp 814assertion. 815Lines (M012) – (M014) contain the BinarySecurityToken holding the X.509v3 certificate of the initiator as 816required by the InitiatorToken assertion. 817Lines (M027) – (M039) contain the message signature. 818Line (M029) indicates the message timestamp is included in the signature as required by the 819IncludeTimestamp assertion definition. 820Line (M030) indicates the supporting UsernameToken is included in the signature as required by the 821SignedEncryptedSupportingTokens assertion. Because the token was encrypted its content prior to 822encryption is included below to better illustrate the reference. 823(M057) 824(M058) Chris 825(M059) sirhC 827(M060) 828Line (M031) indicates the message body is included in the signature as required by the SignedParts 829assertion of the input message policy. 830Note that the initiator’s BinarySecurityToken is not included in the message signature as it was not 831required by policy. 832Line (M036) references the initiator’s BinarySecurityToken included in the message for identifying the key 833used for signing as dictated by the AsymmetricBinding assertion. 834

67ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 68Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 23 of 116 8352.1.3.1 (WSS 1.0) Encrypted UsernameToken with X.509v3 836This scenario is based on the first WS-Security Interop Scenarios Document [WSS10-INTEROP-01 837Scenario 2 – section 4.4.4] 838(http://www.oasis-open.org/committees/download.php/11374/wss-interop1-draft-06-merged-changes.pdf). 839This policy says that Requestor/Initiator must send a password in an encrypted UsernameToken in a WS- 840Security header to the Recipient (who as the Authority will validate the password). The password is 841required because that is the default requirement for the Web Services Security Username Token Profile 8421.x [WSS10-USERNAME, WSS11-USERNAME]. 843 844 845 846 847This setup is only recommended when the sender cannot provide the “message signature” and it is 848RECOMMENDED that the receiver employs some security mechanisms external to the message to 849prevent the spoofing attacks. 850The policy is as follows: 851(P01) 852(P02) 853(P03) 854(P04) 855(P05) 856(P06) 858(P07) 859(P08) 860(P09) 861(P010) 862(P011) 863(P012) 864(P013) 865(P014) 866(P015) 868(P016) 869(P017) 870(P018) 871(P019) 872(P020) 873(P021) 874(P022) 875(P023) 876(P024) 877(P025) 878(P026) 879(P027) 880(P028) 881(P029) 882(P030) 883(P031) 884(P032) 885(P033) 886(P034) 887(P035) 888(P036) 889(P037) 890(P038) 70ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 71Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 24 of 116 891(P039) 892(P040) 893(P041) 894(P042) 895(P043) 896(P044) 898(P045) 899(P046) 900(P047) 901(P048) 902(P049) 903(P050) 904(P051) 905(P052) 906 907(P053) 908(P054) 909(P055) 910(P056) 911(P057) 912(P058) 913(P059) 914(P060) 915(P061) 916 917(P062) 918(P063) 919(P064) 920(P065) 921(P066) 922(P067) 923(P068) 924(P069) 925(P070) 926Lines (P002) – (P035) contain the AsymmetricBindingAssertion which indicates that the recipient’s token 927must be used for both message signature and encryption. 928Lines (P004) – (P012) contain the InitiatorEncryptionToken assertion. Within that assertion lines (P006) – 929(P010) indicate that the initiator token must be an X.509 token. Line (P008) dictates the X.509 token must 930be an X.509v3 security token as described in the WS-Security 1.0 X.509 Token Profile, however as stated 931on line (P006) it must not be included in any message. 932Lines (P013) – (P021) contain the RecipientSignatureToken assertion. Within that assertion lines (P015) – 933(P019) dictate the recipient token must also be an X.509 token as described in the WS-Security 1.0 X.509 934Token Profile for message signature, however as stated on line (P017) it must not be included in any 935message. 936Line (P032) requires the inclusion of a timestamp. 937Line (P035) OnlySignEntireHeadersAndBody assertion will only apply to the response message, as there 938is no signature token defined for the Initiator. 939Lines (P036) – (P041) contain some WS-Security 1.0 related interoperability requirements, specifically 940support for key identifier, and issuer serial number. 941Lines (P042) – (P051) contain an EncryptedSupportingTokens assertion which identifies the inclusion of 942an additional token which must be included in the message and encrypted. Lines (P044) – (P049) indicate 943that the supporting token must be a UsernameToken and must be included in all messages to the 944recipient. Line (P046) dictates the UsernameToken must be hash into digest format, instead of clear text 945password. Line (P047) dictates the UsernameToken must conform to the WS-Security 1.0 946UsernameToken Profile.

73ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 74Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 25 of 116 947Lines (P053) – (P061) contain a policy that is attached to the input message. Lines (P056) – (P058) 948require the body of the input message must be encrypted. 949Lines (P062) – (P070) contain a policy that is attached to the output message. Lines (P065) – (P068) 950require the body of the output message must be encrypted. 951 952An example of a request message that conforms to the above stated policy is as follows. 953 (M01) 954(M02) 955(M03) 956(M04) 958(M05) 959(M06) 960(M07) 961(M08) 962(M09) 963(M010) 964(M011) CuJ. . .= 966(M013) 967(M014) 968(M015) 969(M016) dbj...= 970(M017) 971(M018) 972(M019) 973(M020) 974(M021) 975(M022) 976(M023) 978(M024) 979(M025) 980(M026) KZf...= 981(M027) 982(M028) 983(M029) 984(M030) 2007-03-28T18:42:03Z 985(M031) 986(M032) 987(M033) 988(M034) 989(M035) 991(M036) 992(M037) 993(M038) a/9...B 994(M039) 995(M040) 996(M041) 997(M042) 998Line (M020) is an encryption data reference that references the encrypted UsernameToken on lines 999(M023) – (M028) which was required to be included by the EncryptedSupportingTokens assertion. Lines 1000(M009) – (M014) hold a KeyIdentifier of the recipient’s token used to encrypt the UsernameToken as 1001required by the AsymmetricBindingAssertion. Because the InitiatorEncryptionAssertion disallowed the token 1002from being inserted into the message, a KeyIdentifier is used instead of a reference to an included token.

76ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 77Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 26 of 116 1003Line (M019) is an encryption data reference that references the encrypted body of the message on lines 1004(M035) – (M040). The encryption was required by the EncryptedParts assertion of the input message 1005policy. It also uses the recipient token as identified by the KeyIdentifier. 1006Lines (M029) – (M031) contain a timestamp for the message as required by the IncludeTimestamp 1007assertion. 1008Because the username token was encrypted its content prior to encryption is included below to better 1009illustrate the reference. 1010(M043) 1011(M044) Chris 1012(M045) oY...= 1014(M046) pN...= 1015(M047) 2007-03-28T18:42:03Z 1016(M048) 1017Line (M046) contains the Nonce element and Line (M047) contains a timestamp. It is recommended that 1018these two elements should also be included in the PasswordText case for better security 1019[WSS10-USERNAME]. 1020

79ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 80Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 27 of 116 10212.1.4 (WSS 1.1), User Name with Certificates, Sign, Encrypt 1022 1023This scenario is based on WCF (Indigo) Interoperability Lab: Web Services Security September 1st, 2005 1024[WCF-PLUGFEST-INTEROP]. 1025The use case here is the following: the Initiator generates a symmetric key; the symmetric key is 1026encrypted using the Recipient’s certificate and placed in an encrypted key element. The UsernameToken 1027identifying the Requestor and message body are signed using the symmetric key. The body and 1028UsernameToken are also encrypted. The Authority for this request is generally the Subject of the 1029Initiator’s X509 certificate. 1030We can use the symmetric security binding [WSSP] with X509token as the protection token to illustrate 1031this case. If derived keys are to be used, then the derived keys property of X509Token should be set. 1032The policy is as follows: 1033(P01) 1034(P02) 1035(P03) 1036(P04) 1037(P05) 1038(P06) 1039(P07) 1040(P08) 1067(P033) 1068(P034) 1069(P035) 1070(P036) 1071(P037) 1072(P038) 1073(P039) 1074(P040) 1075(P041) 1076(P042) 1077(P043) 1078(P044) 82ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 83Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 28 of 116 1079(P045) 1080(P046) 1081(P047) 1082(P048) 1083(P049) 1084 1085(P050) 1086(P051) 1087(P052) 1088(P053) 1089(P054) 1090(P055) 1091(P056) 1092(P057) 1093(P058) 1094(P059) 1095(P060) 1096(P061) 1097 1098(P062) 1099(P063) 1100(P064) 1101(P065) 1102(P066) 1103(P067) 1104(P068) 1105(P069) 1106(P070) 1107(P071) 1108(P072) 1109(P073) 1110Lines (P004) – (P297) contain a SymmetricBindingAssertion which indicates the use of one token to both 1111sign and encrypt a message. 1112Lines (P006) – (P015) contain the ProtectionToken assertion. Within that assertion lines (P008) – (P012) 1113indicate that the protection token must be an X.509 token that must never be included in any messages in 1114the message exchange. Line (P010) dictates the X.509 token must be an X.509v3 security token as 1115described in the WS-Security 1.1 X.509 Token Profile. Line (P011) dicates a thumbprint reference must 1116be used to identify the token in any message. 1117Line (P026) requires the inclusion of a timestamp. 1118Lines (P030) – (P038) contain a SignedEncryptedSupportingTokens assertion which identifies the 1119inclusion of an additional token which must be included in the message signature and encrypted. Lines 1120(P032) – (P036) indicate that the supporting token must be a UsernameToken and must be included in all 1121messages to the recipient. Line (P034) dictates the UsernameToken must conform to the WS-Security 1.1 1122UsernameToken Profile. 1123Lines (P040) – (P046) contain some WS-Security 1.1 related interoperability requirements, specifically 1124support for key identifier, issuer serial number, thumbprint, and encrypted key references. 1125Lines (P050) – (P061) contain a policy that is attached to the input message. Lines (P053) – (P055) 1126require that the body of the input message must be signed. Lines (P056) – (P058) require the body of the 1127input message must be encrypted. 1128Lines (P062) – (P073) contain a policy that is attached to the output message. Lines (P065) – (P067) 1129require that the body of the output message must be signed. Lines (P068) – (P070) require the body of 1130the output message must be encrypted. 1131An example of an input message that conforms to the above stated policy is as follows. 1132(M01) 1133(M02) 1134(M03) 1135(M04) 85ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 86Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 29 of 116 1136(M05) 1137(M06) 1139(M07) 1140(M08) 1141(M09) 1143(M010) LKiQ/CmFrJDJqCLFcjlhIsmZ/+0= 1144(M011) 1145(M012) 1146(M013) 1147(M014) 1148(M015) 1149(M016) 1150(M017) 1151(M018) 1152(M019) 1153(M020) 2001-09-13T08:42:00Z 1154(M021) 1155(M022) 1156(M023) 1158(M024) 1159(M025) 1160(M026) 1161(M027) 1162(M028) 1163(M029) 1164(M030) ... 1165(M031) 1166(M032) 1167(M033) 1168(M034) … 1169(M035) … 1170(M036) … 1171(M037) … 1172(M038) 1173(M039) HFLP… 1174(M040) 1175(M041) 1176(M042) 1177(M043) 1178(M044) 1179(M045) 1180(M046) 1181(M047) 1182(M048) 1183(M049) 1184(M050) 1186(M051) 1187(M052) 1188(M053) 1189(M054) 1190(M055) 1191(M056) 1192(M057) ... 1193(M058)

88ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 89Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 30 of 116 1194(M059) 1195(M060) 1196(M061) 1197Lines (M005) – (M014) contain the encrypted symmetric key as required by the use of the 1198SymmetricBinding assertion staring on line (P004) with an X509Token ProtectionToken assertion. Line 1199(M006) references the KwRsaOaep Asymmetric Key Wrap algorithm dictated by the Basic 256 Algorithm 1200Suite assertion on line (P018). Lines (M009) – (M011) hold a KeyIdentifier of the protection token used to 1201encrypt the symmetric key as required by the SymmetricBinding assertion. Because the ProtectionToken 1202assertion disallowed the token from being inserted into the message and instead required a thumbprint 1203reference, a thumbprint reference is included to identify the token. 1204Line (M016) is an encryption data reference that references the encrypted supporting UsernameToken on 1205lines (M022) – (M032). The encryption was required by the SignedEncryptedSupportingTokens assertion 1206on line (P038). Line (M023) references the Aes256 Encryption algorithm dictated by the Basic 256 1207Algorithm Suite assertion on line (P018). The encrypted symmetric key is used to encrypt the 1208UsernameToken as referenced on line (M026). 1209Line (M017) is an encryption data reference that references the encrypted body of the message on lines 1210(M049) – (M059). The encryption was required by the EncryptedParts assertion of the input message 1211policy. The encrypted symmetric key is used to encrypt the UsernameToken as referenced on line 1212(M053). 1213Lines (M019) – (M021) contain a timestamp for the message as required by the IncludeTimestamp 1214assertion. 1215Lines (M033) – (M045) contain the message signature. 1216Line (M035) indicates the message timestamp is included in the signature as required by the 1217IncludeTimestamp assertion definition. 1218Line (M036) indicates the supporting UsernameToken is included in the signature as required by the 1219SignedSupportingTokens assertion. Because the token was encrypted its content prior to encryption is 1220included below to better illustrate the reference. 1221(M062) 1222(M063) Chris 1223(M064) sirhC 1225(M065) 1226Line (M037) indicates the message body is included in the signature as required by the SignedParts 1227assertion of the input message policy. 1228Line (M042) references the encrypted symmetric key for signing as dictated by the SymmetricBinding 1229assertion. 1230

91ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 92Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 31 of 116 12312.2 X.509 Token Authentication Scenario Assertions

12322.2.1 (WSS1.0) X.509 Certificates, Sign, Encrypt 1233This use-case corresponds to the situation where both parties have X.509v3 certificates (and public- 1234private key pairs). The requestor identifies itself to the service. The message exchange is integrity 1235protected and encrypted. 1236This modeled by use of an asymmetric security binding assertion. 1237The policy is as follows: 1238(P01) 1239(P02) 1240(P03) 1241(P04) 1242(P05) 1243(P06) 1244(P07) 1245(P08) 1247(P09) 1248(P010) 1249(P011) 1250(P012) 1251(P013) 1252(P014) 1253(P015) 1254(P016) 1255(P017) 1257(P018) 1258(P019) 1259(P020) 1260(P021) 1261(P022) 1262(P023) 1263(P024) 1264(P025) 1265(P026) 1266(P027) 1267(P028) 1268(P029) 1269(P030) 1270(P031) 1271(P032) 1272(P033) 1273(P034) 1274(P035) 1275(P036) 1276(P037) 1277(P038) 1278(P039) 1279(P040) 1280(P041) 1281(P042) 1282(P043) 1283(P044) 1284(P045) 1285 1286(P046) 1287(P047)

94ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 95Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 32 of 116 1288(P048) 1289(P049) 1290(P050) 1291(P051) 1292(P052) 1293(P053) 1294(P054) 1295(P055) 1296(P056) 1297(P057) 1298 1299(P058) 1300(P059) 1301(P060) 1302(P061) 1303(P062) 1304(P063) 1305(P064) 1306(P065) 1307(P066) 1308(P067) 1309(P068) 1310(P069) 1311Lines (P004) – (P037) contain the AsymmetricBindingAssertion which indicates that the initiator’s token 1312must be used for the message signature and the recipient’s token must be used for message encryption. 1313Lines (P006) – (P014) contain the InitiatorToken assertion. Within that assertion lines (P008) – (P012) 1314indicate that the initiator token must be an X.509 token that must be included with all messages sent to 1315the recipient. Line (P010) dictates the X.509 token must be an X.509v3 security token as described in the 1316WS-Security 1.0 X.509 Token Profile. 1317Lines (P015) – (P023) contain the RecipientToken assertion. Within that assertion lines (P017) – (P021) 1318dictate the recipient token must also be an X.509 token as described in the WS-Security 1.0 X.509 Token 1319Profile, however as stated on line (P017) it must not be included in any message. Instead, according to 1320the MustSupportKeyRefIdentitier assertion on line (P040) a KeyIdentifier must be used to identify the 1321token in any messages where the token is used. 1322Line (P034) requires the inclusion of a timestamp. 1323Lines (P046) – (P057) contain a policy that is attached to the input message. Lines (P049) – (P051) 1324require that the body of the input message must be signed. Lines (P052) – (P054) require the body of the 1325input message must be encrypted. 1326Lines (P058) – (P069) contain a policy that is attached to the output message. Lines (P061) – (P063) 1327require that the body of the output message must be signed. Lines (P064) – (P066) require the body of 1328the output message must be encrypted. 1329An example of an input message that conforms to the above stated policy is as follows. 1330 (M01) 1331 (M02) 1332 (M03) 1333 (M04) 1335 (M05) 1336 (M06) 1337 (M07) 1338 (M08) 1339 (M09) 1340 (M010) 1341 (M011) 1343 (M012) MIGfMa0GCSq… 1344 (M013) 1345 (M014) 97ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 98Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 33 of 116 1346 (M015) 1347 (M016) Hyx...= 1348 (M017) 1349 (M018) 1350 (M019) 1351 (M020) 1352 (M021) 1353 (M022) 1354 (M023) 2001-09-13T08:42:00Z 1355 (M024) 1356 (M025) 1358 (M026) MIIEZzCCA9CgAwIBAgIQEmtJZc0… 1359 (M027) 1360 (M028) 1361 (M029) … 1362 (M030) … 1363 (M031) … 1364 (M032) 1365 (M033) HFLP… 1366 (M034) 1367 (M035) 1368 (M036) 1369 (M037) 1370 (M038) 1371 (M039) 1372 (M040) 1373 (M041) 1374 (M042) 1375 (M043) 1376 (M044) 1377 (M045) ... 1378 (M046) 1379 (M047) 1380 (M048) 1381 (M049) 1382Line (M019) is an encryption data reference that references the encrypted body of the message on lines 1383(M043) – (M047). The encryption was required by the EncryptedParts assertion of the input message 1384policy. Lines (M011) – (M013) hold a KeyIdentifier of the recipient’s token used to encrypt the body as 1385required by the AsymmetricBinding assertion. Because the RecipientToken assertion disallowed the 1386token from being inserted into the message, a KeyIdentifier is used instead of a reference to an included 1387token. 1388Lines (M022) – (M024) contain a timestamp for the message as required by the IncludeTimestamp 1389assertion. 1390Lines (M025) – (M027) contain the BinarySecurityToken holding the X.509v3 certificate of the initiator as 1391required by the InitiatorToken assertion. 1392Lines (M028) – (M039) contain the message signature. 1393Line (M030) indicates the message timestamp is included in the signature as required by the 1394IncludeTimestamp assertion definition. 1395Line (M031) indicates the message body is included in the signature as required by the SignedParts 1396assertion of the input message policy. 1397Note that the initiator’s BinarySecurityToken is not included in the message signature as it was not 1398required by policy. 1399Lines (M035) – (M037) references the initiator’s BinarySecurityToken included in the message for 1400identifying the key used for signing as dictated by the AsymmetricBinding assertion.

100ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 101Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 34 of 116 14012.2.2 (WSS1.0) Mutual Authentication with X.509 Certificates, Sign, Encrypt 1402This scenario is based on WSS Interop, Scenario 3, Web Services Security: Interop 1, Draft 06, Editor, 1403Hal Lockhart, BEA Systems 1404This use case corresponds to the situation where both parties have X.509v3 certificates (and public- 1405private key pairs). The requestor wishes to identify itself to the service using its X.509 credential (strong 1406authentication). The message exchange needs to be integrity protected and encrypted as well. The 1407difference from previous use case is that the X509 token inserted by the client is included in the message 1408signature (see ). 1409The policy is as follows: 1410(P01) 1411(P02) 1412(P03) 1413(P04) 1414(P05) 1415(P06) 1416(P07) 1417(P08) 1419(P09) 1420(P010) 1421(P011) 1422(P012) 1423(P013) 1424(P014) 1425(P015) 1426(P016) 1427(P017) 1429(P018) 1430(P019) 1431(P020) 1432(P021) 1433(P022) 1434(P023) 1435(P024) 1436(P025) 1437(P026) 1438(P027) 1439(P028) 1440(P029) 1441(P030) 1442(P031) 1443(P032) 1444(P033) 1445(P034) 1446(P035) 1447(P036) 1448(P037) 1449(P038) 1450(P039) 1451(P040) 1452(P041) 1453(P042) 1454(P043) 1455(P044) 1456(P045) 1457(P046) 1458 1459(P047)

103ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 104Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 35 of 116 1460(P048) 1461(P049) 1462(P050) 1463(P051) 1464(P052) 1465(P053) 1466(P054) 1467(P055) 1468(P056) 1469(P057) 1470(P058) 1471 1472(P059) 1473(P060) 1474(P061) 1475(P062) 1476(P063) 1477(P064) 1478(P065) 1479(P066) 1480(P067) 1481(P068) 1482(P069) 1483(P070) 1484Lines (P004) – (P038) contain the AsymmetricBindingAssertion which indicates that the initiator’s token 1485must be used for the message signature and the recipient’s token must be used for message encryption. 1486Lines (P006) – (P014) contain the InitiatorToken assertion. Within that assertion lines (P008) – (P012) 1487indicate that the initiator token must be an X.509 token that must be included with all messages sent to 1488the recipient. Line (P010) dictates the X.509 token must be an X.509v3 security token as described in the 1489WS-Security 1.0 X.509 Token Profile. 1490Lines (P015) – (P023) contain the RecipientToken assertion. Within that assertion lines (P017) – (P021) 1491dictate the recipient token must also be an X.509 token as described in the WS-Security 1.0 X.509 Token 1492Profile, however as stated on line (P017) it must not be included in any message. Instead, according to 1493the MustSupportKeyRefIdentitier assertion on line (P040) a KeyIdentifier must be used to identify the 1494token in any messages where the token is used. 1495Line (P034) requires the inclusion of a timestamp. 1496Line (P038) requires token protection which dictate the signature must cover the token used to generate 1497that signature. 1498Lines (P047) – (P058) contain a policy that is attached to the input message. Lines (P050) – (P052) 1499require that the body of the input message must be signed. Lines (P053) – (P055) require the body of the 1500input message must be encrypted. 1501Lines (P059) – (P070) contain a policy that is attached to the output message. Lines (P062) – (P064) 1502require that the body of the output message must be signed. Lines (P064) – (P066) require the body of 1503the output message must be encrypted. 1504An example of an input message that conforms to the above stated policy is as follows. 1505(M01) 1506(M02) 1508(M03) 1509(M04) 1510(M05) 1511(M06) 1512(M07) 1513(M08)

106ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 107Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 36 of 116 1514(M09) 1515(M010) 1516(M011) CuJd...= 1518(M012) 1519(M013) 1520(M014) 1521(M015) Hyx...= 1522(M016) 1523(M017) 1524(M018) 1525(M019) 1526(M020) 1527(M021) 1528(M022) 2007-03-26T16:53:39Z 1529(M023) 1530(M024) MIID...= 1532(M025) 1533(M026) 1534(M027) 1535(M028) 1536(M029) 1537(M030) ... 1538(M031) 1539(M032) +g0I...= 1540(M033) 1541(M034) ... 1542(M035) .. 1543(M036) 1544(M037) RRT...= 1545(M038) 1546(M039) 1547(M040) Xeg5...= 1549(M041) 1550(M042) 1551(M043) 1552(M044) 1553(M045) 1554(M046) 1555(M047) 1557(M049) 1558(M050) 1559(M051) W84fn...1 1560(M052)

109ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 110Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 37 of 116 1561(M053) 1562(M054) 1563 (M055) 1564Line (M018) is an encryption data reference that references the encrypted body of the message on lines 1565(M047) – (M048). The encryption was required by the EncryptedParts assertion of the input message 1566policy. Lines (M009) – (M013) hold a KeyIdentifier of the recipient’s token used to encrypt the body as 1567required by the AsymmetricBindingAssertion. Because the RecipientTokenAssertion disallowed the token 1568from being inserted into the message, a KeyIdentifier is used instead of a reference to an included token. 1569Lines (M021) – (M023) contain a timestamp for the message as required by the IncludeTimestamp 1570assertion. 1571Line (M024) contains the BinarySecurityToken holding the X.509v3 certificate of the initiator as required 1572by the InitiatorToken assertion. 1573Lines (M025) – (M043) contain the message signature. 1574Line (M029) indicates the message timestamp is included in the signature as required by the 1575IncludeTimestamp assertion definition. 1576Line (M034) indicates the message body is included in the signature as required by the SignedParts 1577assertion of the input message policy. 1578Line (M035) indicates the BinarySecurityToken on Line (M024) is included in the signature as required by 1579the ProtectTokens assertion of the AsymmetricBindingAssertion policy. 1580Note that the recipient’s token is not explicitly included in the security header, as it is required not to be by 1581policy (P017). Instead a KeyIdentifier, line (M011) is used to identify the recipient’s that should be used to 1582decrypt the EncryptedData. 1583Lines (M039) – (M041) reference the initiator’s BinarySecurityToken on line (M034), which is included in 1584the message to contain the key used for verifying as dictated by the AsymmetricBindingAssertion.

112ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 113Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 38 of 116 15862.2.3 (WSS1.1) Anonymous with X.509 Certificate, Sign, Encrypt 1587This scenario is based on [WCF-PLUGFEST-INTEROP] (see also sec 2.1.4) 1588In this use case the Request is signed using DerivedKeyToken1(K), then encrypted using a 1589DerivedKeyToken2(K) where K is ephemeral key protected for the server's certificate. Response is signed 1590using DKT3(K), (if needed) encrypted using DKT4(K). The requestor does not wish to identify himself; the 1591message exchange is protected using derived symmetric keys. As a simpler, but less secure, alternative, 1592ephemeral key K (instead of derived keys) could be used for message protection by simply omitting the 1593sp:RequireDerivedKeys assertion. 1594The policy is as follows: 1595(P01) 1596(P02) 1597(P03) 1598(P04) 1599(P05) 1600(P06) 1601(P07) 1602(P08) 1604(P09) 1605(P010) 1606(P011) 1607(P012) 1608(P013) 1609(P014) 1610(P015) 1611(P016) 1612(P017) 1613(P018) 1614(P019) 1615(P020) 1616(P021) 1617(P022) 1618(P023) 1619(P024) 1620(P025) 1621(P026) 1622(P027) 1623(P028) 1624(P029) 1625(P030) 1626(P031) 1627(P032) 1628(P033) 1629(P034) 1630(P035) 1631(P036) 1632(P037) 1633(P038) 1634(P039) 1635(P040) 1636(P041) 1637(P042) 1638(P043) 1639(P044)

1641(P045) 1642(P046) 1643(P047) 1644(P048) 115ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 116Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 39 of 116 1645(P049) 1646(P050) 1647(P051) 1648(P052) 1649(P053) 1650(P054) 1651(P055) 1652(P056) 1653 1654(P057) 1655(P058) 1656(P059) 1657(P060) 1658(P061) 1659(P062) 1660(P063) 1661(P064) 1662(P065) 1663(P066) 1664(P067) 1665(P068) 1666Lines (P004) – (P030) contain the SymmetricBindingAssertion which indicates that the derived key token 1667must be used for both message signature and message encryption. 1668Lines (P007) – (P016) contain the ProtectionToken assertion. Within that assertion lines (P008) – (P014) 1669indicate that the ProtectionToken must be an X.509 token that MUST NOT be included with any message 1670sent between the Initiator and Recipient. 1671Line (P010) dictates the derived key is required. Line (P012) dictates the X.509 token must be an X.509v3 1672security token as described in the WS-Security 1.1 X.509 Token Profile. According to the 1673MustSupportRefThumbprint assertion on line (P035) and RequireThumbprintReference on line (P011), a 1674Thumbprint Reference of KeyIdentifier must be used to identify the token in any messages where the token 1675is used. 1676Line (P027) requires the inclusion of a timestamp. 1677Lines (P031) – (P039) contain some WS-Security 1.1 related interoperability requirements, specifically 1678support for key identifier, issuer serial number, thumbprint, encrypted key references, and requires 1679signature confirmation on the response. 1680 1681Lines (P043) – (P054) contain a policy that is attached to the input message. Lines (P045) – (P048) 1682require that the body of the input message must be signed. Lines (P049) – (P051) require the body of the 1683input message must be encrypted. 1684Lines (P055) – (P066) contain a policy that is attached to the output message. Lines (P057) – (P060) 1685require that the body of the output message must be signed. Lines (P061) – (P063) require the body of 1686the output message must be encrypted. 1687An example of an input message that conforms to the above stated policy is as follows. 1688Note: this message uses WS-SecureConversation as a means to meet the requirements of the policy, 1689however, aside from using the wsc:DerivedKeyToken elements to meet the policy requirements for the 1690RequireDerivedKeys assertion (P010) the general protocol mechanisms described in WS- 1691SecureConversation for SecurityContextTokens are not explicitly demonstrated.

1692(M01) 1693(M02) 1694(M03) 1695(M04) 1697(M05) 1698(M06) 1699(M07) 1700(M08) 118ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 119Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 40 of 116 1701(M09) 1702(M010) 1703(M011) c2...= 1705(M012) 1706(M013) 1707(M014) 1708(M015) TE...= 1709(M016) 1710(M017) 1711(M018) 1712(M019) wsse:SecurityTokenReference wsse11:TokenType="...#EncryptedKey"> 1713(M020) 1714(M021) 1715(M022) 0 1716(M023) 32 1717(M024) WS-SecureConversationWS-SecureConversation 1718(M025) 39...= 1719(M026) 1720(M027) 1721(M028) 1722(M029) 1723(M030) 1724(M031) 1725(M032) 1726(M033) 1727(M034) 0 1728(M035) 32 1729(M036) WS-SecureConversationWS-SecureConversation 1730(M037) ...= 1731(M038) 1732(M039) 1733(M040) 2007-03-26T23:43:13Z 1734(M041) 1735(M042) 1736(M043) 1737(M044) ... 1738(M045) ... 1739(M046) ... 1740(M047) 1741(M048) Yu...= 1742(M049) 1743(M050) 1744(M051) 1745(M052) 1746(M053) 1747(M054) 1748(M055) 1749(M056) 1750(M057) 1751(M058) 1753(M059) 1754(M060) 1755(M061) 1756(M062) 1757(M063) 1758(M064) 1759(M065) 1760(M066) p53...f 1761(M067) 1762(M068) 1763(M069) 1764 (M070) 1765 1766Lines (M005) – (M017) is the EncryptedKey information which will be reference using the WSS1.1 1767#EncryptedKey SecurityTokenReference function. Lines (M010) – (M012) is the security token reference.

121ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 122Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 41 of 116 1768Because the ProtectionToken disallowed the token from being inserted into the message, a KeyIdentifier is 1769used instead of a reference to an included token. In addition, Line (M011) the KeyIdentifier has the value 1770type of #ThumbprintSHA1 for Thumbprint Reference, it is required by the policy line (P011) of the 1771Thumbprint Reference. 1772Lines (M018) – (M022) is the first wsc:DerivedKeyToken. It is derived from the EncryptedKey of lines 1773(M005) – (M017), which is referenced using the WSS1.1 #EncryptedKey SecurityTokenReference 1774mechanism contained in lines (M019) – (M021), and used for body encryption and it is referenced on line 1775(M062). 1776Lines (M027) – (M029) is an encryption data reference that references the encrypted body of the 1777message on lines (M058) – (M068). The encryption was required by the EncryptedParts assertion of the 1778input message policy. 1779Lines (M030) – (M038) is the second wsc:DerivedKeyToken. It is derived from the EncryptedKey of lines 1780(M005) – (M017) and used for signature referenced on line (M051). 1781Lines (M039) – (M041) contain a timestamp for the message as required by the IncludeTimestamp 1782assertion. 1783Lines (M042) – (M054) contain the message signature. 1784Line (M045) indicates the message timestamp is included in the signature as required by the 1785IncludeTimestamp assertion definition. 1786Line (M046) indicates the message body is included in the signature as required by the SignedParts 1787assertion of the input message policy.

124ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 125Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 42 of 116 17882.2.4 (WSS1.1) Mutual Authentication with X.509 Certificates, Sign, Encrypt 1789This scenario is based on [WCF-PLUGFEST-INTEROP] (see also sec 2.1.4) 1790Client and server X509 certificates are used for client and server authorization respectively. Request is 1791signed using K, then encrypted using K, K is ephemeral key protected for server's certificate. Signature 1792corresponding to K is signed using client certificate. Response is signed using K, encrypted using K, 1793encrypted key K is not included in response. Alternatively, derived keys can be used for each of the 1794encryption and signature operations by simply adding an sp:RequireDerivedKeys assertion. 1795The policy is as follows: 1796 1797(P01) 1798(P02) 1799(P03) 1800(P04) 1801(P05) 1802(P06) 1803(P07) 1804(P08) 1806(P09) 1807(P010) 1808(P011) 1809(P012) 1810(P013) 1811(P014) 1812(P015) 1813(P016) 1814(P017) 1815(P018) 1816(P019) 1817(P020) 1818(P021) 1819(P022) 1820(P023) 1821(P024) 1822(P025) 1823(P026) 1824(P027) 1825(P028) 1826(P029) 1827(P030) 1828(P031) 1829(P032) 1830(P033) 1832(P034) 1833(P035) 1834(P036) 1835(P037) 1836(P038) 1837(P039) 1838(P040) 1839(P041) 1840(P042) 1841(P043) 1842(P044) 1843(P045) 1844(P046) 1845(P047)

127ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 128Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 43 of 116 1846(P048) 1847(P049) 1848(P050) 1849(P051) 1850(P052) 1851(P053) 1852 1853(P054) 1854(P055) 1855(P056) 1856(P057) 1857(P058) 1858(P059) 1859(P060) 1860(P061) 1861(P062) 1862(P063) 1863(P064) 1864(P065) 1865 1866(P066) 1867(P067) 1868(P068) 1869(P069) 1870(P070) 1871(P071) 1872(P072) 1873(P073) 1874(P074) 1875(P075) 1876(P076) 1877(P077) 1878Lines (P004) – (P030) contain the SymmetricBindingAssertion which indicates that the derived key token 1879must be used for both message signature and message encryption. 1880Lines (P007) – (P016) contain the ProtectionToken assertion. Within that assertion lines (P008) – (P014) 1881indicate that the initiator token must be an X.509 token that must not be included with all messages sent 1882between the recipient and Recipient. 1883Line (P010) dictates the derived key is required. Line (P012) dictates the X.509 token must be an X.509v3 1884security token as described in the WS-Security 1.1 X.509 Token Profile. According to the 1885MustSupportRefThumbprint assertion on line (P043) and RequireThumbprintReference on line (P011), a 1886Thumbprint Reference of KeyIdentifier must be used to identify the token in any messages where the token 1887is used. 1888Line (P027) requires the inclusion of a timestamp. 1889Lines (P031) – (P040) contain the EndorsingSupportingTokens assertion which indicates that the message 1890signature should be endorsed by client’s X509 certificate on line (P033) – (P038). Line (P033) 1891IncludeToken=".../AlwaysToRecipient" indicates the endorsing is only required when the message is sent to recipient. 1892Line (P036) dictates the X.509 token must be an X.509v3 security token as described in the WS-Security 18931.1 X.509 Token Profile. and RequireThumbprintReference on line (P035), a Thumbprint Reference of 1894KeyIdentifier must be used to identify the token in any messages where the token is used. 1895Lines (P041) – (P049) contain some WS-Security 1.1 related interoperability requirements, specifically 1896support for key identifier, issuer serial number, thumbprint, encrypted key references, and requires 1897signature confirmation on the response. 1898 1899Lines (P053) – (P064) contain a policy that is attached to the input message. Lines (P055) – (P058) 1900require that the body of the input message must be signed. Lines (P059) – (P061) require the body of the 1901input message must be encrypted.

130ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 131Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 44 of 116 1902Lines (P065) – (P076) contain a policy that is attached to the output message. Lines (P067) – (P070) 1903require that the body of the output message must be signed. Lines (P071) – (P073) require the body of 1904the output message must be encrypted. 1905An example of an input message that conforms to the above stated policy is as follows. 1906Note: this message uses WS-SecureConversation as a means to meet the requirements of the policy, 1907however, aside from using the wsc:DerivedKeyToken elements to meet the policy requirements for the 1908RequireDerivedKeys assertion (P010) the general protocol mechanisms described in WS- 1909SecureConversation for SecurityContextTokens are not explicitly demonstrated. 1910(M01) 1911(M02) 1912(M03) 1913(M04) 1914(M05) 1915(M06) 1916(M07) 1917(M08) 1918(M09) 1919(M010) 1920(M011) c2...= 1922(M013) 1923(M014) 1924(M015) 1925(M016) eI...= 1926(M017) 1927(M018) 1928(M019) MI...= 1930(M020) 1932(M021) 1933(M022) 1934(M023) 1935(M024) 0 1936(M025) 32 1937(M026) WS-SecureConversationWS-SecureConversation 1938(M027) +R...= 1939(M028) 1940(M029) 1941(M030) 2007-03-31T04:27:21Z 1942(M031) 1943(M032) 1944(M033) 1945(M034) 1946(M035) 1948(M036) 1949(M037) 1950(M038) 1951(M039) 0 1952(M040) 32 1953(M041) WS-SecureConversationWS-SecureConversation 1954(M042) wL...= 1955(M043) 1956(M044) 1957(M045) 1958(M046) ... 1959(M047) 1960(M048) ... 1961(M049) 1962(M050)

133ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 134Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 45 of 116 1963(M051) ... 1964(M052) 1965(M053) 1966(M054) abcdefg= 1967(M055) 1968(M056) 1969(M057) 1970(M058) 1971(M059) 1972(M060) 1973(M061) 1974(M062) 1975(M063) ... 1976(M064) 1977(M065) ... 1978(M066) 1979(M067) 1980(M068) hijklmnop= 1981(M069) 1982(M070) 1983(M071) Pj...= 1985(M072) 1986(M073) 1987(M074) 1988(M075) 1989(M076) 1990(M077) 1991(M078) 1993(M079) 1994(M080) 1995(M081) 1996(M082) 1997(M083) 1998(M084) 1999(M085) 2000(M086) 70...= 2001(M087) 2002(M088) 2003(M089) 2004(M090) 2005(M091) 2006 2007Lines (M005) – (M017) is the EncryptedKey information which will be reference using the WSS1.1 2008#EncryptedKey SecurityTokenReference function. Lines (M010) – (M012) is the security token reference. 2009Lines (M010) – (M012) is the security token reference. Because the ProtectionToken disallowed the token 2010from being inserted into the message, a KeyIdentifier is used instead of a reference to an included token. 2011In addition, Line (M011) the KeyIdentifier has the value type of #ThumbprintSHA1 for Thumbprint 2012Reference, and it is required by the policy line (P011) of the Thumbprint Reference. 2013Lines (M019) – (M027) is the first derived key token. It is derived from the EncryptedKey of lines (M005) – 2014(M017) and used for body encryption referenced on line (M081). 2015Lines (M028) – (M030) contain a Timestamp element for the message as required by the 2016IncludeTimestamp assertion. 2017Lines (M031) – (M033) contain an encryption data reference that references the encrypted body of the 2018message on lines (M077) – (M087). The encryption was required by the EncryptedParts assertion of the 2019input message policy. 2020Lines (M034) – (M042) is the second derived key token. It is derived from the EncryptedKey of lines 2021(M005) – (M017) and used by the signature that references it on line (M056).

136ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 137Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 46 of 116 2022Lines (M043) – (M059) contain the message signature. Lines (M054) – (M058) is its KeyInfo block that 2023indicates the second derived key token should be used to verify the message signature. 2024Line (M057) indicates the message timestamp is included in the signature as required by the 2025IncludeTimestamp assertion definition. 2026Line (M060) indicates the message body is included in the signature as required by the SignedParts 2027assertion of the input message policy. 2028Lines (M060) – (M073) contain the endorsing signature. It signs the message signature, referenced on 2029line (M063), per EndorsingSupportingTokens assertion policy requirement on lines (P031) – (P040). Line 2030(M070), the KeyIdentifier, has the value type of #ThumbprintSHA1 for Thumbprint Reference, and it is 2031required by the policy line (P035) of the Thumbprint Reference. 2032 2033An example of an output message that conforms to the above stated policy follows: 2034 2035(R01) 2036(R02) 2037(R03) 2038(R04) 2039(R05) 2007-03-31T04:27:25Z 2040(R06) 2041(R07) 2042(R08) 2043(R09) nazB6DwNC9tcwFsghoSYWXLf2wk= 2045(R011) 2046(R012) 0 2047(R013) 24 2048(R014) NfSNXZLYAA8mocQz19KWjg== 2049(R015) 2050(R016) 2051(R017) 2052(R018) nazB6DwNC9tcwFsghoSYWXLf2wk= 2054(R020) 2055(R021) lF/CtyQ9d1Ro8E3+uZYmgQ== 2056(R022) 2057(R023) 2058(R024) 2059(R025) 2060(R026) 2062(R028) 2064(R030) 2065(R031) 2066(R032) 2068(R034) 2070(R036) 2071(R037) ... 2072(R038) 2073(R039) 2074(R040) ... 2075(R041) 2076(R042) 2077(R043) ... 2078(R044) 2079(R045) 2080(R046) ... 2081(R047) 2082(R048) 2083(R049) 3rAxsfJ2LjF7liRQX2EH/0DBmzE= 2084(R050) 2085(R051) 2086(R052) 139ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 140Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 47 of 116 2087(R053) 2088(R054) 2089(R055) 2090(R056) 2091(R057) 2092(R058) 2093(R059) 2095(R061) 2096(R062) 2097(R063) 2098(R064) 2099(R065) 2100(R066) 2101(R067) 2102(R068) y+eV...pu 2103(R069) 2104(R070) 2105(R071) 2106(R072) 2107 2108Lines (R001)-(R072) contain the Response message returned to the Initiator. 2109Lines (R004)-(R006) contain the Timestamp required by the Policy (P027). 2110Lines (R007)-(R015) and (R016)-(R022) contain the information necessary for the Initiator to derive the 2111keys using the WS-SecureConversation shared secret, the identified key (R010) for DK1 and (R019) for 2112DK2, which reference the same key, and the Nonce (R014) for DK1 and (R021) for DK2, which are 2113different for the two derived keys. 2114Lines (R023)-(R025) contain a ReferenceList that indicates the message Body (R058) contains the data 2115to be encrypted. The encryption was required by the output policy (P079). 2116Lines (R026)-(R027) contain the SignatureConfirmation for the SignatureValue in the request message 2117(M054) which was required to be included by the policy (P047) RequireSignatureConfirmation. 2118Lines (R028)-(R029) contain the SignatureConfirmation for the 2nd SignatureValue in the request 2119message (M068), which is also required by the policy (P047). 2120Lines (R030)-(R055) contain the response message signature that covers the Timestamp element 2121(R039)->(R004) required to be signed by the policy (P027), the two SignatureConfirmation elements 2122(R042)->(R026) and (R045)->(R028), which are required to be signed because they are required 2123elements of the policy (P047), and the message Body (R036)->(R058), which is required to be signed by 2124the output message policy (P076). The signature may be verified using derivedKeyToken1 as indicated 2125on line (R052). 2126Lines (R059)-(R070) contain the encrypted data as required by the policy (P079) and may be decrypted 2127using derivedKeyToken2 as indicated on line (R064).

142ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 143Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 48 of 116 21282.3 SAML Token Authentication Scenario Assertions 2129For SAML, the combination of SAML and WSS version numbers is supported (WssSamlV11Token10, 2130WssSamlV11Token11, WssSamlV20Token11). 2131Instead of explicitly including the SAML Assertion, a wsse:KeyIdentifier reference can also be used. To 2132enable this last behavior, the IncludeToken attribute is set to http://docs.oasis-open.org/ws-sx/ws- 2133securitypolicy/200512/IncludeToken/Never. 2134In all of the SAML scenarios, the SAML Assertion ConfirmationMethod expected to be used by the 2135Initiator is communicated implicitly by the context of the sp: security binding in use and type of sp: 2136element containing the SamlToken. There are 3 general SAML ConfirmationMethod use cases covered: 2137holder-of-key (hk), sender-vouches (sv), and bearer (br). 2138 2139 For the holder-of-key case, there is always a contained reference (or value) in the SAML 2140 Assertion to key material that may be used for message protection in the scenario. The hk case 2141 can be assumed if the WssSamlV**Token** element appears either in the sp:InitiatorToken 2142 element of the sp:AsymmetricBinding element, or in the sp:ProtectionToken element of the 2143 sp:SymmetricBinding element. In the sp:TransportBinding case, if the WssSamlV**Token** 2144 element appears in an sp:EndorsingSupportingTokens or sp:SignedEndorsingSupportingTokens 2145 element, the SAML Assertion type can also be assumed to be hk. 2146 The sender-vouches case can be assumed if the WssSamlV**Token** version will always 2147 appear in an sp:SignedSupportingTokens element to indicate that the SAML Authority associated 2148 with this token is the Initiator that signs the message. 2149 The bearer case can be assumed if the WssSamlV**Token** version appears in an 2150 sp:SupportingTokens element (it may be signed as a SignedPart, but it is not involved in the 2151 message protection). 2152 2153It is recognized that other uses cases might exist, where these guidelines might need further elaboration 2154in order to address all contingencies, however that is outside the scope of the current version of this 2155document. 2156 Note: in the discussions below the term “SamlToken” or “SamlToken assertion” refers to the 2157 policy requirement that a “SAML Assertion” be used as that token. 2158 Note: SAML Assertions have issuers. In addition, these Assertions are generally signed with an 2159 X509 certificate. In general, the SAML IssuingAuthority may be regarded as the Subject of the 2160 X509 certificate, which is trusted by a RelyingParty. In general, as well, there is usually a known 2161 mapping between the Issuer identified within the SAML Assertion and the Subject of the X509 2162 certificate used to sign that Assertion. It will be assumed in this document that the SAML 2163 IssuingAuthority may be identified by either of these identities and that, in general, a RelyingParty 2164 will check the details as necessary. 2165The concept of the sp:”message signature” within the context of the sp:TransportBinding is not clearly 2166identified within the current version of [WS-SecurityPolicy], however, there are certain inferences that are 2167used in the use cases that follow that are identified here for reference. 2168  Based on the diagrams in section 8 of [WS-SecurityPolicy], which show messages with a 2169 “message signature” followed by a diagram showing use of transport security the only difference 2170 is that the message signature diagrams contain a block labelled “Sig1”, which is the message 2171 signature, and the transport security diagrams do not have this block. 2172  Considering the fact that when [SSL] Client Certificates are used for client authentication, that the 2173 client uses the client certificate private key to sign hash of SSL handshake messages in an SSL 2174 CertificateVerify message that is part of the SSL protocol, the assumption is made that 2175 subsequent data sent by the client on this link is effectively protected for the purposes of data

145ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 146Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 49 of 116 2176 integrity and confidentiality, and that the data sent on the link is authorized to be sent by the 2177 holder of the private key associated with the client certificate. 2178  Based on the considerations in the bullets above, and with intention of maintaining functional 2179 consistency with the WS-SecurityPolicy notions of sp: message signature, 2180 sp:SignedSupportingTokens, and sp:SignedEndorsingSupportingTokens, use of client certicates 2181 with SSL will be considered equivalent to having a “virtual message signature” provided by the 2182 Initiator’s client certificate which covers all the data in the SOAP request that the Initiator sends 2183 on the SSL link. 2184  As such, in the above context, the client certificate may be regarded as providing both a virtual 2185 Signing function for tokens and Timestamp that appear in the wsse:Security header, as well as a 2186 virtual Endorsing function for tokens that contain the client certificate or a reference to the client 2187 certificate that appear in the wsse:Security header. 2188The net effect of the above assumptions for the SAML use cases in this section that use the 2189sp:TransportBinding is that if a client certifcate is required to be used with the sp:HttpsToken 2190assertion then: 2191 1. A SAML sender-vouches Assertion contained in a wsse:Security header block may be 2192 considered to be an sp:SignedSupportingToken when used in an sp:TransportBinding 2193 using an sp:HttpsToken assertion that contains an sp:RequireClientCertificate assertion, 2194 because the client certificate is being used as the IssuingAuthority behind the SAML 2195 sender-vouches Assertion, which requires the IssuingAuthority to sign the combined 2196 message and Assertion. 2197 2. A SAML holder-of-key Assertion contained in a wsse:Security header block may be 2198 considered to be an sp:SignedEndorsingSupportingToken when used in an 2199 sp:TransportBinding using an sp:HttpsToken assertion that contains an 2200 sp:RequireClientCerfticate assertion AND that the either the client certificate or a 2201 reference to it is contained in the saml:SubjectConfirmationData/ds:KeyInfo element of 2202 the SAML holder-of-key Assertion. 2203 3. A SAML bearer Assertion contained in a wsse:Security header block may only be 2204 considered to be an sp:SupportingToken, because they are only “incidentally” covered 2205 by the virtual message signature as a “pass through” token provided by the Requestor to 2206 be evaluated by the Recipient that is being “passed through” by the Initiator, but which 2207 the Initiator takes no responsibility. 2208Ultimately, the responsibilities associated with the granting access to resources is determined by the 2209agreements between RelyingParties and IssuingAuthorities. Those agreements need to take into 2210consideration the security characteristics of the bindings which support access requests as to what kind of 2211bindings are required to “adequately protect” the requests for the associated business purposes. These 2212examples are intended to show how SAML Assertions can be used in a variety of WS-SecurityPolicy 2213contexts and how the different SAML token types (hk, sv, bearer) may be used in different configurations 2214relating the IssuingAuthority, the Requestor, the Initiator, the Recipient, and the RelyingParty. 2215 2216

148ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 149Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 50 of 116 22172.3.1 WSS 1.0 SAML Token Scenarios

22182.3.1.1 (WSS1.0) SAML1.1 Assertion (Bearer) 2219Initiator adds a SAML assertion (bearer) representing the Requestor to the SOAP security header. 2220Since the SamlToken is listed in the SupportingTokens element, it will not explicitly be covered by a 2221message signature. The Initiator may infer that a Saml Bearer Assertion is acceptable to meet this 2222requirement, because the Initiator is not required to explicitly cover a SupportingToken with a signature. 2223The SAML assertion itself could be signed. The IssuingAuthority in this scenario is the Issuer (and signer, 2224if the Assertion is signed) of the SAML Assertion. The Initiator simply passes the token through and is not 2225actively involved in the trust relationship between the IssuingAuthority that issued the SAML Assertion 2226and the Requestor who is the Subject of the SAML Assertion. 2227This scenario might be used in a SAML Federation application where a browser-based user with a SAML 2228Assertion indicating that user’s SSO (Single Sign On) credential has submitted a request to a portal using 2229the Assertion as a credential (either directly or indirectly via a SAML Artifact [SAML11]), and the portal as 2230Initiator is generating a web service request on behalf of this user, but the trust that the Recipient has for 2231the Requestor is based on the Assertion and its IssuingAuthority, not the Initiator who delivered the 2232request. 2233 2234 (P01) 2235 (P02) 2236 (P03) 2237 (P04) 2239 (P05) 2240 (P06) 2241 (P07) 2242 (P08) 2243 (P09) 2244 (P010) 2245 (P011) 2246 2247Lines (P001)-(P011) contain the endpoint wsp:Policy, which contains no bindings because none is 2248required to access the service protected by this policy, however the service does require that the 2249Requestor provide a Supporting Token in the sp:SupportingTokens element (P002)-(P010), which must 2250be an sp:SamlToken (P004)-(P008), which must be an sp:WssSamlV11Token10 (P006), which means 2251that the SamlToken must be a SAML 1.1 saml:Assertion that is sent in compliance with the 2252[WSS10-SAML11-PROFILE]. 2253As explained in section 2.3 above, the fact that the sp:SamlToken is simply in an sp:SupportingTokens 2254element indicates to the Initiator that a SAML bearer Assertion is what is expected to accompany the 2255request. 2256The following is a sample request taken from [WSS11-SAML1120-PROFILE] that complies with the 2257WSS 1.0 compatible policy above 2258 2259 (M01) 2260 (M02) 2261 (M03) 2262 (M04) 2268 (M010) 151ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 152Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 51 of 116 2269 (M011) 2270 (M012) 2273 (M015) uid=joe,ou=people,ou=saml-demo,o=baltimore.com 2274 (M016) 2275 (M017) 2276 (M018) 2277 (M019) urn:oasis:names:tc:SAML:1.0:cm:bearer 2278 (M020) 2279 (M021) 2280 (M022) 2281 (M023) 2282 (M024) 2283 (M025) 2284 (M026) 2285 (M027) 2286 (M028) . . . 2287 (M029) 2288 (M030) 2289 2290Lines (M001)-(M030) contains the SOAP:Envelope, which contains the SOAP:Header (M002)-(M026) and 2291the SOAP:Body (M027)-(M029). 2292The SOAP Header contains a wsse:Security header block (M003)-(M025) which simply contains the 2293saml:Assertion. 2294The saml:Assertion (M004)-(M024) is Version 1.1 (M008)-(M009), which is required by the policy 2295sp:WssSamlV11Token10 assertion (P006). The Assertion contains a saml:AuthenticationStatement 2296(M010)-(M023) that contains a saml:NameIdentifier (M012)-(M016) that identifies the saml:Subject, who is 2297the Requestor (who submitted the request from a browser) and it contains a saml:SubjectConfirmation 2298element (M017)-(M021), which specifies the saml:ConfirmationMethod to be “bearer” (M019), which 2299meets the policy requirement (P006). 2300For general context to relate this scenario to Figure 1, the Requestor at a browser will have obtained 2301either the saml:Assertion above or an Artifact identifying that Assertion from an IssuingAuthority and sent 2302it to the portal in the context of some request the Requestor is trying to make. The portal recognizes that 2303to meet the needs of this request that it must invoke a web service that has publicized the policy above 2304(P001)-(P011). Therefore, the portal will now take on the role of Initiator (Fig 1) and assemble a SOAP 2305request (M001)-(M030) and submit it to the service as described in detail above.

154ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 155Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 52 of 116 23062.3.1.2 (WSS1.0) SAML1.1 Assertion (Sender Vouches) over SSL 2307This scenario is based on first WSS SAML Profile InterOp [WSS10-SAML11-INTEROP Scenario #2 2308section 4.4.4] 2309Initiator adds a SAML Assertion (sv) to the SOAP Security Header. Because the TransportBinding 2310requires a Client Certificate AND the SAML token is in a SignedSupportingTokens element, when the 2311Initiator uses the Client Certificate to protect the message under SSL, the Initiator may be considered as 2312effectively “signing” the SAML sv Assertion and acting as a SAML Authority (i.e. the issuer of the sv 2313Assertion). By including the sv assertion in the header and using the Client Certificate to protect the 2314message, the Initiator takes responsibility for binding the Requestor, who is the Subject of the Assertion to 2315the contents of the message. 2316 Note: because SSL does not retain cryptographic protection of the message after the message is 2317 delivered, messages protected using only this mechanism cannot be used as the basis for 2318 non-repudiation. 2319 2320 (P01) 2322 (P02) 2323 (P03) 2324 (P04) 2325 (P05) 2326 (P06) 2327 (P07) 2328 (P08) 2329 (P09) 2330 (P010) 2331 (P011) 2332 (P012) 2333 (P013) 2334 (P014) 2335 (P015) 2336 (P016) 2337 (P017) 2338 (P018) 2339 (P019) 2340 (P020) 2341 (P021) 2342 (P022) 2343 (P023) 2344 (P024) 2345 (P025) 2346 (P026) 2347 (P027) 2348 (P028) 2350 (P029) 2351 (P030) 2352 (P031) 2353 (P032) 2354 (P033) 2355 (P034) 2356 (P035) 2357 2358Lines (P002)-(P025) contain a TransportBinding assertion that indicates the message must be protected 2359by a secure transport protocol such as SSL or TLS.

157ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 158Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 53 of 116 2360Lines (P004)-(P012) contain a TransportToken assertion indicating that the transport is secured by means 2361of an HTTPS TransportToken, requiring cryptographic operations to be performed based on the transport 2362token using the Basic256 algorithm suite (P015). 2363In addition, because this is SAML sender-vouches, a client certificate is required (P008) as the basis of 2364trust for the SAML Assertion and for the content of the message [WSS10-SAML11-INTEROP section 23654.3.1]. 2366The layout requirement in this case (P018)-(P022) is automatically met (or may be considered moot) 2367since there are no cryptographic tokens required to be present in the WS-Security header. 2368A timestamp (P023) is required to be included in an acceptable message. 2369Lines (P026)-(P034) contain a SignedSupportingTokens assertion, which indicates that the referenced 2370token is effectively “signed” by the combination of usage of the client certificate for SSL authentication 2371and the cryptographic protection of SSL. However, the “signed” characteristic will not be present after the 2372message is delivered from the transport layer to the recipient. 2373Lines (P028)-(P032) indicate the signed token is a SAML Assertion (sender-vouches as described above 2374in section 2.3) and on line (P030) that it is a SAML 1.1 Assertion and that the WS-Security 1.0 SAML 2375Profile [WSS10-SAML11-PROFILE] is being used. 2376This scenario is based on first WSS SAML Profile InterOp [WSS10-SAML11-INTEROP “Scenario #2 - 2377Sender-Vouches: Unsigned: SSL” section 4.4.4] 2378Here is the example request from that scenario: 2379 (M01) 2380 (M02) 2388 (M010) 2389 (M011) 2390 (M012) 2391 (M013) 2003-03-18T19:53:13Z 2392 (M014) 2393 (M015) 2399 (M021) 2402 (M024) 2406 (M028) 2407 (M029) 2410 (M032) uid=joe,ou=people,ou=saml-demo,o=example.com 2411 (M033) 2412 (M034) 2413 (M035) 2414 (M036) urn:oasis:names:tc:SAML:1.0:cm:sender-vouches 2415 (M037) 2416 (M038) 2417 (M039) 160ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 161Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 54 of 116 2418 (M040) 2419 (M041) 2420 (M042) 2421 (M043) 2422 (M044) 2423 (M045) 2424 (M046) EchoString 2425 (M047) 2426 (M048) 2427 (M049) 2428 2429Lines (M011)-(M042) contain the WS-Security 1.0 header required by the WssSamlV11Token10 2430assertion (P030). 2431Lines (M012)-(M014) contain the wsu:Timestamp required by IncludeTimestamp assertion (P023). 2432Lines (M015)-(M041) contain the SAML 1.1 Assertion required by the WssSamlV11Token10 assertion 2433(P030). 2434Note that the additional requirements identified in the policy above are met by the SSL transport 2435capabilities and do not appear in any form in the SOAP message (M001)-(M049).

163ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 164Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 55 of 116 24362.3.1.3 (WSS1.0) SAML1.1 Assertion (HK) over SSL 2437Initiator adds a SAML assertion (hk) to the SOAP Security Header. Because the TransportBinding 2438requires a Client Certificate AND the SAML token is in an EndorsingSupportingTokens element, the 2439Initiator may be considered to be authorized by the issuer of the hk SAML assertion to bind message 2440content to the Subject of the assertion. If the Client Certificate matches the certificate identified in the hk 2441assertion, the Initiator may be regarded as executing SAML hk responsibility of binding the Requestor, 2442who would be the Subject of the hk assertion, to the content of the message. 2443In this scenario, the IssuingAuthority is the issuer(signer) of the hk SAML Assertion. The Requestor is the 2444Subject of the Assertion and the Initiator is authorized by the Authority to bind the Assertion to the 2445message using the ClientCertificate identified in the SAML Assertion, which should also be used to sign 2446the timestamp of the message with a separate Signature included in the WS-Security header. 2447 2448 (P01) > 2450 (P03) 2451 (P04) 2452 (P05) 2453 (P06) 2454 (P07) 2455 (P08) 2456 (P09) 2457 (P010) 2458 (P011) 2459 (P012) 2460 (P013) 2461 (P014) 2462 (P015) 2463 (P016) 2464 (P017) 2465 (P018) 2466 (P019) 2467 (P020) 2468 (P021) 2469 (P022) 2470 (P023) 2471 (P024) 2472 (P025) 2473 (P026) 2474 (P027) 2475 (P028) 2476 (P029) 2478 (P030) 2479 (P031) 2480 (P032) 2481 (P033) 2482 (P034) 2483 (P035) 2484 (P036) 2485 2486Section 2.3.2.3 contains an example message that is similar to one that could be used for the policy 2487above, except the Signed Endorsing Supporting Token there is a SAML Version 2.0 token, and a SAML 2488Version 1.1 token would be required here.

166ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 167Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 56 of 116 24892.3.1.4 (WSS1.0) SAML1.1 Sender Vouches with X.509 Certificates, Sign, Optional 2490 Encrypt 2491This scenario is based on the first WSS SAML Profile InterOp [WSS10-SAML11-INTEROP Scenario #3]. 2492In this case, the SAML token is included as part of the message signature and sent only to the Recipient. 2493The message security is provided using X.509 certificates with both requestor and service having 2494exchanged these credentials via some out of band mechanism, which provides the basis of trust of each 2495others’ certificates. 2496In this scenario the SAML Authority is the Initiator who uses the message signature to both provide the 2497integrity of the message and to establish the Initiator as the SAML Authority based on the X509 certificate 2498used to sign the message and the SignedSupportingTokens SAML Assertion. Effectively, the SAML 2499Assertion is being “issued” as part of the message construction process. The Requestor is the Subject of 2500the SAML Assertion. The Initiator knows that the Recipient is expecting it to be the SAML Authority by the 2501fact that the policy specifies that the message requires a SignedSupportingTokens SamlToken. 2502 2503 (P01) 2505 (P03) 2506 (P04) 2507 (P05) 2508 (P06) 2509 (P07) 2510 (P08) 2511 (P09) 2513 (P010) 2514 (P011) 2515 (P012) 2516 (P013) 2517 (P014) 2518 (P015) 2519 (P016) 2520 (P017) 2521 (P018) 2523 (P019) 2524 (P020) 2525 (P021) 2526 (P022) 2527 (P023) 2528 (P024) 2529 (P025) 2530 (P026) 2531 (P027) 2532 (P028) 2533 (P029) 2534 (P030) 2535 (P031) 2536 (P032) 2537 (P033) 2538 (P034) 2539 (P035) 2540 (P036) 2541 (P037) 2542 (P038) 2543 (P039) 2544 (P040) 2545 (P041) 2546 (P042) 169ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 170Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 57 of 116 2547 (P043) 2548 (P044) 2549 (P045) 2550 (P046) 2552 (P047) 2553 (P048) 2554 (P049) 2555 (P050) 2556 (P051) 2557 (P052) 2558 (P053) 2559 (P054) 2560 (P055) 2561 (P056) 2562 (P057) 2563 (P058) 2564 (P059) 2565 (P060) 2566 (P061) 2567 (P062) 2568 (P063) 2569 (P064) 2570 (P065) 2571 (P066) 2572 (P067) 2573 (P068) 2574 2575 (P069) 2576 (P070) 2577 (P071) 2578 (P072) 2579 (P073) 2580 (P074) 2581 (P075) 2582 (P076) 2583 (P077) 2584 (P078) 2585 (P079) 2586 (P080) 2587Line (P004) is a wsp:All element whose scope carries down to line (P053), which means all 3 of the 2588contained assertions: (P005)-(P038) AsymmetricBinding, (P039)-(P043) WSS10, and (P044)-(P052) 2589SignedSupportingTokens must be complied with by message exchanges to a Web Service covered by 2590this policy. 2591Lines (P005)-(P038) contain an AsymmetricBinding assertion which indicates that the Initiator’s token 2592must be used for the message signature and that the recipient’s token must be used for message 2593encryption. 2594Lines (P007)-(P015) contain the InitiatorToken assertion. Within the InitiatorToken assertion, lines 2595(P009)-(P013) indicate that the Initiator’s token must be an X509Token that must always be included as 2596part of the request message (as opposed to an external reference). Line (P011) indicates that the X509 2597token must be an X.509 V3 signature-verification certificate and used in the manner described in 2598[WSS10-X509-PROFILE]. 2599Lines (P016)-(P023) contain the RecipientToken assertion. Again, this an X.509 V3 certificate (P020) that 2600must be used as described in [WSS10-X509-PROFILE], however the token itself, must never be included 2601in messages in either direction (P018). 2602Instead (momentarily skipping slightly ahead), policy lines (P039)-(P043), the WSS10 assertion, indicate 2603that the Recipient’s token must be referenced by a KeyIdentifier element, which is described in the WS- 2604Security 1.0 core specification [WSS10-SOAPMSG].

172ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 173Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 58 of 116 2605Lines (P025)-(P029) contain the AlgorithmSuite assertion, which specifies the sp:Basic256 set of 2606cryptographic components. The relevant values for this example within the sp:Basic256 components are 2607the asymmetric signing algorithm, ds:rsa-sha1, and the digest algorithm, ds:sha1, where “ds:” = 2608“http://www.w3.org/2000/09/xmldsig# “ [XML-DSIG]. 2609Lines (P030)-(P034) contain the sp:Layout assertion, which is set to sp:Strict (P032), which governs the 2610required relative layout of various Timestamp, Signature and Token elements in the messages. 2611Line (P035) IncludeTimestamp means a Timestamp element must be included in the WS-Security header 2612block and signed by the message signature for messages in both directions. 2613Line (P036) OnlySignEntireHeaderAndBody indicates that the message signature must explicitly cover 2614the SOAP:Body element (not children), and if there are any signed elements in the SOAP:Header they 2615must be direct child elements of the SOAP:Header. However, the one exception where the latter condition 2616is not applied is that if the child of the SOAP:Header is a WS-Security header (i.e. a wsse:Security 2617element), then individual direct child only elements of that Security element may also be signed. 2618Lines (P044)-(P052) contain a SignedSupportingTokens assertion, which contains only one token 2619(P046)-(P050), a SamlToken, which must always be sent to the Recipient (P046) and it must be a 2620SAML 1.1 Assertion token. Because the SamlToken is in a “SignedSupportingTokens” element, it is 2621implicitly a SAML sender-vouches ConfirmationMethod token as described in section 2.3 above. 2622Lines (P057)-(P068) contain a policy that applies only to input messages from the Initiator to the 2623Recipient. 2624Lines (P060)-(P062) specify that the SOAP:Body element of the input message must be signed by the 2625Initiator’s message signature. 2626Lines (P063)-(P065) specify that the SOAP:Body element of the input message may optionally be 2627encrypted (signified by wsp:Optional=”true”) using the Recipient’s encryption token (in this case (P020), it 2628is an X.509 certificate). 2629Lines (P069)-(P080) contain a policy that applies only to output messages from the Recipient to the 2630Initiator. 2631Lines (P072)-(P074) specify that the SOAP:Body element of the output message must be signed by the 2632Recipient’s message signature. 2633Lines (P075)-(P077) specify that the SOAP:Body element of the output message must be encrypted by 2634the Initiator’s encryption token (in this case (P012), it is also an X.509 certificate). 2635Here is an example request: 2636 2637 (M01) 2638 (M02) 2648 (M012) 2649 (M013) 2650 (M014) 2651 (M015) 2003-03-18T19:53:13Z 2652 (M016) 2653 (M017)

175ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 176Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 59 of 116 2659 (M023) 2662 (M026) 2663 (M027) 2664 (M028) 2667 (M031) uid=joe,ou=people,ou=saml-demo,o=example.com 2668 (M032) 2669 (M033) 2670 (M034) 2671 (M035) urn:oasis:names:tc:SAML:1.0:cm:sender-vouches 2672 (M036) 2673 (M037) 2674 (M038) 2675 (M039) 2676 (M040) ... 2677 (M041) 2678 (M042) ... 2679 (M043) 2680 (M044) 2681 (M045) 2682 (M046) 2685 (M048) _a75adf55-01d7-40cc-929f-dbd8372ebdfc 2686 (M049) 2687 (M050) 2688 (M051) 2694 (M057) MIIEZzCCA9CgAwIBAgIQEmtJZc0... 2695 (M058) 2696 (M059) 2697 (M060) 2698 (M061) 2700 (M063) 2702 (M065) 2703 (M066) 2704 (M067) 2707 (M070) 2708 (M071) 2710 (M073) 2711 (M074) 2712 (M075) 2713 (M076) 2715 (M078) ... 2716 (M079) 2717 (M080) 2718 (M081) 2720 (M083) ... 2721 (M084)

178ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 179Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 60 of 116 2722 (M085) 2723 (M086) 2725 (M088) ... 2726 (M089) 2727 (M090) 2728 (M091) HJJWbvqW9E84vJVQk... 2729 (M092) 2730 (M093) 2731 (M094) 2732 (M095) 2733 (M096) 2734 (M097) 2735 (M098) 2736 (M099) 2737 (M0100) 2738 (M0101) 2739 (M0102) SUNW 2740 (M0103) 2741 (M0104) 2742 (M0105) 2743 2744 Note: For the instructional purposes of this document, in order to be compliant with WS- 2745 SecurityPolicy, this copy of the original message had to be modified from the original. In particular, 2746 the modifications that are applied above are the inclusion of a wsu:Id attribute in the Timestamp 2747 element start tag (M014) and the addition of a ds:Reference element and URI attribute identifying 2748 that Timestamp element in the message signature (M085)-(M089). (The original message in 2749 [WSS10-SAML11-INTEROP scenario #3] is not compliant with WS-SecurityPolicy because the 2750 Timestamp that it contains is not covered by the message signature in that document.) 2751Lines (M002)-(M0105) contain the SOAP:Envelope, i.e. the whole SOAP message. 2752Lines (M012)-(M099) contain the SOAP:Header, which is the header portion of the SOAP message. 2753Lines (M0100)-(M0104) contain the SOAP:Body, which is just some dummy content for test purposes. 2754Lines (M013)-(M098) contain the wsse:Security header, which is the primary focus of this example. 2755Lines (M014)-(M016) contain the wsu:Timestamp, which is required by the policy (P035). 2756Lines (M017)-(M044) contain the SAML Assertion, which is the sp:SamlToken required by the policy 2757sp:SignedSupportingTokens (P046)-(P050). 2758Lines (M021)-(M022) identify the SAML Assertion as being Version 1.1 as required by the policy (P048). 2759Line (M035) identifies the SAML Assertion as having ConfirmationMethod sender-vouches, which is the 2760implicit requirement of the sp:SamlToken being in the SignedSupportingTokens as described above in the 2761policy section covering (P044)-(P052). 2762Lines (M045)-(M050) contain a wsse:SecurityTokenReference which contains a wsse:KeyIdentifier, which 2763is used to reference the SAML Assertion, as described in [WSS10-SAML11-PROFILE] and required by 2764the policy (P041). 2765Lines (M051)-(M058) contain the Initiator’s wsse:BinarySecurityToken, which is required by the policy 2766(P007)-(P015), and in particular lines (M053)-(M054) identify the token as an X.509 V3 token as required 2767by the policy (P011). Line (M057) contains a truncated portion of the Base64 representation of the actual 2768certificate, which is included in the message as required by the policy sp:IncludeToken (P009). 2769Lines (M059)-(M0102) contain the ds:Signature, which is the sp: message signature as required by 2770various parts of the Endpoint Policy (P001)-(P055) and Input Message Policy (P057)-(P068). 2771Lines (M060)-(M095) contain the ds:SignedInfo element which describes the signing algorithm used 2772(M064) and specific elements that are signed (M065)-(M094) as required by the policies, which are 2773described in detail immediately following.

181ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 182Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 61 of 116 2774Lines (M061)-(M062) contain the ds:CanonicalizationMethod Algorithm, which is specified as xml-exc- 2775c14n#, which is the default value required by the policy sp:AlgorithmSuite (P025)-(P029). 2776Line (M064) identifies the SignatureMethod Algorithm as ds:rsa-sha1, which is the asymmetric key 2777signing algorithm required by the policy sp:AlgorithmSuite (P025)-(P029). 2778Lines (M065)-(M079) identify the SAML Assertion (M017)-(M044) as an element that is signed, which is 2779referenced through the URI “#STR1” on line (M065), which references the SecurityTokenReference 2780(M045)-(M050), which in turn uses the identifier on line (M048) to reference the actual SAML Assertion by 2781its AssertionID attribute on line (M018). The SAML Assertion is required to be signed because it is 2782identified in the policy within the SignedSupportingTokens element on line (P048). 2783Lines (M077)-(M078) contain the digest algorithm, which is specified to be sha1, as required by the policy 2784sp:Basic256 assertion (P027) in the sp:AlgorithmSuite. 2785Lines (M080)-(M084) identify the SOAP:Body (M0100)-(M0104) as an element that is signed, which is 2786referenced through the URI “#MsgBody” on line (M080). The SOAP Body is required to be signed by the 2787input message policy lines (P060)-(P062). 2788Lines (M085)-(M089) identify the wsu:Timestamp (M014)-(M016) as an element that is signed, which is 2789referenced throught the URI “#timestamp” on line (M085). The wsu:Timestamp is required to be signed by 2790the policy sp:IncludeTimestamp assertion (P035). Note that the wsu:Timestamp occurs in the 2791wsse:Security header prior to the ds:Signature as required by the sp:Strict layout policy (P032). 2792Finally, lines (M092)-(M096) contain the ds:KeyInfo element that identifies the signing key associated with 2793this ds:Signature element. The actual signing key is referenced through the 2794wsse:SecurityTokenReference (M093)-(M095), with URI “#attesterCert”, which identifies the 2795InitiatorToken identified by the policy (P011) and contained in the wsse:BinarySecurityToken element 2796(M051)-(M058), which occurs in the wsse:Security header prior to this ds:Signature element, as required 2797by the sp:Strict layout policy assertion (P032). (Note: this BinarySecurityToken would need to be included 2798in the signature, if the sp:AsymmetricBinding assertion in the endpoint policy contained a 2799sp:ProtectTokens assertion, but it does not, so it does not need to be signed.) 2800

184ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 185Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 62 of 116 28012.3.1.5 (WSS1.0) SAML1.1 Holder of Key, Sign, Optional Encrypt 2802This example is based on the first WSS SAML Profile InterOp [WSS10-SAML11-INTEROP Scenario #4]. 2803In this example the SAML token provides the key material for message security, hence acts as the 2804Initiator token, and therefore the Requestor and Initiator may be considered to be the same entity. The 2805SAML HK Assertion contains a reference to the public key of the signer of the message (the Initiator). The 2806Initiator knows Recipient's public key, which it may use to encrypt the request, but the Initiator does not 2807share a direct trust relation with the Recipient except indirectly throught the SAML Assertion Issuer. The 2808Recipient has a trust relation with the Authority that issues the SAML HK Assertion The indirect trust 2809relation between the Recipient and the Initiator is established by the fact that the Initiator’s public key has 2810been signed by the Authority in the SAML HK Assertion. On the request the message body is signed 2811using Initiator’s private key referenced in the SAML HK Assertion and it is optionally encrypted using 2812Recipient’s server certificate. On the response, the server signs the message using its private key and 2813encrypts the message using the key provided within SAML HK Assertion. 2814 HK Note: there is a trust model aspect to the WS-Security holder-of-key examples that 2815 implementors may want to be aware of. The [SAML20-CORE] specification defines the Subject of 2816 the SAML Assertion such that the “presenter” of the Assertion is the entity that “attests” to the 2817 information in the Assertion. “The attesting entity and the actual Subject may or may not be the 2818 same entity.” In general, these two choices map to the actors in Figure 1 as follows: the 2819 “attesting” entity may be regarded as the Initiator. The Subject entity, about whom the information 2820 in the Assertion applies, may be regarded as the Requestor. In the case where the Subject and 2821 attestor are one and the same, the Initiator and Requestor may be regarded as one and the 2822 same. In this case the potential exists to use the Assertion for non-repudiation purposes with 2823 respect to messages that the Requestor/Initiator signs. When the Subject and attestor are 2824 separate entities, then holder-of-key is more similar to sender-vouches where the Initiator/attestor 2825 is sending the message on behalf of the Subject. The mechanisms for determining whether the 2826 Subject and attestor may be verified to be the same entity are dependent on the arrangements 2827 among the business entities and the structure of the associated application scenarios. 2828 2829 (P01) 2831 (P03) 2832 (P04) 2833 (P05) 2834 (P06) 2835 (P07) 2836 (P08) 2837 (P09) 2839 (P010) 2840 (P011) 2841 (P012) 2842 (P013) 2843 (P014) 2844 (P015) 2845 (P016) 2846 (P017) 2847 (P018) 2849 (P019) 2850 (P020) 2851 (P021) 2852 (P022) 2853 (P023) 2854 (P024) 2855 (P025) 2856 (P026)

187ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 188Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 63 of 116 2857 (P027) 2858 (P028) 2859 (P029) 2860 (P030) 2861 (P031) 2862 (P032) 2863 (P033) 2864 (P034) 2865 (P035) 2866 (P036) 2867 (P037) 2868 (P038) 2869 (P039) 2870 (P040) 2871 (P041) 2872 (P042) 2873 (P043) 2874 (P044) 2875 (P045) 2876 (P046) 2877 (P047) 2878 (P048) 2879 (P049) 2880 (P050) 2881 (P051) 2882 (P052) 2883 (P053) 2884 (P054) 2885 (P055) 2886 (P056) 2887 (P057) 2888 (P058) 2889 (P059) 2890 (P060) 2891 (P061) 2892 (P062) 2893 (P063) 2894 (P064) 2895 (P065) 2896 (P066) 2897 (P067) 2898 (P068) 2899 (P069) 2900 (P070) 2901 (P071) 2902 (P072) 2903 (P073) 2904 (P074) 2905 (P075) 2906 (P076) 2907 (P077) 2908 2909Lines (P001)-(P046) contain the endpoint policy, and lines (P048)-(P064) and (P066)-(P077) contain the 2910message input and message output policies, respectively. 2911Lines (P005)-(P038) contain the AsymmetricBinding assertion, which requires separate security tokens 2912for the Initiator and Recipient. 2913Lines (P007)-(P015) contain the InitiatorToken, which is defined to be a SamlToken (P009)-(P013), which 2914must always be sent to the Recipient (P009). The SamlToken is further specified by the 2915WssSamlV11Token10 assertion (P011) that requires the token to be a SAML 1.1 Assertion and the token 2916must be used in accordance with the WS-Security [WSS10-SAML11-PROFILE]. Furthermore, as

190ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 191Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 64 of 116 2917described in section 2.3 above, because the SamlToken assertion appears within an InitiatorToken 2918assertion, the SAML Assertion must use the holder-of-key ConfirmationMethod, whereby for the indicated 2919WS-Security profile, the SAML Assertion contains a reference to the Initiator’s X.509 signing certificate or 2920equivalent. 2921Lines (P016)-(P024) contain the RecipientToken assertion. Again, this an X.509 V3 certificate (P020) that 2922must be used as described in [WSS10-SAML11-PROFILE], however the token itself, must never be 2923included in messages in either direction (P018) (i.e not only will the Recipient not send the token, but the 2924Initiator must not send the actual token, even when using it for encryption). 2925Lines (P025)-(P029) AlgorithmSuite and (P030)-(P034) Layout are the same as described above in 2926section 2.3.1.4. 2927Line (P035) IncludeTimestamp means a Timestamp element must be included in the WS-Security header 2928block and signed by the message signature for messages in both directions. 2929Line (P036) OnlySignEntireHeaderAndBody indicates that the message signature must explicitly cover 2930the SOAP:Body element (not children), and if there are any signed elements in the SOAP:Header they 2931must be direct child elements of the SOAP:Header. However, the one exception where the latter condition 2932is not applied is that if the child of the SOAP:Header is a WS-Security header (i.e. a wsse:Security 2933element), then individual direct child only elements of that Security element may also be signed. 2934 2935Lines (P039)-(P043) contain the WSS10 assertion, which indicates that the Recipient’s token must be 2936referenced by a KeyIdentifier element (P041), the usage of which is described in the WS-Security 1.0 2937core specification [WSS10-SOAPMSG]. 2938Lines (P048)-(P064) contain the message input policy that applies only to messages from the Initiator to 2939the Recipient. 2940Lines (P051)-(P053) specify that the SOAP:Body element of the input message must be signed by the 2941Initiator’s message signature. 2942Lines (P054)-(P061) specify that the SOAP:Body element of the input message may optionally (signified 2943by the empty policy alternative on line (P060)) be encrypted using the Recipient’s encryption token (in this 2944case (P020), it is an X.509 certificate). 2945 Note: Because the input policy above (P048-P064) has the EncryptedParts assertion 2946 (P056-P058) contained in an element (P054-P061), which also contains an empty 2947 policy element (P060), either a message with an encrypted Body element or an unencrypted 2948 Body element will be accepted. 2949Lines (P066)-(P077) contain a message output policy that applies only to messages from the Recipient to 2950the Initiator. 2951Lines (P069)-(P071) specify that the SOAP:Body element of the output message must be signed by the 2952Recipient’s message signature. 2953Lines (P072)-(P074) specify that the SOAP:Body element of the output message must be encrypted by 2954the Initiator’s encryption token (in this case (P012), it is also an X.509 certificate). 2955 2956The following example request is taken from the [WSS10-SAML11-INTEROP] document scenario #4: 2957 2958 (M01) 2959 (M02)

193ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 194Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 65 of 116 2968 (M011) 2969 (M012) 2970 (M013) 2971 (M014) 2003-03-18T19:53:13Z 2972 (M015) 2973 (M016) 2980 (M023) 2983 (M026) 2984 (M027) 2985 (M028) 2988 (M031) uid=joe,ou=people,ou=saml-demo,o=example.com 2989 (M032) 2990 (M033) 2991 (M034) 2992 (M035) urn:oasis:names:tc:SAML:1.0:cm:holder-of-key 2993 (M036) 2994 (M037) 2995 (M038) ... 2996 (M039) 2997 (M040) 2998 (M041) 2999 (M042) 3003 (M046) gold 3004 (M047) 3005 (M048) 3009 (M052) [email protected] 3010 (M053) 3011 (M054) 3012 (M055) ... 3013 (M056) 3014 (M057) 3015 (M058) 3016 (M059) 3018 (M061) 3020 (M063) 3021 (M064) 3023 (M066) GyGsF0Pi4xPU... 3024 (M067) 3025 (M068) 3026 (M069) 3028 (M071) ... 3029 (M072) 3030 (M073)

196ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 197Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 66 of 116 3031 (M074) HJJWbvqW9E84vJVQk... 3032 (M075) 3033 (M076) 3034 (M077) 3037 (M080) _a75adf55-01d7-40cc-929f-dbd8372ebdfc 3038 (M081) 3039 (M082) 3040 (M083) 3041 (M084) 3042 (M085) 3043 (M086) 3044 (M087) 3045 (M088) 3046 (M089) SUNW 3047 (M090) 3048 (M091) 3049 (M092) 3050 3051 Note: for the instructional purposes of this document, it was necessary to make changes to the 3052 original sample request to meet the requirements of WS-SecurityPolicy. The changes to the 3053 message above include: 3054  Line (M013): added wsu:Id=”timestamp” attribute to sp:Timestamp element. 3055  Lines (M068)-(M072): added a ds:Reference element to include the Timestamp in the 3056 message signature required by the policy sp:IncludeTimestamp assertion (P035). 3057Lines (M002)-(M092) contain the SOAP Envelope, i.e. the whole SOAP message. 3058Lines (M011)-(M086) contain the SOAP Header. 3059Lines (M087)-(M091) contain the unencrypted SOAP Body, which is allowed to be unencrypted based on 3060line (P060) of the input message policy, which is the alternative choice to encrypting based on lines 3061(P055)-(P059). 3062Lines (M012)-(M080) contain the wsse:Security header entry, which is the only header entry in this SOAP 3063Header. 3064Lines (M013)-(M015) contain the wsu:Timestamp which is required by the endpoint policy (P035). 3065Lines (M016)-(M056) contain the SAML Assertion, which is required in the policy by the SamlToken 3066(P009)-(P013) contained in the InitiatorToken. The SAML Assertion is version 1.1 (M020)-(M021) as 3067required by the sp:WssSamlV11Token10 assertion (P011). The SAML Assertion is of type that uses the 3068holder-of-key saml:ConfirmationMethod [SAML11-CORE] (M034)-(M036) as required by the fact that the 3069SamlToken is contained in the InitiatorToken assertion of the policy (P009)-(P013), as explained in 3070section 2.3 above. 3071Line (M055) contains the ds:Signature of the Issuer of the SAML Assertion. While the details of this 3072signature are not shown, it is this signature that the Recipient must ultimately trust in order to trust the rest 3073of the message. 3074Lines (M057)-(M084) contain the message signature in a ds:Signature element. 3075Lines (M058)-(M073) contain the ds:SignedInfo element, which identifies the elements to be signed. 3076Lines (M063)-(M067) contains a ds:Reference to the SOAP:Body, which is signed in the same manner as 3077example section 2.3.1.4 above. 3078Lines (M068)-(M072) contains a ds:Reference to the URI “timestamp”, which again is signed in the same 3079manner as the wsu:Timestamp in section 2.3.1.4 above. 3080Lines (M075)-(M083) contain the ds:KeyInfo element, which identifies the key that should be used to 3081verify this ds:Signature element. Lines (M076)-(M082) contain a wsse:SecurityTokenReference, which 3082contains a wsse:KeyIdentifier that identifies the signing key as being contained in a token of

199ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 200Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 67 of 116 3083wsse:ValueType “…wss-saml-token-profile-1.0#SAMLAssertionID”, which means a SAML V1.1 Assertion 3084[WSS10-SAML11-PROFILE]. Line (M080) contains the saml:AssertionID of the SAML Assertion that 3085contains the signing key. This SAML Assertion is on lines (M016)-(M056) with the correct 3086saml:AssertionID on line (M017). Note that the fact that the referenced token (the SAML Assertion) occurs 3087in the wsse:Security header before this ds:KeyInfo element that uses it in compliance with the sp:Strict 3088layout policy (P032) and the wsse:KeyIdentifier is an acceptable token reference mechanism as specified 3089in the policy sp:Wss10 assertion containing a sp:MustSupportRefKeyIdentifier assertion (P041).

202ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 203Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 68 of 116 30902.3.2 WSS 1.1 SAML Token Scenarios 3091This section contains SamlToken examples that use WS-Security 1.1 SOAP Message Security [WSS11] 3092and the WS-Security 1.1 SAML Profile [WSS11-SAML1120-PROFILE].

30932.3.2.1 (WSS1.1) SAML 2.0 Bearer 3094This example is based on the Liberty Alliance Identity Web Services Framework (ID-WSF 2.0) Security 3095Mechanism for the SAML 2.0 Profile for WSS 1.1 [WSS11-LIBERTY-SAML20-PROFILE], which itself is 3096based on the [WSS11-SAML1120-PROFILE]. 3097In this example, an AsymmetricBinding is used for message protection provided by the Initiator, however, 3098Recipient trust for the content is based only on the SAML bearer token provided by the Requestor. 3099 3100 (P01) 3101 (P02) 3102 (P03) 3103 (P04) 3104 (P05) 3105 (P06) 3107 (P07) 3108 (P08) 3109 (P09) 3110 (P010) 3111 (P011) 3112 (P012) 3113 (P013) 3114 (P014) 3115 (P015) 3117 (P016) 3118 (P017) 3119 (P018) 3120 (P019) 3121 (P020) 3122 (P021) 3123 (P022) 3124 (P023) 3125 (P024) 3126 (P025) 3127 (P026) 3128 (P027) 3129 (P028) 3130 (P029) 3131 (P030) 3132 (P031) 3133 (P032) 3134 (P033) 3135 (P034) 3136 (P035) 3137 (P036) 3138 (P037) 3139 (P038) 3140 (P039) 3141 (P040) 3142 (P041) 3143 (P042) 3144 (P043) 3145 (P044) 3146 (P045) 205ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 206Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 69 of 116 3147 (P046) 3149 (P047) 3150 (P048) 3151 (P049) 3152 (P050) 3153 (P051) 3154 (P052) 3155 (P053) 3156Lines (P001)-(P045) contain the endpoint policy, which contains 3 assertions: an sp:AsymmetricBinding 3157assertion, an sp:Wss11 assertion, and an sp:SupportingTokens assertion. 3158Lines (P002)-(P035) contain the sp:AsymmetricBinding assertion, which is identical to the same assertion 3159that is described in section 2.1.3. Please refer to section 2.1.3 for details. 3160Lines (P036)-(P043) contain an sp:Wss11 assertion, which contains a set of assertions that specify the 3161token referencing techniques that are required to be supported (P038)-(P041). 3162Lines (P044)-(P052) contain an sp:SupportingTokens assertion, which contains an sp:SamlToken 3163(P046)-(P050), which specifies that it must always be sent to the Recipient. The sp:SamlToken contains 3164an sp:WssSamlV20Token11 assertion (P048), which means that the SamlToken provided must be a 3165SAML Version 2.0 Assertion that is submitted in compliance with the [WSS11-SAML1120-PROFILE]. 3166The fact that the sp:SamlToken is contained in an sp:SupportingTokens element indicates to the Initiator 3167that the SAML Assertion must use the saml2:SubjectConfirmation@Method “bearer” as described above 3168in introductory section 2.3. 3169The following is an example request compliant with the above policy: 3170 3171 (M01) 3172 (M02) 3176 (M06) 3177 (M07) 3178 (M08) ... 3179 (M09) ... 3180 (M010) ... 3181 (M011) 3182 (M012) 3183 (M013) 2005-06-17T04:49:17Z 3184 (M014) 3185 (M015) 3186 (M016) 3189 (M019) http://authority.example.com/ 3190 (M020) 3191 (M021) ... 3192 (M022) 3193 (M023) 3194 (M024) U2XTCNvRX7Bl1NK182nmY00TEk== 3196 (M026) ... 3197 (M027) 3198 (M028) 3200 (M030) 3201 (M031) 3203 (M033)

208ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 209Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 70 of 116 3205 (M035) 3206 (M036) http://wsp.example.com 3207 (M037) 3208 (M038) 3209 (M039) 3211 (M041) 3213 (M043) 3214 (M044) ...:SAML:2.0:ac:classes:PasswordProtectedTransport 3216 (M046) 3217 (M047) 3218 (M048) 3219 (M049) 3224 (M054) 3225 (M055) 3226 (M056) 3228 (M058) mQEMAzRniWkAAAEH9RWir0eKDkyFAB7PoFazx3ftp0vWwbbzqXdgcX8 3229 (M059) ... hg6nZ5c0I6L6Gn9A=HCQY 3230 (M060) 3231 (M061) ... 3232 (M062) 3233 (M063) 3234 (M064) 3235 (M065) 3237 (M067) 3240 (M070) sxJu9g/vvLG9sAN9bKp/8q0NKU= 3243 (M073) 3244 (M074) 3245 (M075) 3246 (M076) 3249 (M079) ... 3250 (M080) ... 3251 (M081) ... 3252 (M082) ... 3253 (M083) 3254 (M084) 3255 (M085) 3256 (M086) 3258 (M088) 3259 (M089) 3260 (M090) 3261 (M091) ... 3262 (M092) 3263 (M093) ... 3264 (M094) 3265 (M095) 3266 (M096) 3267 (M097)

211ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 212Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 71 of 116 3268 (M098) 3269 (M099) 3270 (M0100) 3271 (M0101) 3272 (M0102) 3273 3274The sample message above was taken and cosmetically edited from the [WSS11-LIBERTY-SAML20- 3275PROFILE]. 3276Lines (M002)-(M0102) contain the SOAP:Envelope, which contains the SOAP:Header (M006)-(M096) 3277and the SOAP:Body (M097)-(M0101). 3278The SOAP Header contains some WS-Addressing (wsa:) parameters (M008)-(M010) (not discussed 3279here) and a wsse:Security header. 3280The wsse:Security header (M011)-(M095) contains a wsu:Timestamp (M012)-(M014), a saml2:Assertion 3281(M016)-(M064), a wsse:SecurityTokenReference (M067)-(M073), and a ds:Signature (M074)-(M094). 3282The wsu:Timestamp (M012)-(M014) is required by the policy sp:IncludeTimestamp assertion (P032). 3283The saml2:Assertion (M016)-(M064) is required by the policy sp:WssSamlV20Token11 (P048). The 3284saml2:Assertion is Version 2.0 (M017) and it is signed by the IssuingAuthority (M021). This is the 3285ds:Signature (M021) of the IssuingAuthority, identified in the saml2:Issuer element (M019), that the 3286Recipient trusts with respect to recognizing the Requestor and determining whether the request should be 3287granted. In addition, this saml2:Assertion uses the “bearer” saml2:SubjectConfirmation@Method, as 3288required by the policy sp:SamlToken in the sp:SupportingTokens element described above 3289(P044)-(P052). 3290 Note: the saml2:Assertion contains a saml2:EncryptedID (M023)-(M027), which contains the 3291 identity of the Requestor and a saml2:EncryptedAttribute (M062), which contains information 3292 about the Requestor. It is presumed that prior to issuing this request, that the Requestor 3293 contacted the IssuingAuthority (directly or indirectly) and was granted permission to access the 3294 web service that is now the target of this request. As such, the IssuingAuthority has knowledge of 3295 this web service and presumably the public certificate associated with that service and has used 3296 the public key contained in that certificate to encrypt the aforementioned portions of the 3297 saml2:Assertion, which can only be decrypted by the RelyingParty who presumably has entrusted 3298 the private key of the service with the Recipient, in order that the Recipient may decrypt the 3299 necessary data. 3300However, before the Recipient can evaluate these aspects of the request, the requirements of the policy 3301sp:AsymmetricBinding (P002)-(P035) must be met in terms of proper “presentation” of the request as 3302described below. 3303Lines (M074)-(M094) contain the message signature ds:Signature element, which contains a 3304ds:SignedInfo that contains ds:Reference elements that cover the wsa: headers (M079)-(M081), the 3305wsu:Timestamp (M082) (required by the policy sp:IncludeTimestamp assertion (P032), the 3306saml2:Assertion (M083)-(M090), and the SOAP:Body (M091). 3307The ds:Reference (M083)-(M090) covering the saml2:Assertion warrants further examination. 3308 The first point to note is that to reference the saml2:Assertion the ds:Reference uses an STR- 3309 Transform (M084) to reference a wsse:SecurityTokenReference (M067)-(M073), which is in 3310 compliance with policy sp:Wss11 sp:MustSupportRefKeyIdentifier assertion (P038). 3311 The second point to note about this ds:Reference is that is covering the saml2:Assertion even 3312 though the policy references the sp:SamlToken in an sp:SupportingTokens element and not an 3313 sp:SignedSupportingTokens element. The reason this is the case is that it is the fact that an 3314 sp:SupportingTokens (P044)-(P052) element is used that tells the Initiator that a SAML bearer 3315 Assertion is required. However, this only means that the SamlToken is not “required” to be 3316 signed. It is the Initiator’s choice whether to sign it or not, and it is generally good practice to do 3317 so in order to prevent a token substitution attack. 3318

214ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 215Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 72 of 116 33192.3.2.2 (WSS1.1) SAML2.0 Sender Vouches over SSL 3320This scenario is based on second WSS SAML Profile InterOp [WSS11-SAML1120-INTEROP Scenario 3321#2]. 3322Similar to 2.3.1.2 except SAML token is of version 2.0. 3323 3324 3325 (P01) 3326 (P02) 3327 (P03) 3328 (P04) 3329 (P05) 3330 (P06) 3331 (P07) 3332 (P08) 3333 (P09) 3334 (P010) 3335 (P011) 3336 (P012) 3337 (P013) 3338 (P014) 3339 (P015) 3340 (P016) 3341 (P017) 3342 (P018) 3343 (P019) 3344 (P020) 3345 (P021) 3346 (P022) 3347 (P023) 3348 (P024) 3349 (P025) 3350 (P026) 3351 (P027) 3352 (P028) 3354 (P029) 3355 (P030) 3356 (P031) 3357 (P032) 3358 (P033) 3359 (P034) 3360 (P035) 3361Lines (P001)-(P035) contain the policy that requires all the contained assertions to be complied with by 3362the Initiator. In this case there are 2 assertions: sp:TransportBinding (P002) and 3363sp:SignedSupportingTokens (P026). 3364Lines (P002)-(P025) contain a TransportBinding assertion that indicates the message must be protected 3365by a secure transport protocol such as SSL or TLS. 3366Lines (P004)-(P012) contain a TransportToken assertion indicating that the transport is secured by means 3367of an HTTPS TransportToken, requiring cryptographic operations to be performed based on the transport 3368token using the Basic256 algorithm suite (P015). 3369In addition, because this is SAML sender-vouches, a client certificate is required (P008) as the basis of 3370trust for the SAML Assertion and for the content of the message [WSS10-SAML11-INTEROP section 33714.3.1]. 3372The requirements for the sp:Layout assertion (P018)-(P022) should be automatically met (or may be 3373considered moot) since there are no cryptographic tokens required to be present in the WS-Security

217ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 218Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 73 of 116 3374header. (However, if a signature element was included to cover the wsse:Timestamp, then the layout 3375would need to be considered.) 3376A timestamp (P023) is required to be included in an acceptable message. 3377 3378Here is an example request: 3379 3380 (M01) 3381 (M02) 3387 (M08) 3388 (M09) 3389 (M010) 3390 (M011) 2005-03-18T19:53:13Z 3391 (M012) 3392 (M013) 3394 (M015) www.opensaml.org 3395 (M016) 3397 (M018) 3398 (M019) uid=joe,ou=people,ou=saml demo,o=example.com 3401 (M022) 3403 (M024) 3404 (M025) 3405 (M026) ... 3406 (M027) ... 3407 (M028) 3408 (M029) 3409 (M030) 3410 (M031) 3411 (M032) 3412 (M033) 3413 (M034) EchoString 3414 (M035) 3415 (M036) 3416 (M037) 3417Lines (M002)-(M037) contain the SOAP:Envelope, which contains the SOAP:Header (M003)-(M031) and 3418the SOAP:Body (M032)-(M036). 3419Lines (M009)-(M030) contain the wsse:Security header, which, in conjunction with the client 3420certificate (P008), is the primary basis for trust in this example. 3421Lines (M010)-(M012) contain the wsu:Timestamp, which meets the sp:IncludeTimestamp assertion policy 3422requirement (P023). 3423Lines (M013)-(M029) contain the saml2:Assertion, which is required to be Version 2.0 (M014) and to be 3424used within the [WSS11-SAML1120-PROFILE], because of the policy sp:SamlToken assertion 3425(P028)-(P032), which contains the sp:WssSamlV20Token11 (P030). 3426Lines (M022)-(M023) indicate that the SAML Assertion uses the saml2:Method sender-vouches for the 3427purposes of saml2:SubjectConfirmation, which is required by the fact that the sp:SamlToken appears in 3428an sp:SignedSupportingTokens assertion (P026)-(P034) in conjunction with the client certificate required 3429by the sp:RequireClientCertificate asertion (P008) within the sp:TransportBinding as described in section

220ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 221Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 74 of 116 34302.3 above. In addition, the Recipient should be able to correlate the saml2:Issuer (M015) as being 3431properly associated with the client certficate received from the HTTPS (SSL) connection. 3432

223ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 224Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 75 of 116 34332.3.2.3 (WSS1.1) SAML2.0 HoK over SSL 3434This scenario is based on second WSS SAML Profile InterOp [WSS11-SAML1120-INTEROP 3435Scenario #5]. 3436Similar to 2.3.1.3 except SAML token is of version 2.0. 3437Initiator adds a SAML Assertion (hk) to the SOAP Security Header. In this policy the sp:TransportBinding 3438requires a Client Certificate AND the sp:SamlToken is in an sp:SignedEndorsingSupportingTokens 3439element. A SAML holder-of-key Assertion meets these requirements because it is “virtually signed” by the 3440message signature as a result of the SSL client certificate authentication procedure as described in 3441section 2.3. Furthermore, the SAML hk Assertion in this case is a “virtually endorsing”, because the key 3442identified in the holder-of-key saml2:SubjectConfirmationData is also the client certificate, which is 3443virtually endorsing its own signature, under the authority of the IssuingAuthority who has signed the SAML 3444hk Assertion. 3445As a result, the Initiator may be considered to be authorized by the saml2:Issuer of the hk SAML 3446Assertion to bind message content to the Subject of the Assertion. If the Client Certificate matches the 3447certificate identified in the hk Assertion, the Initiator may be regarded as executing SAML hk responsibility 3448of binding the Requestor, who would be the Subject of the hk Assertion, to the content of the message. 3449 (Note: the same considerations described in section 2.3.1.4 with respect to whether the Subject 3450 of the Assertion and the Subject of the Client Certificate are the same entity determining whether 3451 the Client Certificate is attesting for the Assertion Subject or whether the Client Certificate is 3452 authenticating as the Assertion Subject apply here.) 3453In this scenario, the IssuingAuthority is the saml2:Issuer(signer) of the hk SAML Assertion. The Requestor 3454is the Subject of the Assertion and the Initiator is authorized by the IssuingAuthority to bind the Assertion 3455to the message using the ClientCertificate identified in the SAML Assertion, which may also be 3456considered to be virtually signing the wsu:Timestamp of the message. Optionally, a separate Signature 3457may be used to sign the wsu:Timestamp, which the Recipient would also be required to verify was signed 3458by the client certificate in this example. 3459 3460 (P01) 3461 (P02) 3462 (P03) 3463 (P04) 3464 (P05) 3465 (P06) 3466 (P07) 3467 (P08) 3468 (P09) 3469 (P010) 3470 (P011) 3471 (P012) 3472 (P013) 3473 (P014) 3474 (P015) 3475 (P016) 3476 (P017) 3477 (P018) 3478 (P019) 3479 (P020) 3480 (P021) 3481 (P022) 3482 (P023) 3483 (P024) 3484 (P025) 3485 (P026) 3486 (P027)

226ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 227Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 76 of 116 3487 (P028) 3489 (P029) 3490 (P030) 3491 (P031) 3492 (P032) 3493 (P033) 3494 (P034) 3495 (P035) 3496 3497Lines (P001)-(P035) contain the policy that requires all the contained assertions to be complied with by 3498the Initiator. In this case there are 2 assertions: sp:TransportBinding (P002) and 3499sp:EndorsingSupportingTokens (P026). 3500Lines (P002)-(P025) contain a TransportBinding assertion that indicates the message must be protected 3501by a secure transport protocol such as SSL or TLS. 3502Lines (P004)-(P012) contain a TransportToken assertion indicating that the transport is secured by means 3503of an HTTPS TransportToken, requiring cryptographic operations to be performed based on the transport 3504token using the Basic256 algorithm suite (P015). 3505In addition, because this is SAML holder-of-key, a client certificate is required (P008) as the basis of trust 3506for the SAML Assertion and for the content of the message [WSS10-SAML11-INTEROP section 4.3.1]. In 3507the holder-of-key case, there will be an additional certificate required in the trust chain, which is the 3508certificate used to sign the SAML hk Assertion, which will be contained or referenced in the Assertion. 3509The layout requirement in this case (P018)-(P022) is automatically met (or may be considered moot) 3510since there are no cryptographic tokens required to be present in the WS-Security header. (However, if a 3511signature element was included to cover the wsse:Timestamp, then the layout would need to be 3512considered.) 3513A timestamp (P023) is required to be included in an acceptable message. 3514Lines (P026)-(P034) contain an sp:SignedEndorsingSupportingTokens element, which means that the 3515contained supporting token (the SAML hk Assertion) references a key that will be “signing” (endorsing) 3516the message signature. The token itself may also be considered to be “signed”, because it is contained in 3517the message sent over the SSL link. In the case of sp:TransportBinding, there may be no actual 3518“message signature”, however, when a client certificate is used, the service can be assured that the 3519connection was set up by the client and that the SSL link guarantees the integrity of the data that is sent 3520on the link by the client, while it is on the link and when it is received from the link by using the key 3521referenced by the token. However, it does not guarantee the integrity after the data is received (i.e. after it 3522is received there is no way to tell whether any changes have been made to it since it has been received). 3523In any event, within this context a Signed Endorsing Supporting Token can be used to tell the Recipient 3524that the Issuer of the token is making claims related to the holder of the private key that is referenced by 3525the token, which in this case would be the private key associated with the client certificate used to set up 3526the SSL link, as described further below. 3527Lines (P028)-(P032) contain an sp:SamlToken, which must always be sent to the Recipient. 3528Line (P030) specifies that the token is of type WssSamlV20Token11, which means that the Endorsing 3529Supporting Token must be a SAML Version 2.0 token and it must be sent using WS-Security 1.1 using 3530the [WSS11-SAML1120-PROFILE]. Note that because the SamlToken is contained in an 3531sp:EndorsingSupportingTokens element, that it implicitly must be a holder-of-key token as described in 3532section 2.3 above. 3533Here is an example request taken from the WSS SAML Profile InterOp [WSS11-SAML1120-INTEROP 3534Scenario #5] containing only minor cosmetic modifications and corrections. 3535 3536 (M01) 3537 (M02)

229ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 230Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 77 of 116 3540 (M05) xmlns:xsd="http://www.w3.org/2001/XMLSchema" 3541 (M06) xmlns:wsu=".../oasis-200401-wss-wssecurity-utility-1.0.xsd" 3542 (M07) xmlns:wsse=".../oasis-200401-wss-wssecurity-secext-1.0.xsd" 3543 (M08) xmlns:wsse11=".../oasis-wss-wssecurity-secext-1.1.xsd" 3544 (M09) xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 3545 (M010) xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"> 3546 (M011) 3547 (M012) 3548 (M013) 3549 (M014) 2005-03-18T19:53:13Z 3550 (M015) 3551 (M016) 3553 (M018) www.opensaml.org 3554 (M019) 3555 (M020) 3556 (M021) 3558 (M023) 3560 (M025) 3561 (M026) 3562 (M027) 3564 (M029) 3566 (M031) 3569 (M034) 3570 (M035) 3571 (M036) 3573 (M038) Kclet6XcaOgOWXM4gty6/UNdviI= 3575 (M040) 3576 (M041) 3577 (M042) 3578 (M043) hq4zk+ZknjggCQgZm7ea8fI79gJEsRy3E8LHDpYXWQIgZpkJN9CMLG8ENR4Nrw+n 3579 (M044) 7iyzixBvKXX8P53BTCT4VghPBWhFYSt9tHWu/AtJfOTh6qaAsNdeCyG86jmtp3TD 3580 (M045) MwuL/cBUj2OtBZOQMFn7jQ9YB7klIz3RqVL+wNmeWI4= 3581 (M046) 3582 (M047) 3583 (M048) 3584 (M049) 3585 (M050) MIICyjCCAjOgAwIBAgICAnUwDQYJKoZIhvcNAQEEBQAwgakxCzAJBgNVBAYTAlVT 3586 (M051) ... 3587 (M052) 8I3bsbmRAUg4UP9hH6ABVq4KQKMknxu1xQxLhpR1ylGPdiowMNTrEG8cCx3w/w== 3588 (M053) 3589 (M054) 3590 (M055) 3591 (M056) 3592 (M057) 3594 (M059) 3595 (M060) uid=joe,ou=people,ou=saml-demo,o=example.com 3598 (M063) 3600 (M065) 3602 (M067)

232ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 233Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 78 of 116 3603 (M068) 3604 (M069) 3605 (M070) C=ZA, ST=Western Cape, L=Cape Town, 3606 (M071) O=Thawte Consulting cc, 3607 (M072) OU=Certification Services Division, 3608 (M073) CN=Thawte Server CA/[email protected] 3609 (M074) 3610 (M075) 12345678 3611 (M076) 3612 (M077) 3613 (M078) 3614 (M079) 3615 (M080) 3616 (M081) 3617 (M082) gold 3618 (M083) 3619 (M084) 3620 (M085) [email protected] 3622 (M087) 3623 (M088) 3624 (M089) 3625 (M090) 3626 (M091) 3627 (M092) 3628 (M093) 3629 (M094) SUNW 3630 (M095) 3631 (M096) 3632 (M097) 3633Lines (M002)-(M097) contain the SOAP:Envelope, which contains the SOAP:Header (M011)-(M091) and 3634the SOAP:Body (M092)-(M096). 3635Lines (M012)-(M090) contain the wsse:Security header, which contains a wsu:Timestamp (M013)-(M015) 3636and a saml2:Assertion (M016)-(M089). 3637The wsu:Timestamp (M013)-(M015) may be considered to be virtually signed by the client certificate as 3638explained above and in section 2.3. 3639The saml2:Assertion was issued by an IssuingAuthority identified in the saml2:Issuer element (M018). 3640The saml2:Issuer has used the private key of its enterprise certificate to produce the ds:Signature 3641element (M019)-(M056) that is an enveloped-signature (M028) that covers its parent XML element, the 3642saml2:Assertion (M016)-(M089). The ds:KeyInfo (M047)-(M055) within this ds:Signature contains an 3643actual copy of the Issuer’s enterprise certificate, that the Recipient can verify for authenticity to establish 3644that this message is in conformance with any agreement the RelyingParty may have with the 3645IssuingAuthority. The details of this verification are outside the scope of this document, however they 3646involve the structures and systems the RelyingParty has in place recognize and verify certificates and 3647signatures it receives that are associated with business arrangements with the holders of the private keys 3648of those certificates. 3649The saml2:Subject of the saml2:Assertion is contained in lines (M059)-(M079). Within the saml2:Subject 3650is the saml2:NameID (M060)-(M062), which contains the official name of the Subject of this Assertion and 3651this entity may be considered to the Requestor associated with this request. 3652The saml2:SubjectConfirmation (M063)-(M064) has Method “holder-of-key” which implies that there is a 3653saml2:SubjectConfirmationData element (M065)-(M078) which will contain information that identifies a 3654signing key that the Initiator will use to bind this saml2:Assertion to a message that is associated with the 3655Requestor. In this context, the Initiator is acting as “attesting entity” with respect to the Subject as defined 3656in [SAML20], which means that the Initiator is authorized by the IssuingAuthority to present 3657saml2:Assertions pertaining to saml2:Subjects to Recipients/RelyingParties. In this example there is a 3658ds:KeyInfo (M067)-(M077) that identifies a specific certificate (ds:X509IssuerName (M069)-(M074) and 3659ds:SerialNumber (M075)) that the Initiator must prove possession of the associated private key to verify

235ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 236Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 79 of 116 3660this message. In this policy that private key is the one associated with the client certificate that the Initiator 3661is required to use (P008). 3662The saml2:AttributeStatement (M080)-(M088) contains some information about the Subject that is 3663officially being provided in this saml2:Assertion by the IssuingAuthority that may have some significance 3664to the Relying Party in terms of determining whether access is granted for this request. 3665

238ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 239Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 80 of 116 36662.3.2.4 (WSS1.1) SAML1.1/2.0 Sender Vouches with X.509 Certificate, Sign, 3667 Encrypt 3668Here the message and SAML Assertion are signed using a key derived from the ephemeral key K. The 3669ephemeral key is encrypted using the Recipient’s public key for the request input message and the same 3670shared ephemeral key, K, is encrypted using the Initiators public key for the response output message. 3671Alternatively, derived keys can be used for each of signing and encryption operations. 3672In this scenario the Authority is the Initiator who signs the message with the generated key. In order to 3673establish trust in the generated key, the Initiator must sign the message signature with a second signature 3674using an X509 certificate, which is indicated as the EndorsingSupportingToken. This X509 certificate 3675establishes the Initiator as the SAML Authority. 3676(Note: there are instructive similarities and differences between this example and example 2.3.1.4, where 3677the difference is that: here the binding is symmetric and the WSS1.1 is used, whereas in 2.3.1.4 the 3678binding is asymmetric and WSS1.0 is used. One particular item is that in 2.3.1.4 an 3679EndorsingSupportingToken is not needed because in 2.3.1.4 the asymmetric binding uses X.509 3680certificates, which may be inherently trusted as opposed to the ephemeral key, K, used here.) 3681 3682 (P01) 3683 (P02) 3684 (P03) 3685 (P04) 3686 (P05) 3687 (P06) 3688 (P07) 3689 (P08) 3694 (P012) 3695 (P013) 3696 (P014) 3697 (P015) 3698 (P016) 3699 (P017) 3700 (P018) 3701 (P019) 3702 (P020) 3703 (P021) 3704 (P022) 3705 (P023) 3706 (P024) 3707 (P025) 3708 (P026) 3709 (P027) 3710 (P028) 3711 (P029) 3712 (P030) 3713 (P031) 3714 (P032) 3715 (P033) 3717 (P034) 3718 (P035) 3719 (P036) 3720 (P037) 3721 (P038) 3722 (P039)

241ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 242Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 81 of 116 3723 (P040) 3724 (P041) 3725 (P042) 3726 (P043) 3727 (P044) 3728 (P045) 3729 (P046) 3730 (P047) 3731 (P048) 3732 (P049) 3733 (P050) 3734 (P051) 3735 (P052) 3736 (P053) 3737 (P054) 3738 (P055) 3739 (P056) 3740 (P057) 3741 (P058) 3742 (P059) 3743 (P060) 3744 (P061) 3745 (P062) 3746 (P063) 3747 (P064) 3748 (P065) 3749 (P066) 3750 (P067) 3751 (P068) 3752 (P069) 3753 (P070) 3754 (P071) 3755 (P072) 3756 (P073) 3757 (P074) 3758 (P075) 3759 (P076) 3760 (P077) 3761 (P078) 3762 (P079) 3763 (P080) 3764 (P081) 3765 (P082) 3766 (P083) 3767 (P084) 3768 (P085) 3769Lines (P001)-(P059) contain the policy that requires all the contained assertions to be complied with by 3770the Initiator. In this case there are 4 assertions: sp:SymmetricBinding (P004)-(P030), 3771sp:SignedSupportingTokens (P031)-(P039), sp:EndorsingSupportingTokens (P040)-(P048), and 3772sp:Wss11 (P049)-(P056). 3773The sp:SymmetricBinding assertion (P004) contains an sp:ProtectionToken (P006)-(P016), which 3774indicates that both the Initiator and Recipient must use the public key associated with the X509Token 3775(P008)-(P014) associated with the message receiver to encrypt the shared ephemeral symmetric key as 3776explained at the beginning of this section. The messages may either be encrypted and signed using keys 3777derived from the ephemeral key as indicated by the sp:RequireDerivedKeys assertion (P011) or the 3778encryption and signing can be done using the ephemeral key itself without deriving keys, because the 3779RequireDerivedKey assertion is an optional requirement as indicated by the wsp:Optional attribute on line 3780(P011). 3781The sp:SignedSupportingTokens assertion (P031) contains an sp:SamlToken assertion (P033)-(P037), 3782which indicates that a signed SAML Assertion must always be included in the Initiator’s request to the

244ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 245Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 82 of 116 3783Recipient (AlwaysToRecipient (P033)). This SAML Assertion must be included in the WS-Security header 3784and referenced and signed as described in the WS-Security 1.1 Profile for SAML [WSS11-SAML1120- 3785PROFILE] as indicated by the sp:WssSamlV11Token11 assertion (P036), which indicates the SAML 1.1 3786option in that profile (as opposed to the SAML 2.0 option, which would have been indicated by 3787sp:WssSamlV20Token11). 3788The sp:EndorsingSupportingToken assertion (P040) is needed because there are no guarantees that the 3789ephemeral key, K, is still being used by the Initiator with whom the Recipient would have collaborated 3790originally to establish the ephemeral key as a shared secret. The purpose of the endorsing token is to 3791sign the signature made by the ephemeral key, using the Initiator’s private key, which will explicitly 3792guarantee the content of this particular Initiator request. The endorsing token in this policy is an 3793sp:X509Token (P042)-(P046), which, in particular, is an sp:WssX509V3Token11, which must be used in 3794accordance with the WS-Security 1.1 Profile for X509 Tokens [WSS11-X509-PROFILE]. (Note: it may be 3795the case that this X509 certificate is the same X509 certificate referred to in the ProtectionToken assertion 3796(P012). However, it is important to keep in mind that line (P012) only indicates that the Initiator’s token will 3797be used by the Recipient to protect the ephemeral key. Therefore, the fact that the token is identified in 3798line (P012) as sp:X509V3Token10 (as opposed to …Token11) is not significant in that context, because 3799all that is relevant is that it is X509 V3 TBD – verify). 3800There are also 2 Policys, one each for the input message and the output message, each of which 3801contains an assertion indicating the message SOAP Body must be signed (P064)-(P066) for the input 3802message and (P077)-(P079) for the output message, and each contains an assertion the message SOAP 3803Body must be encrypted (P067)-(P069) for the input message and (P080)-(P082) for the output message. 3804The following is a sample request that is compliant with this policy. 3805 (M01) 3806 (M02) 3817 (M011) 3818 (M012) 3819 (M013) 3820 (M014) 2003-03-18T19:53:13Z 3821 (M015) 3822 (M016) 3823 (M017) 3824 (M018) 3825 (M019) 3826 (M020) 3827 (M021) 3828 (M022) c2...= 3830 (M023) 3831 (M024) 3832 (M025) 3833 (M026) TE...= 3834 (M027) 3835 (M028) 3836 (M029) 3837 (M030) 3838 (M031) 3839 (M032)

247ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 248Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 83 of 116 3842 (M035) Issuer="www.opensaml.org" 3843 (M036) MajorVersion="1" 3844 (M037) MinorVersion="1"> 3845 (M038) 3848 (M041) 3849 (M042) 3850 (M043) 3853 (M046) uid=joe,ou=people,ou=saml-demo,o=example.com 3854 (M047) 3855 (M048) 3856 (M049) 3857 (M050) urn:oasis:names:tc:SAML:1.0:cm:sender-vouches 3858 (M051) 3859 (M052) 3860 (M053) 3861 (M054) 3862 (M055) ... 3863 (M056) 3864 (M057) ... 3865 (M058) 3866 (M059) 3867 (M060) 3868 (M061) 3871 (M063) _a75adf55-01d7-40cc-929f-dbd8372ebdfc 3872 (M064) 3873 (M065) 3874 (M066) 3880 (M070) MIIEZzCCA9CgAwIBAgIQEmtJZc0... 3881 (M071) 3882 (M072) 3883 (M073) 3884 (M074) 3886 (M076) 3888 (M078) 3889 (M079) 3890 (M080) 3893 (M082) 3894 (M083) 3896 (M085) 3897 (M086) 3898 (M087) 3899 (M088) 3901 (M090) ... 3902 (M091) 3903 (M092) 3904 (M093)

250ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 251Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 84 of 116 3905 (M094) Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> 3906 (M095) ... 3907 (M096) 3908 (M097) 3909 (M098) 3911 (M0100) ... 3912 (M0101) 3913 (M0102) 3914 (M0103) HJJWbvqW9E84vJVQk... 3915 (M0104) 3916 (M0105) 3917 (M0106) 3918 (M0107) 3919 (M0108) 3920 (M0109) 3921 (M0110) 3922 (M0111) 3923 (M0112) ... 3924 (M0113) 3925 (M0114) ... 3926 (M0115) 3927 (M0116) 3928 (M0117) Bu ...= 3929 (M0118) 3930 (M0119) 3931 (M0120) 3932 (M0121) 3933 (M0122) 3934 (M0123) 3935 (M0124) 3936 (M0125) 3937 (M0126) 3938 (M0127) 3940 (M0128) 3941 (M0129) 3942 (M0130) 3943 (M0131) 3944 (M0132) 3945 (M0133) 3946 (M0134) 3947 (M0135) 70...= 3948 (M0136) 3949 (M0137) 3950 (M0138) 3951 (M0139) 3952 3953

253ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 254Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 85 of 116 39542.3.2.5 (WSS1.1) SAML1.1/2.0 Holder of Key, Sign, Encrypt 3955This scenario is based on IBM WS-SecureConversation Interop, WS-SecureConversation and WS-Trust 3956Interop Scenarios Version 1.0a August 24, 2004 [WSSX-PRE-INTEROP see figure 3 in that doc]. 3957 3958SAML Assertion contains the ephemeral key K in the EncryptedKey construct encrypted using server’s 3959certificate. The body of the message is signed using DKT1(K) and encrypted using DKT2(K). Response is 3960also signed using derived keys. In a simpler alternative, ephemeral key K itself could be used for 3961message protection. 3962In this scenario, the Authority is the Issuer of the SAML 20 hk Assertion that contains the symmetric 3963signing key. The Recipient can trust the Initiator that uses the symmetric key, because the same key gets 3964delivered to the Recipient in the SAML hk Assertion, which is signed by the trusted Authority. 3965Here are the ws-sx interop Policys: 3966 3967 3975 3976 3977 3978 3979 3980 3981 3983 3984 3985 3986 3987 3988 3989 3990 3991 3992 3993 3994 3995 3996 3997 3998 3999 4000 4001 4002 4003 4004 4005 4006 4007 4009 4010 http://example.com/STS

256ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 257Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 86 of 116 4011 4012 4013 http://docs.oasis-open.org/wss/oasis-wss-saml-token- 4014 profile-1.1#SAMLV1.1 4015 http://docs.oasis-open.org/ws-sx/ws- 4016 trust/200512/SymmetricKey 4017 256 4018 http://www.w3.org/2001/10/xml-exc- 4019 c14n# 4020 http://www.w3.org/2001/04/xmlenc#aes256- 4021 cbc 4022 http://www.w3.org/2001/04/xmlenc#aes256- 4023 cbc 4024 http://www.w3.org/2000/09/xmldsig#hmac-sha1 4025 4026 4027 4028 4029 4030 4031 4032 4033 4034 4035 4036 4037 4038 4039 4040 4041 4042 4043 4044 4045 4046 4047 4048 4049 4050 4051 4052 4053 4061 4062 4063 4064 4065 4066 4067 4069 4071

259ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 260Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 87 of 116 4073 4075 4076 4077 4078 4079 4080 4081 4082 4083 4084 4085When a client encounters the above Policy, it determines what tokens it will supply. The tokens may be 4086obtained using WS-Trust, an example from the Interop, which also will be shown here. 4087A typical WS-Trust Policy that the client may then encounter is the following: 4088 4089 4097 4098 4099 4100 4101 4102 4103 4105 4106 4107 4108 4109 4110 4111 4112 4113 4114 4115 4116 4117 4118 4119 4120 4121 4122 4123 4124 4125 4126 4127 4128 4130 4131 4132 4133 262ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 263Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 88 of 116 4134 4135 4136 4137 4138 4139 4140 4141 4142 4143 4144 4145 4146 4147 4148 4149 4150 4151 4152 4153 4154 4155 4156 4157 4165 4166 4167 4168 4169 4170 4171 4173 4175 4177 4179 4180 4181 4182 4183 4184 4185 4186 4187 4188 4189Here is an example STS request: 4190 4191

265ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 266Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 89 of 116 4194 xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity- 4195 secext-1.0.xsd" 4196 xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity- 4197 utility-1.0.xsd" 4198 > 4199 4200 4201 http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue 4202 4203 4204 urn:uuid:04d386bf-f850-459e-918b-ad80f3d1e088 4205 4206 4207 4208 http://www.w3.org/2005/08/addressing/anonymous 4209 4210 4211 4212 http://server.example.com/STS/Scenarios5-6 4213 4214 4215 4216 2005-10-25T00:47:36.144Z 4217 2005-10-25T00:52:36.144Z 4218 4219 4220 4222 4223 4224 4227 NQM0IBvuplAtETQvk+6gn8C13wE= 4228 4229 4230 4231 4232 4233 4234 4235 4236 4237 4238 4239 4240

268ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 269Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 90 of 116 4245 4246 MIIDDDCCAfSgAwIBAgIQM6YEf7FVYx/tZyEXgVComTANBgkqhkiG9w0BAQUFADAwMQ4wDAYDVQQKDA 4247 VPQVNJUzEeMBwGA1UEAwwVT0FTSVMgSW50ZXJvcCBUZXN0IENBMB4XDTA1MDMxOTAwMDAwMFoXDTE4 4248 MDMxOTIzNTk1OVowQjEOMAwGA1UECgwFT0FTSVMxIDAeBgNVBAsMF09BU0lTIEludGVyb3AgVGVzdC 4249 BDZXJ0MQ4wDAYDVQQDDAVBbGljZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAoqi99By1VYo0 4250 aHrkKCNT4DkIgPL/SgahbeKdGhrbu3K2XG7arfD9tqIBIKMfrX4Gp90NJa85AV1yiNsEyvq+mUnMpN 4251 cKnLXLOjkTmMCqDYbbkehJlXPnaWLzve+mW0pJdPxtf3rbD4PS/cBQIvtpjmrDAU8VsZKT8DN5Kyz+ 4252 EZsCAwEAAaOBkzCBkDAJBgNVHRMEAjAAMDMGA1UdHwQsMCowKKImhiRodHRwOi8vaW50ZXJvcC5iYn 4253 Rlc3QubmV0L2NybC9jYS5jcmwwDgYDVR0PAQH/BAQDAgSwMB0GA1UdDgQWBBQK4l0TUHZ1QV3V2Qtl 4254 LNDm+PoxiDAfBgNVHSMEGDAWgBTAnSj8wes1oR3WqqqgHBpNwkkPDzANBgkqhkiG9w0BAQUFAAOCAQ 4255 EABTqpOpvW+6yrLXyUlP2xJbEkohXHI5OWwKWleOb9hlkhWntUalfcFOJAgUyH30TTpHldzx1+vK2L 4256 PzhoUFKYHE1IyQvokBN2JjFO64BQukCKnZhldLRPxGhfkTdxQgdf5rCK/wh3xVsZCNTfuMNmlAM6lO 4257 Ag8QduDah3WFZpEA0s2nwQaCNQTNMjJC8tav1CBr6+E5FAmwPXP7pJxn9Fw9OXRyqbRA4v2y7YpbGk 4258 G2GI9UvOHw6SGvf4FRSthMMO35YbpikGsLix3vAsXWWi4rwfVOYzQK0OFPNi9RMCUdSH06m9uLWcki 4259 Cxjos0FQODZE9l4ATGy9s9hNVwryOJTw== 4260 4261 4262 4263 4265 4266 4267 4268 4269 4270 4271 VX1fCPwCzVsSc1hZf0BSbCgW2hM= 4272 4273 4274 4275 4276 4277 4278 FwiFAUuqNDo9SDkk5A28Mg7Pa8Q= 4279 4280 4281 4282 4283 4284 4285 oM59PsOTpmrDdOcwXYQzjVUl0xw= 4286 4287 4288 4289 4290 4291 4292 KIK3vklFN1QmMdQkplq2azfzrzg= 4293 4294 4295 4296 4297 4298 4299 RJEe3hrcyCD6PzFJo6fyut6biVg= 4300 4301 4302 4303 4304 4305 4306 zQdN5XpejfqXn0WKo0m51ZYiasE= 4307

271ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 272Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 91 of 116 4308 4309 iHGJ+xV2VZTjMlRc7AQJrwLY/aM= 4310 4311 4312 4316 4317 4318 4319 4320 4321 4323 4324 4325 4326 4327 4328 4329 UZKtShk8q6iu9WR5uQZp04iAitg= 4330 4331 4332 4333 4334 Ovxdeg4KQcfQlT/hEBJz+Z8dQUAfChaWIcmG3xGLZYcc8tbmCtZFuQz9tnW35Lmst6vIHFI23mg8U3 4335 lRefuPA7ewRLYORAOjf92SxMbeVTlrIxQbIQNw0bs4SBSLfAo14= 4336 4337 4338 4339 4343 4344 4345 4346 4347 4348 4349 4350 4352 4353 4354 4355 4356 4375 4376 4377 4378 4379 4380 4381 4382Here is an example STS response: 4383 4384 4393 4394 4395 http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTRC/IssueFinal 4396 4397 4398 urn:uuid:04d386bf-f850-459e-918b-ad80f3d1e088 4399 4400 4401 http://www.w3.org/2005/08/addressing/anonymous 4402 4403 4404 4405 2005-10-25T00:47:38.718Z 4406 2005-10-25T00:52:38.718Z 4407 4408 4409 4410 4411 4412 4417 4418 4419 4421 4422 4423 4424 4425 4426 4427 kKx5bpLLlyucgXQ6exv/PbjsFlA= 4428 4429 4430 4431

277ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 278Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 93 of 116 4432 4433 4434 LB+VGn4fP2z45jg0Mdzyo8yTAwQ= 4435 4436 4437 4438 4439 4440 4441 izHLxm6V4Lc3PSs9Y6VRv3I5RPw= 4442 4443 4444 4445 4446 4447 4448 6LS4X08vC/GMGay2vwmD8fL7J2U= 4449 4450 4451 4452 4453 4454 4455 uXGSpCBfbT1fLNBLdGMgy6DGDio= 4456 4457 4458 4459 4460 4461 4462 z86w+GrzqRZF56ciuz6ogzVXAUA= 4463 4464 4465 4466 4467 4468 4469 Z9TfD20a5aGngsyOPEvQuE0urvQ= 4470 4471 4472 Q7HhboPUaZyXqUKgG7NCYlhMTXI= 4473 4474 4475 4478 CixQW5yEb3mw6XYqD8Ysvrf8cwI= 4479 4480 4481 4482 4483 4484 4485 4486 4487 4489 4490 4491 4494 CixQW5yEb3mw6XYqD8Ysvrf8cwI=

280ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 281Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 94 of 116 4495 4496 4497 4498 4499 4500 4501 4605 4606 4607 4608 4609 4610 4611 4612Here is an example request: 4613 (M01) 4614 4615

286ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 287Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 96 of 116 4618 xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity- 4619 secext-1.0.xsd" 4620 xmlns:sc="http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512" 4621 xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity- 4622 utility-1.0.xsd" 4623 > 4624 4625 4626 http://example.org/Ping 4627 4628 4629 urn:uuid:a859eb17-1855-4d4f-8f73-85e4cba3e423 4630 4631 4632 4633 http://www.w3.org/2005/08/addressing/anonymous 4634 4635 4636 4637 http://server.example.com/Scenarios5 4638 4639 4640 4641 2005-10-25T00:47:38.222Z 4642 2005-10-25T00:52:38.222Z 4643 4644 4645 4647 4648 4649 4652 NQM0IBvuplAtETQvk+6gn8C13wE= 4653 4654 4655 4656 4657 4658 4659 4660 4661 4662 4663 4664 4665 4666 0 4667 24 4668 7hI6Ul6OHavffYgpquHWuQ== 4669 4670 4671 4672 4673 4674 OEu+WEeUxPFRQK7SCFAnEQ== 4675 4676 4677 4678 4679 4680

289ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 290Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 97 of 116 4681 4683 4684 4685 4686 4688 4689 4690 4693 NQM0IBvuplAtETQvk+6gn8C13wE= 4694 4695 4696 4697 4698 4699 4700 cb7+JW2idPNSarK9quqCe9PQwmW2hoUghuyKRe+I9zOts6HaMcg73LqCWuK/jtdpvNl6GT/ZDYfcAJ 4701 7NLyMGxSiwi4DUlTOShqS6OTYBIKgUKiA+zXNl2koVSy7amcUhPMIT6/fohH+6MZDA4t6jomcyhlCi 4702 W8d9IAzSWFkfg2k= 4703 4704 4705 4706 4707 4708 4709 4711 4713 4714 4715 4716 4717 4718 4719 4720 4723 uuid-0c947d47-f527-410a-a674-753a9d7d97f7-16 4724 4725 4726 0 4727 24 4728 pgnS/VDSzJn6SFz+Vy23JA== 4729 4730 4731 4732 4734 4735 4736 4737 4738 4739 4740 eQdQVGRkVI1YfKJBw7vOYCOeLQw= 4741 4742 4743

292ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 293Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 98 of 116 4744 4745 4746 4747 xxyKpp5RZ2TebKca2IGOafIgcxk= 4748 4749 4750 4751 4752 4753 4754 WyGDDyYbL/hQZJfE3Yx2aK3RkK8= 4755 4756 4757 4758 4759 4760 4761 AEOH0t2KYR8mivgqUGDrgMtxgEQ= 4762 4763 4764 4765 4766 4767 4768 y8n6Dxd3DbD6TR6d6H/oVWsV4yE= 4769 4770 4771 4772 4773 4774 4775 /Cc+bGkkeQ6jlVXZx8PGgmF6MjI= 4776 4777 4778 4779 4780 4781 4782 4783 4784 4785 4786 4787 4824 4825 4826 4827 4828 4829 4830Here is an example response: 4831 4832 4841 4842 4843 http://example.org/PingResponse 4844 4845 4846 urn:uuid:a859eb17-1855-4d4f-8f73-85e4cba3e423 4847 4848 4849 http://www.w3.org/2005/08/addressing/anonymous 4850 4851 4852 4853 2005-10-25T00:47:38.921Z 4854 2005-10-25T00:52:38.921Z 4855 4856 4857 4858 pDJlrSJLzIqi+AcQLUB4GjUuRLs= 4861 4862 0 4863 24 4864 KFjy1Gb73BubLul0ZGgx+w== 4865 4866 4867

298ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 299Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 100 of 116 4868 4871 pDJlrSJLzIqi+AcQLUB4GjUuRLs= 4872 4873 4874 omyh+Eg6XIa8q3V5IkHiXg== 4875 4876 4877 4878 4879 4880 4881 4882 4883 4885 4886 4887 4888 4889 4890 4891 y/oItF5TcTOFan7SavhZTTTv48M= 4892 4893 4894 4895 4896 4897 4898 X4UIaLWnaAWTriw4UJ/SFDgm090= 4899 4900 4901 4902 4903 4904 4905 vqy8/D4CDCaI1nnd4wl1Qjyp+qM= 4906 4907 4908 4909 4910 4911 4912 H11vLAr5g8pbZ6jfZ+2WNyiNjiM= 4913 4914 4915 4916 4917 4918 4919 dr0g6hycoc884i+BD8FYCJGbbbE= 4920 4921 4922 4923 4924 4925 4926 Rv3N7VNfAqpn0khr3F/qQZmE/l4= 4927 4928 4929 4930

301ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 302Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 101 of 116 4931 4932 4933 X2pxEnYPM8cMLrbhNqPgs8xk+a4= 4934 4935 4936 I2jQuDTWWQiNJy/ziyg8AFYO/z4= 4937 4938 4939 4940 4941 4942 4943 4944 4945 4946 4947 4949 4950 4951 4952 4953 4954 4955 4956 4957 4958 4959 4960 4961 4962 4963

49642.3.3 4965

304ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 305Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 102 of 116 49662.4 Secure Conversation Scenarios

49672.4.1 (WSS 1.0) Secure Conversation bootstrapped by Mutual 4968 Authentication with X.509 Certificates 4969This scenario corresponds to the situation where both parties have an X.509 certificate (and public/private 4970key pair). Because of the volume of messages from each source, the Requestor/Initiator uses WS- 4971SecureConversation to establish a new session key and uses the session key for integrity and/or 4972confidentiality protection. This improves performance, by using less expensive symmetric key operations 4973and improves security by reducing the exposure of the long term secret. 4974The recipient models this scenario by using the symmetric binding that includes a 4975SecureConversationToken assertion to describe the token type accepted by this endpoint. This token 4976assertion further contains a bootstrap policy to indicate the security binding that is used by requestors that 4977want a security context token issued by this service. The bootstrap policy affects the Request Security 4978Token Request (RST) and Request Security Token Request Response (RSTR) messages sent between 4979the Initiator and the Recipient to establish the security context. It is modeled by use of an asymmetric 4980binding assertion for this scenario because both parties mutually authenticate each other using their 4981X.509 certificates. 4982The message level policies cover a different scope of the web service definition than the security binding 4983level policy and so appear as separate policies and are attached at Message Policy Subject. These are 4984shown below as input and output policies. Thus, we need a set of coordinated policies one with endpoint 4985subject (WSS10SecureConversation_policy) and two (WSS10SecureConversation_input_policy, 4986WSS10SecureConversation_output_policy) with message subjects to achieve this use case. 4987 4988(P01) 4989(P02) 4990(P03) 4991(P04) 4992(P05) 4993(P06) 4994(P07) 4995(P08) 4998(P09) 4999(P010) 5000(P011) 5001(P012) 5002(P013) 5003(P014) 5004(P015) 5006(P016) 5007(P017) 5008(P018) 5009(P019) 5012(P020) 5013(P021) 5014(P022) 5015(P023) 5016(P024) 5017(P025) 5018(P026) 5019(P027)

307ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 308Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 103 of 116 5020(P028) 5023(P029) 5024(P030) 5025(P031) 5026(P032) 5027(P033) 5028(P034) 5029(P035) 5030(P036) 5031(P037) 5032(P038) 5033(P039) 5034(P040) 5035(P041) 5036(P042) 5037(P043) 5038(P044) 5039(P045) 5040(P046) 5041(P047) 5042(P048) 5043(P049) 5044(P050) 5045(P051) 5046(P052) 5047(P053) 5048(P054) 5049(P055) 5050(P056) 5052(P057) 5053(P058) 5054(P059) 5055(P060) 5056(P061) 5057(P062) 5058(P063) 5059(P064) 5060(P065) 5061(P066) 5062(P067) 5063(P068) 5064(P069) 5065(P070) 5066(P071) 5067(P072) 5068(P073) 5069(P074) 5070(P075) 5071(P076) 5072(P077) 5073(P078) 5074(P079) 5075(P080) 5076(P081) 5077(P082) 5078(P083) 5079(P084) 5080(P085) 5081(P086) 5082(P087)

310ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 311Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 104 of 116 5083(P088) 5084(P089) 5085(P090) 5086(P091) 5087(P092) 5088 5089(P093) 5090(P094) 5091(P095) 5092(P096) 5093(P097) 5095(P098) 5097(P099) 5099(P0100) 5100(P0101) 5101(P0102) 5102(P0103) 5103(P0104) 5104(P0105) 5105(P0106) 5106(P0107) 5107(P0108) 5108(P0109) 5109(P0110) 5111(P0111) 5113(P0112) 5115(P0113) 5117(P0114) 5118(P0115) 5119(P0116) 5120(P0117) 5121(P0118) 5122Lines (P004) – (P082) indicate that the service uses the symmetric security binding to protect messages, 5123using a Security Context Token (Lines (P008) – (P066)) to sign messages in both directions. The actual 5124basis for the signatures should be keys derived from that Security Context Token as stated by the 5125RequireDerivedKey assertion in Line (P010). Messages must include a Timestamp element (Line (P079)) 5126and the signature value must be calculated over the entire body and header elements (Line (P080)). 5127Lines (P083) – (P088) contain the Trust13 assertion which defines the requirements for the WS-Trust 5128related message exchange as part of the SC bootstrap. Line (P085) indicates that the Initiator (Client) has 5129to provide entropy to be used as key material for the requested proof token. Line (P086) requires the 5130same from the recipient (Server) which results in computed key from both client and server entropy 5131values. 5132Lines (P011) – (P065) contain the bootstrap policy for the initial creation of the security context between 5133the communication parties before it is being used. It contains an AsymmetricBinding assertion (Lines 5134(P015) – (P048)) which indicates that the initiator’s (WS-Security 1.0 X.509 Certificate) token (Lines 5135(P017) – (P025)) used by the recipient to verify the signature in the RST must be included in the message 5136(P019). The exchange of entropy and key material in the body of the RST and RSTR messages is 5137protected by the EncryptedParts assertion of the bootstrap policy in lines (P058) – (P061). 5138According to the MustSupportKeyRefIdentitier assertions in Line (P051), an X.509 Key Identifier must be 5139used to identify the token. Lines (P054) – (P057) require that the body and the WS-Addressing Action 5140header is signed on each message (RST, RSTR) within the bootstrap process.

313ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 314Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 105 of 116 5141An example of an RST message sent from the initiator to the recipient according to the bootstrap policy 5142defined by this policy is as follows: 5143(M01) 5144(M02) 5146(M03) 5147(M04) 5148(M05) http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/SCT 5149(M06) 5150(M07) 5151(M08) 5152(M09) 2007-06-17T00:00:00Z 5153(M010) 2007-06-17T23:59:59Z 5154(M011) 5155(M012) 5157(M013) MIICZDCCAc2gAwIBAgIRALSOLzt7... 5158(M014) 5159(M015) 5160(M016) 5161(M017) 5163(M018) 5165(M019) 5166(M020) 5167(M021) 5169(M022) 5170(M023) 5172(M024) oZKZXftCbY43Wo4w... 5173(M025) 5174(M026) ... 5175(M027) ... 5176(M028) 5177(M029) Po9mb0Gw6hWn... 5178(M030) 5179(M031) 5180(M032) 5182(M033) 5183(M034) 5184(M035) 5185(M036) 5186(M037) 5187(M038) 5188(M039) 5189(M040) AtETQ... 5191(M042) 5192(M043) 5193(M044) 5194(M045) 5195(M046) 5196(M047) 5197(M048) 5198(M049) 5199(M050) 5200(M051) 5201(M052) 5202(M053) 5203(M054) 316ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 317Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 106 of 116 5204(M055) 5205(M056) 5206(M057) 5207(M058) 5208(M059) 5209(M060) 5210(M061) 5211(M062) 5234(M083) 5235(M084) 5236(M085) 5237(M086) 5238(M087) 5239Line (M005) indicates to the recipient that the SCT Binding of WS-Trust is used. 5240Lines (M008) – (M011) hold the Timestamp element as required by the IncludeTimestamp assertion. 5241Lines (M012) – (M014) contain the initiator’s X.509 token as required by the InitiatorToken assertion’s 5242value (“…/AlwaysToRecipient”). 5243Lines (M015) – (M035) hold the message signature. 5244Lines (M036) – (M053) hold the encrypted symmetric key used to encrypt the RST request in the body of 5245the message according to the bootstrap policy. It contains a Subject Key Identifier of the X.509 Certificate 5246used to encrypt the key and not the certificate itself as required by the RecipientToken assertion’s value 5247(“…/Never”) in (P028). 5248Lines (M019) – (M025) indicate the WS-Addressing Action header is included in the signature as required 5249by the SignedParts assertion. 5250Line (M026) indicates the Timestamp is included in the signature according to the IncludeTimestamp 5251assertion definition. 5252Line (M027) indicates the SOAP Body is included in the signature as required by the SignedParts 5253assertion. 5254Lines (M056) – (M086) hold the Security Token Reference pointing to the initiators X.509 certificate. 5255Lines (M038) – (M058) contain the SOAP Body of the message with the encrypted RST element. Lines 5256(M062) – (M082) show the unencrypted content of the RST request. It specifies the Token Type (Lines 5257(M064) – (M066)) and the Request Type (Lines (M067) – (M069). According to the Trust13 assertion, it 5258also includes entropy provided by the initiator as indicated by Lines (M077) – (M080).

319ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 320Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 107 of 116 5259An example of an RSTR message sent from the recipient to the initiator according to the bootstrap policy 5260defined by this policy is as follows: 5261 (M01) 5262 (M02) 5264 (M03) 5265 (M04) 5266 (M05) http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTRC/IssueFinal 5267 (M06) 5268 (M07) 5269 (M08) 5270 (M09) 2007-06-17T00:00:00Z 5271 (M010) 2007-06-17T23:59:59Z 5272 (M011) 5273 (M012) 5275 (M013) MIIASDPIOASDsaöAgIRALSOLzt7... 5276 (M014) 5277 (M015) 5278 (M016) 5279 (M017) 5281 (M018) 5283 (M019) 5284 (M020) 5285 (M021) 5287 (M022) 5288 (M023) 5290 (M024) oZKZXftCbY43Wo4w... 5291 (M025) 5292 (M026) ... 5293 (M027) ... 5294 (M028) 5295 (M029) Po9mb0Gw6hWn... 5296 (M030) 5297 (M031) 5298 (M032) 5299 (M033) 5300 (M034) 5301 (M035) 5302 (M036) 5303 (M037) 5304 (M038) 5305 (M039) 5306 (M040) AtETQ... 5308 (M042) 5309 (M043) 5310 (M044) 5311 (M045) 5312 (M046) 5313 (M047) 5314 (M048) 5315 (M049) 5316 (M050) 5317 (M051) 5318 (M052) 5319 (M053) 5320 (M054) 5321 (M055) 322ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 323Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 108 of 116 5322 (M056) 5323 (M057) 5324 (M058) 5325 (M059) 5326 (M060) 5327 (M061) 5328 (M062) 5369 (M099) 5370 (M0100) 5371 (M0101) 5372 (M0102) 5373 (M0103) 5374Line (M005) indicates to the initiator that th is is the final response to the RST in an RSTRC. 5375Lines (M008) – (M011) hold the Timestamp element as required by the IncludeTimestamp assertion. 5376Lines (M012) – (M014) contain the recipient’s X.509 token as required by the RecipientToken assertion’s 5377value (“…/AlwaysToInitiator”). 5378Lines (M015) – (M035) hold the message signature. 5379Lines (M036) – (M053) hold the encrypted symmetric key used to encrypt the RSTR response in the body 5380of the message according to the bootstrap policy.

325ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 326Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 109 of 116 5381Lines (M019) – (M025) indicate the WS-Addressing Action header is included in the signature as required 5382by the SignedParts assertion. 5383Line (M026) indicates the Timestamp is included in the signature according to the IncludeTimestamp 5384assertion definition. 5385Line (M027) indicates the SOAP Body is included in the signature as required by the SignedParts 5386assertion. 5387Lines (M031) – (M033) hold the Security Token Reference pointing to the requestor’s X.509 certificate. 5388Lines (M056) – (M102) contain the SOAP Body of the message with the encrypted RSTR collection 5389element. Commented out is the unencrypted form of the RSTR collection in Lines (M063) – (M097), which 5390includes one RSTR (Lines (M064) – (M096)). Lines (M065) – (M069) contain the new Security Context 5391Token. The accompanying RequestedProofToken in Lines (M070) – (M084) include the encrypted secret 5392key (Lines (M071) – (M083)) of the security context. The key is encrypted using the initiator’s public key 5393that was already used to verify its signature in the incoming request. 5394According to the Trust13 assertion, the response includes entropy provided by the recipient as indicated 5395by Lines (M092) – (M095). 5396An Example of an SCT-secured application message sent from the initiator to the recipient according to 5397the message input policy (WSS10SecureConversation_input_policy) is as follows: 5398 (M01) 5399 (M02) 5401 (M03) 5402 (M04) http://acme.com/ping/ 5403 (M05) 5404 (M06) http://acme.com/guid/1231873ledh-CA47-1067-B31D-10662DA 5405 (M07) 5406 (M08) urn:Ping 5407 (M09) 5408 (M010) 5409 (M011) 2007-06-17T00:00:00Z 5410 (M012) 2007-06-17T23:59:59Z 5411 (M013) 5412 (M014) 5413 (M015) uuid:91f50600-60cc-11da-8e67-000000000000 5414 (M016) 5415 (M017) 5416 (M018) 5417 (M019) 5418 (M020) 5420 (M021) 5421 (M022) 0 5422 (M023) 24 5423 (M024) 5424 WSSecure ConversationWSSecure Conversation 5425 (M025) 5426 (M026) ylN04kFBJesy2U2SQL6ezI3SCak= 5427 (M027) 5428 (M028) 5429 (M029) 5430 (M030) 5432 (M031) 5434 (M032) 5435 (M033) 5436 (M034) 5438 (M035)

328ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 329Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 110 of 116 5439 (M036) 5441 (M037) oZKZXftCbY43Wo4w... 5442 (M038) 5443 (M039) ... 5444 (M040) ... 5445 (M041) ... 5446 (M042) ... 5447 (M043) 5448 (M044) Po9mb0Gw6hWn... 5449 (M045) 5450 (M046) 5451 (M047) 5453 (M048) 5454 (M049) 5455 (M050) 5456 (M051) 5457 (M052) 5458 (M053) 5459 (M054) 5460 (M055) abc 5461 (M056) 5462 (M057) 5463 (M058) 5464 5465Lines (M004) – (M008) contain the WS-Addressing headers according to the UsingAddressing assertion. 5466Lines (M010) – (M013) hold the Timestamp as specified by the IncludeTimestamp assertion within the 5467SymmetricBinding assertion. 5468Lines (M014) – (M017) contain the Security Context Token which has been issued by the recipient in the 5469previous message. Based on this token, the initiator included a Derived Key Token (Lines (M018) – 5470(M027)) as indicated by the RequireDerivedKey assertion in the policy. 5471Lines (M028) – (M050) hold the message signature that uses the Derived Key Token (Lines (M046) – 5472(M048)) to sign the WS-Addressing headers (Lines (M032) – (M040)), the timestamp (Line (M041)) and 5473the body (Line (M042)) of the message, according to the SignedParts assertion of the message input 5474policy (WSS10SecureConversation_input_policy). 5475 5476

331ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 332Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 111 of 116 54773 References 5478

54793.1 Specifications 5480 5481WSS10-SOAPMSG: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message- 5482 security-1.0.pdf 5483 5484WSS11-SOAPMSG: http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os- 5485 SOAPMessageSecurity.pdf 5486 5487WSS10-USERNAME: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token- 5488 profile-1.0.pdf 5489 5490WSS11-USERNAME: http://www.oasis-open.org/committees/download.php/16782/wss-v1.1-spec-os- 5491 UsernameTokenProfile.pdf 5492WSS10-X509-PROFILE: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile- 5493 1.0.pdf 5494 5495WSS11-X509-PROFILE: http://www.oasis-open.org/committees/download.php/16785/wss-v1.1-spec-os- 5496 x509TokenProfile.pdf 5497 5498WSS10-SAML11-PROFILE: http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0.pdf 5499 5500WSS11-SAML1120-PROFILE: http://www.oasis-open.org/committees/download.php/16768/wss-v1.1- 5501 218-spec-os-SAMLTokenProfile.pdf 5502 5503WSS11-LIBERTY-SAML20-PROFILE: 5504 http://www.projectliberty.org/liberty/content/download/894/6258/file/liberty-idwsf- 5505 security-mechanisms-saml-profile-v2.0.pdf 5506 5507WSS-TC-ALL-TOKEN-PROFILES: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss 5508 5509WS-SECURITYPOLICY: http://www.oasis-open.org/committees/download.php/21401/ws-securitypolicy- 5510 1.2-spec-cd-01.pdf 5511 5512WS-TRUST: http://www.oasis-open.org/committees/download.php/21365/ws-trust-1.3-spec- 5513 cs-01.pdf 5514 5515WS-POLICY: http://www.w3.org/TR/ws-policy 5516 5517WS-POLICYATTACHMENT: http://www.w3.org/TR/ws-policy-attach

334ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 335Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 112 of 116 5518 5519WSDL: http://www.w3.org/TR/wsdl 5520SSL: http://www.ietf.org/rfc/rfc2246.txt 5521SAML11-CORE: http://www.oasis-open.org/committees/download.php/3406/oasis-sstc-saml-core- 5522 1.1.pdf 5523SAML20-CORE: http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf 5524XML-DSIG: http://www.w3.org/TR/xmldsig-core/ 5525XML-ENCR: http://www.w3.org/TR/xmlenc-core/ 5526

55273.2 Interops and Sample Messages 5528 5529WSS10-INTEROP-01: http://www.oasis-open.org/committees/download.php/11374/wss-interop1-draft- 5530 06-merged-changes.pdf 5531 5532WSS10-INTEROP-02: http://www.oasis-open.org/committees/download.php/11375/wss-interop2-draft- 5533 06-merged.doc 5534 5535WSS11-INTEROP-01: http://www.oasis-open.org/committees/download.php/12997/wss-11-interop- 5536 draft-01.doc 5537 5538WSS10-KERBEROS-INTEROP: http://www.oasis-open.org/committees/download.php/10991/wss- 5539 kerberos-interop.doc 5540 5541WSS10-SAML11-INTEROP: http://www.oasis-open.org/committees/download.php/7702/wss-saml- 5542 interop1-draft-12.doc 5543 5544WSS11-SAML1120-INTEROP: http://www.oasis-open.org/committees/download.php/16556/wss-saml2- 5545 interop-draft-v4.doc 5546 5547WSSX-PRE-INTEROP: http://www.oasis- 5548 open.org/committees/download.php/16357/Trust_SecureConversation_Interop.2 5549 004-10.doc 5550 5551WSSX-WSTR-WSSC-INTEROP: http://www.oasis-open.org/committees/download.php/20954/ws-sx- 5552 interop-ed-10.doc 5553 5554WCF-PLUGFEST-INTEROP: http://mssoapinterop.org/ilab/WSSecurity/WCFInteropPlugFest_Security.zip 5555 5556WSI-SCM-SAMPLEAPPL: http://www.ws-i.org/SampleApplications/SupplyChainManagement/2006- 5557 04/SCMSecurityArchitectureWGD5.00.doc (login required) 5558 5559

337ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 338Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 113 of 116 5560A. Acknowledgements

5561The following individuals have participated in the creation of this specification and are gratefully 5562acknowledged: 5563Participants: 5564 Ashok Malhotra, Oracle 5565 Prateek Mishra, Oracle 5566 Ramana Turlapati, Oracle 5567 Martin Gudgin, Microsoft 5568 Marc Goodner, Microsoft 5569 Paul Cotton, Microsoft 5570 Hal Lockhart, BEA 5571 Symon Chang, BEA 5572 Frederick Hirsch, Nokia 5573 Greg Whitehead, Hewlett-Packard 5574 Ching-Yun (C.Y.) Chao, IBM 5575 Anthony Nadalin, IBM 5576 Tony Gullotta, SOA 5577 5578 [Participant Name, Affiliation | Individual Member] 5579

340ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 341Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 114 of 116 5580B. Non-Normative Text

343ws-sp-usecases-examples-draft-176-013.doc 1618 September October 2007 344Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 115 of 116 5581C. Revision History

5582[optional; should not be included in OASIS Standards] 5583 Revision Date Editor Changes Made 0.09 23-Feb-07 Rich Levinson Updated doc format to latest OASIS template, added Symon Chang’s encrypted UsernameToken scenario 0.10 6-Mar-07 Rich Levinson Added sample messages and explanatory text Tony Gullotta to several examples. Line numbered each example w Pxxx for the Policy, Mxxx for the Symon Chang sample message. Intent is to do all examples, Martin Raepple this version is to get feedback along with progress as each example stands alone. Completed examples: 2.1.1.2, 2.1.2.1, 2.1.3, 2.1.4, 2.2.1, and 2.5.1. Partially completed examples that have sample messages: 2.1.1.1, 2.1.1.3, 2.3.1.2, 2.3.1.4, 2.3.1.5, and 2.3.2.2, 2.3.2.4, 2.3.2.5