WS-SecurityPolicy Examples Version 1.0

Committee Specification 02

4 November 2010

Specification URIs:

This Version:

http://docs.oasis-open.org/ws-sx/security-policy/examples/ws-sp-usecases-examples-cs-02.doc  (Authoritative)

http://docs.oasis-open.org/ws-sx/security-policy/examples/ws-sp-usecases-examples-cs-02.pdf

http://docs.oasis-open.org/ws-sx/security-policy/examples/ws-sp-usecases-examples-cs-02.html

Previous Version:

http://docs.oasis-open.org/ws-sx/security-policy/examples/ws-sp-usecases-examples-cd-04.doc (Authoritative)

http://docs.oasis-open.org/ws-sx/security-policy/examples/ws-sp-usecases-examples-cd-04.pdf

http://docs.oasis-open.org/ws-sx/security-policy/examples/ws-sp-usecases-examples-cd-04.html

Latest Version:

http://docs.oasis-open.org/ws-sx/security-policy/examples/ws-sp-usecases-examples.doc

http://docs.oasis-open.org/ws-sx/security-policy/examples/ws-sp-usecases-examples.pdf

http://docs.oasis-open.org/ws-sx/security-policy/examples/ws-sp-usecases-examples.html

Technical Committee:

OASIS Web Services Secure Exchange TC

Chair(s):

Kelvin Lawrence, IBM

Chris Kaler, Microsoft

Editor(s):

Rich Levinson, Oracle Corporation

Tony Gullotta, SOA Software Inc.

Symon Chang, Oracle Corporation.

Martin Raepple, SAP AG

Related work:

N/A

Declared XML Namespace(s):

N/A

Abstract:

This document contains examples of how to set up WS-SecurityPolicy [WSSP] policies for a variety of common token types that are described in WS-Security 1.0 [WSS10] and WS-Security 1.1 [WSS11] token profiles [WSSTC]. Particular attention is focused on the different “security bindings” (defined in [WSSP]) within the example policies. Actual messages that have been documented in WS-Security TC [WSSTC]and other WS-Security-based Interops [WSSINTEROPS, WSSXINTEROPS, OTHERINTEROPS] that conform to some of the example policies are referenced when appropriate.

The purpose of this document is to give examples of how policies may be defined for several existing use cases that have been part of the WS-Security Interops that have been conducted (see References section for Interop documents [INTEROPS]). In addition, some example use cases have been included which show some variations from the WS-Security Interop use cases in order to demonstrate how different options and security bindings impact the structure of the policies.

 

Status:

This document was last revised or approved by the WS-SX TC on the above date. The level of approval is also listed above. Check the “Latest Version” or “Latest Approved Version” location noted above for possible later revisions of this document.

Technical Committee members should send comments on this specification to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the “Send A Comment” button on the Technical Committee’s web page at http://www.oasis-open.org/committees/ws-sx/.

For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page (http://www.oasis-open.org/committees/ws-sx/ipr.php.

Notices

Copyright © OASIS® 1993–2010. All Rights Reserved.

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.

OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.

The names "OASIS",  are trademarks of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see http://www.oasis-open.org/who/trademark.php for above guidance.

 

Table of Contents

 

1      Introduction. 6

1.1 Terminology and Concepts. 6

1.1.1 Actors. 7

1.1.2 Concepts. 10

1.1.2.1 X509 Certificates. 10

1.2 Terminology. 11

1.3 Normative References. 11

1.4 Non-Normative References. 12

1.5 Specifications. 13

1.6 Interops and Sample Messages. 13

2      Scenarios. 14

2.1 UsernameToken. 14

2.1.1 UsernameToken – no security binding. 14

2.1.1.1 UsernameToken with plain text password. 14

2.1.1.2 UsernameToken without password. 15

2.1.1.3 UsernameToken with timestamp, nonce and password hash. 16

2.1.2 Use of SSL Transport Binding. 17

2.1.2.1 UsernameToken as supporting token. 17

2.1.3 (WSS 1.0) UsernameToken with Mutual X.509v3 Authentication, Sign, Encrypt 19

2.1.3.1 (WSS 1.0) Encrypted UsernameToken with X.509v3. 22

2.1.4 (WSS 1.1), User Name with Certificates, Sign, Encrypt 25

2.2 X.509 Token Authentication Scenario Assertions. 29

2.2.1 (WSS1.0) X.509 Certificates, Sign, Encrypt 29

2.2.2 (WSS1.0) Mutual Authentication with X.509 Certificates, Sign, Encrypt 32

2.2.2.1 (WSS1.0) Mutual Authentication, X.509 Certificates, Symmetric Encryption. 35

2.2.3 (WSS1.1) Anonymous with X.509 Certificate, Sign, Encrypt 39

2.2.4 (WSS1.1) Mutual Authentication with X.509 Certificates, Sign, Encrypt 42

2.3 SAML Token Authentication Scenario Assertions. 48

2.3.1 WSS 1.0 SAML Token Scenarios. 49

2.3.1.1 (WSS1.0) SAML1.1 Assertion (Bearer) 49

2.3.1.2 (WSS1.0) SAML1.1 Assertion (Sender Vouches) over SSL. 51

2.3.1.3 (WSS1.0) SAML1.1 Assertion (HK) over SSL. 53

2.3.1.4 (WSS1.0) SAML1.1 Sender Vouches with X.509 Certificates, Sign, Optional Encrypt 54

2.3.1.5 (WSS1.0) SAML1.1 Holder of Key, Sign, Optional Encrypt 60

2.3.2 WSS 1.1 SAML Token Scenarios. 65

2.3.2.1 (WSS1.1) SAML 2.0 Bearer 65

2.3.2.2 (WSS1.1) SAML2.0 Sender Vouches over SSL. 69

2.3.2.3 (WSS1.1) SAML2.0 HoK over SSL. 71

2.3.2.4 (WSS1.1) SAML1.1/2.0 Sender Vouches with X.509 Certificate, Sign, Encrypt 75

2.3.2.5 (WSS1.1) SAML1.1/2.0 Holder of Key, Sign, Encrypt 80

2.4 Secure Conversation Scenarios. 105

2.4.1 (WSS 1.0) Secure Conversation bootstrapped by Mutual Authentication with X.509 Certificates. 105

3      Conformance. 114

A.     Acknowledgements. 115

B.     Revision History. 118

 

 


1      Introduction

This document describes several WS-SecurityPolicy [WS-SECURITYPOLICY] examples. An example typically consists of the security aspects of a high-level Web Service use-case with several variable components.  Many of the examples are based on existing use cases that have been conducted during WS-Security Interops [WSS-INTEROPS]. In those examples a reference is included to identify the specific use case in the specific interop document that is being demonstrated.

In the policy examples below, the “wsp” prefix refers to the elements defined in the WS-Policy namespace:

xmlns:wsp=”http://www.w3.org/ns/ws-policy/”

the “sp” prefix refers to elements defined in the WS-SecurityPolicy (WS-SP) namespace:

xmlns:sp=“http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702”
the “t” prefix refers to elements defined in the WS-Trust namespace:

            xmlns:t=” http://docs.oasis-open.org/ws-sx/ws-trust/200512”

 

Where uses cases are based on existing scenarios, those scenarios are referenced at the beginning of the use case section. The explicit documents describing the scenarios are identified by links in [Section 3.2].

1.1 Terminology and Concepts

This section (1.1.*) describes the logical “actors” that participate in the examples. In addition, there is a discussion on general concepts that describes how the logical actors typically relate to the physical message exchanges that take place.

This section also provides a security reference model designed to provide context for the examples in terms of a conceptual framework within which the actors interact, which is intended to help readers understand the trust relationships implicit in the message exchanges shown in the examples.

In these examples there are always three important conceptual entities to recognize that exist on the initiating side of a transaction, where the transaction is being requested by sending an electronic message that contains the details of the what is being requested and by whom (the “entities” become “actors” as the discussion moves from the conceptual to the specific). These three entities are:

WS-SecurityPolicy is primarily concerned with the technical software used between the initiating entity and the recipient entity, whom are respectively officially referred to as the Initiator and the Recipient in the WS-SecurityPolicy 1.2 specification (WS-SP) (see section 1.4 of that document).

Therefore, the purpose of this section is to give a larger real world context to understanding the examples and how to relate the technical details of WS-SecurityPolicy to the actual logical actors involved in the transactions governed by the technology.

The reason for providing this context is to help interested readers understand that while the technology may be securing the integrity and confidentiality of the messages, there are additional questions about transactions such as who is liable for any commitments resulting from the transaction and how those commitments are technically bound within the message exchanges.

The purpose here is not to provide unequivocable answers to all questions regarding liability of transactions, but to give a sense of how the structuring of a request message ties the participating entities to the transaction. Depending on how the WS-SecurityPolicy technology is used, these “ties” can be relatively stronger or weaker. Depending on the nature of the transactions supported by a particular Web Application, the system managers of the Web Services Application being protected using WS-SecurityPolicy techniques, may be interested in a conceptual framework for understanding which WS-SP techniques are more or less appropriate for their needs.

These introductory sections are intended to provide this type of conceptual framework for understanding how the examples in this document may be interpreted in the above context of the three entities on the initiating side of the transaction. A complementary model is also provided for the recipient side of the transaction, but since the recipient is generally concerned with validating the request, which is primarily a back office function, less emphasis is focused on the options in that environment except as they might relate back to the initiator side of the transaction.

1.1.1 Actors

The following diagram shows the actors and the relationships that may be typically involved in a network security scenario:

 


Figure 1.

 

The diagram is intended to show the possible interactions that may occur between actors in any given scenario, although, in general, depending on the policy specified by the recipient, only a subset of the possible interactions will actually occur in a given scenario. Note that the Issuing and Validating Authorities, may, in general be either a WS-Trust Security Token Service (STS) or other authority.

First, a brief narrative will describe the diagram, then the actors will be defined in more detail.

In a typical example interaction, a Requestor wants to issue a Web Service request to a Web Service that is hosted by the “Recipient” web site on behalf of a RelyingParty, who is actually the business entity responsible for making the service available and with whom any business arrangements with the Requestor are made. One may think of this as an end to end interaction between a Requestor and a RelyingParty, with technical resources being provided by the Initiator on the Requestor side and the Recipient on the RelyingParty side.

Technically, what occurs is that the Requestor hands the request to the Initiator, which in turn issues a query to the Recipient and is returned the WSDL [WSDL] describing the Web Service, which generally includes WS-SP policy Assertions [WS-POLICY, WS-POLICYATTACHMENT] that describe the security policies supported by the Recipient for this Web Service (Note: it is not necessary that the information in the Assertions be obtained this way. It may also be stored locally based on out of band agreements between the Requestor and RelyingParty). This interaction is shown by the upper pair of arrows between the Initiator and the Recipient.

Upon receipt of the WS-SP policy assertions, the Initiator then interacts with the Requestor and the Issuing Authority, as needed in order to meet the requirements specified by the WS-SP. Generally, what is required here is that credentials and tokens are obtained from the Requestor and Issuing Authority and assembled as required in a new WS-Security request message that is to be issued to the Recipient.

(For example, if a UsernameToken is required by the Recipient, one possibility is that the Initiator will query the Requestor for Username and Password and create the appropriate token to include in the Request.

Other possibilities exist as well, but WS-SP only governs what the final message must contain. How it gets constructed and how the pieces are assembled are specific to the system environment that is being used.

In general, the examples in this document will explain the interactions that might occur to meet the policy requirements, but the actual sequences and specifics will be determined by the setup of the systems involved.)

Finally, after assembling the necessary tokens, the Initiator (or Requestor/Initiator) may sign and encrypt the message as required by the WS-SP policy and send it to the Recipient.

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

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

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

The following list is a reference to identify the logical actors in Figure 1. (In general, these actors may physically be implemented such that more than one actor is included in the physical entity, such as a Security Token Service (STS) [WS-TRUST] that implements both an IssuingAuthority and a ValidatingAuthority. Similarly, in a scenario where a user is at a security-enabled work station, the work station may combine a Requestor and Initiator in a single physical entity.)

Of these actors, the Requestor and Initiator can generally being regarded as “client-side” or “requestor-side” actors. The Recipient and RelyingParty (or combined “RelyingParty/Recipient”) can be regarded as “server-side” actors.

Note 1: In addition to the above labelling of the actors, there is also the notion of “Sender”. Generally, the “Sender” may be thought of as a Requestor/Initiator that is independently collecting information from a user (who could be modeled as a separate benign actor to the left of the Requestor in the figure 1.1 from whom the Requestor gathers information that would be included in the message) and is submitting requests on behalf of that user. Generally, the trust of the Recipient is on the Sender, and it is up to the Sender to do whatever is necessary for the Sender to trust the user. Examples of this configuration will be described in the SAML Sender Vouches sections later in this document.

Note 2: The person or entity actually making the request is the "Requestor", however, there are 2 common use cases: 1. the Requestor is a user at a browser and the request is intercepted by a web service that can do WS-Security and this web service is the "Initiator" which actually handles the message protection and passes the Requestor’s credentials (typically collected via http(s) challenge by the Initiator to the Requestor for username/password) to the Recipient. 2. the Requestor is at a web-service client enabled workstation, where the Requestor person making the request is also in charge of the web service client that is initiating the request, in which case the combined entity may be referred to as a "Requestor/Initator".

1.1.2 Concepts

Physical message exchanges are between the Initiator and Recipient. For the purposes of this document the Initiator and Recipient may be considered to be the physical systems that exchange the messages. The Initiator and Recipient use the keys that are involved in the WS-SP security binding that protects the messages.

As described in the previous section, the Requestor is the logical entity that gathers the credentials to be used in the request and the Initiator is the logical entity that inserts the credentials into the request message and does all the rest of the message construction in accordance with the WS-SP policy. The Requestor may generally be thought of as being either a separate physical entity from the Initiator, or  as part of a combined physical entity with the Initiator. An example of the latter combined case would be a user at a client workstation equipped with signing and encryption capabilities, where the combined entity may be referred to as a “Requestor/Initiator”.

Similarly, the IssuingAuthority should generally be thought of as a separate physical entity from the Initiator. However, in some cases, such as SAML sender-vouches, the IssuingAuthority and the Initiator may be the same entity.

In some other cases, such as the case where user passwords are involved, the ValidatingAuthority system entity may also comprise the Recipient and the Relying Party, since passwords are typically checked locally for validity.

The focus of WS-SP is the notion that policy assertions are attached to the Initiator and/or Recipient, however, the concepts in those policies generally require understanding specifically the relation of the parties involved (i.e. Requestor/Initiator, RelyingParty/Recipient). This is because the Requestor in general does not know in advance what policies each Web Service provider requires and it is necessary for practical purposes to have a front end Initiator resolve the policy and coordinate whatever actions are required to exchange the Requestor tokens for the tokens required by the service. This token exchange may be done using WS-Trust [WS-TRUST] to prepare the necessary requests and process responses from an STS IssuingAuthority. Examples of these WS-Trust token exchanges may be found in [WSSX-INTEROP].

Typically both the Requestor/Initiator and Recipient/RelyingParty will have relations with the IssuingAuthority/ValidatingAuthority and often establish contact with those Authorities using WS-Trust for the purpose of obtaining and validating tokens used in their Web Service interactions. The policies for using the Authority may also be represented using WS-SP, but they are typically no different from the policies shown in the examples in this document. The policies in this document may be used for any kind of request, whether it be a request to a service provider for general content or operations or a request to an Authority for authentication tokens.

In each example the relations between these actors and how the request message is prepared will be described, because, in general, the policy requirements will imply these relationships. Generally, each of the 3 client side actors, the Requestor, the Initiator, and the IssuingAuthority will contribute to the preparation of the request message, which is the primary focus of this document. For validation of the message, the Recipient, the RelyingParty, and the ValidatingAuthority are generally involved, but for this document the focus is simply that the Recipient provides the WS-SP policy that dictates the preparation of the request message.

1.1.2.1 X509 Certificates

The specifics of whom is trusted for X509 certificates depends on the specific organization’s PKI (Public Key Infrastructure) setup. For this document, we shall assume the Subject of the X509 certificate identifies the actor, which may be the IssuingAuthority, or the Initiator, or the Requestor, depending on the example. We shall also assume that the issuer of the X509 certificates is a general Certificate Authority not directly involved in any authorization of the web service transactions, but is relied on for the validity of the X509 certificate in a manner out of scope of the scenarios covered. In addition, this document does not explicitly address the case of X509 certificates issued by the IssuingAuthority actor. Such use cases are generally implicitly covered if one assumes that such relations are automatically covered by the specifics of the organization PKI setups.

However, the IssuingAuthority may issue tokens, such as SAML holder-of-key that contain X509 certificates. In these cases, the basis of trust is that the X509 Certificate of the IssuingAuthority was used to protect the X509 certificate of the Requestor which is contained in the signed SAML holder-of-key token. I.e. any “chaining” of tokens is done by referencing those tokens within signed XML structures and not by issuing actual X509 certificates

1.2 Terminology

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].

1.3 Normative References

[RFC2119]               S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997.

[WSS10-SOAPMSG] OASIS Standard, “Web Services Security: SOAP Message Security 1.0 (WS-Security 2004)”, March 2004.
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf

[WSS11-SOAPMSG] OASIS Standard, “Web Services Security: SOAP Message Security 1.1”, OASIS Standard incorporating Approved Errata, 01 November 2006.
http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-errata-os-SOAPMessageSecurity.pdf           

[WSS10-USERNAME] OASIS Standard, “Web Services Security: UsernameToken Profile 1.0”, March 2004.
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0.pdf

[WSS11-USERNAME] OASIS Standard, “Web Services Security: UsernameToken Profile 1.1”, February 2006.
http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-UsernameTokenProfile.pdf

[WSS10-X509-PROFILE]  OASIS Standard, “Web Services Security: X.509 Certificate Token Profile 1.0”, March 2004.
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0.pdf

[WSS11-X509-PROFILE]  OASIS Standard, “Web Services Security: X.509 Certificate Token Profile 1.1”, OASIS Standard incorporating Approved Errata, 01 November 2006.
http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-errata-os-x509TokenProfile.pdf

[WSS10-SAML11-PROFILE]  OASIS Standard, “Web Services Security: SAML Token Profile 1.0”, December 2004.
http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0.pdf

[WSS11-SAML1120-PROFILE]  OASIS Standard, “Web Services Security: SAML Token Profile 1.1”, OASIS Standard Incorporating Approved Errata, 1 November 2006.
http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-errata-os-SAMLTokenProfile.pdf

[WSS11-LIBERTY-SAML20-PROFILE] http://www.projectliberty.org/liberty/content/download/894/6258/file/liberty-idwsf-security-mechanisms-saml-profile-v2.0.pdf

[WSS-TC-ALL-TOKEN-PROFILES]  OASIS WS-Security TC links to all other WSS 1.0 and WSS 1.1 token profiles
http://www.oasis-open.org/specs/index.php#wssv1.0
http://www.oasis-open.org/specs/index.php#wssv1.1
and other documents (interops) in the TC repository:
http://www.oasis-open.org/committees/documents.php?wg_abbrev=wss

[WS-SECURITYPOLICY]  OASIS Standard, “WS-SecurityPolicy 1.2”, July 2007.
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.doc

[WS-SECURECONVERSATION] OASIS Standard, “WS-SecureConversation 1.3”, March 2007.  http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/ws-secureconversation-1.3-os.doc

[WS-TRUST]            OASIS Standard, “WS-Trust 1.3”, March 2007.
http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.doc

[WS-POLICY]          http://www.w3.org/TR/ws-policy

[WS-POLICYATTACHMENT]  http://www.w3.org/TR/ws-policy-attach

[WSDL]                   http://www.w3.org/TR/wsdl

[SSL]                      http://www.ietf.org/rfc/rfc2246.txt

[SAML11-CORE]     OASIS Standard, “Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V1.1”, September 2003.
http://www.oasis-open.org/committees/download.php/3406/oasis-sstc-saml-core-1.1.pdf

[SAML20-CORE]     OASIS Standard, “Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0”, March 2005.
http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf

[XML-DSIG]            http://www.w3.org/TR/xmldsig-core/

[XML-ENCR]           http://www.w3.org/TR/xmlenc-core/

1.4 Non-Normative References

WSS10-INTEROP-01:     OASIS Working Draft 06, “Web Services Security: Interop 1 Scenarios”, Jun 2003. 
http://www.oasis-open.org/committees/download.php/11374/wss-interop1-draft-06-merged-changes.pdf

 

WSS10-INTEROP-02:     OASIS Working Draft 06, “Web Services Security: Interop 2 Scenarios”, Oct 2003.
http://www.oasis-open.org/committees/download.php/11375/wss-interop2-draft-06-merged.doc

WSS11-INTEROP-01:     OASIS Working Draft 02, “Web Services Security 1.1: Interop Scenario”, June 2005. http://www.oasis-open.org/committees/download.php/12997/wss-11-interop-draft-01.doc

WSS10-KERBEROS-INTEROP:   OASIS Working Draft 02, “Web Services Security: Kerberos Token Profile Interop Scenarios”, Jan 2005.  
http://www.oasis-open.org/committees/download.php/11720/wss-kerberos-interop.doc

WSS10-SAML11-INTEROP:  OASIS Working Draft 12, “Web Services Security: SAML Interop 1 Scenarios”, July 2004.
http://www.oasis-open.org/committees/download.php/7702/wss-saml-interop1-draft-12.doc

WSS11-SAML1120-INTEROP:  OASIS Working Draft 4, “Web Services Security: SAML 2.0  Interop Scenarios”, January 2005.
http://www.oasis-open.org/committees/download.php/16556/wss-saml2-interop-draft-v4.doc

WSSX-PRE-INTEROP:   OASIS Contribution Version 1.0d,  “WS-SecureConversation and WS-Trust Interop Scenarios”, September 29, 2004.
http://docs.oasis-open.org/ws-sx/security-policy/examples/ws-sp-usecases-examples.html

WSSX-WSTR-WSSC-INTEROP: OASIS White Paper Version ED-10, “WS-SX Interop Scenarios - Phase 2 Scenarios for demonstration of WS-SX TC specifications”, October 31, 2006. http://www.oasis-open.org/committees/download.php/20954/ws-sx-interop-ed-10.doc

WS-SECURE-INTEROP: OASIS White Paper Version ED-01, “Examples of Secure Web Service Message Exchange”, July 11, 2008.  
http://www.oasis-open.org/committees/download.php/28803/ws-sx-secure-message-examples.doc

WSI-SCM-SAMPLEAPPL:  http://java.sun.com/webservices/docs/1.4/wsi-sampleapp/index.html (login required)  

1.5 Specifications

1.6 Interops and Sample Messages

2      Scenarios

2.1 UsernameToken

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

2.1.1 UsernameToken – no security binding

In this model a UsernameToken is placed within a WS-Security header in the SOAP Header [WSS10-USERNAME, WSS11-USERNAME]. No other security measure is used.

Because no security binding is used, there is no explicit distinction between the Requestor, who is identified in the UsernameToken and the Initiator, who physically sends the message. They may be one and the same or distinct parties. The lack of a security binding indicates that any direct URL access method (ex. HTTP) may be used to access the service.

2.1.1.1 UsernameToken with plain text password

This scenario is based on the first WS-Security Interop Scenarios Document [WSS10-INTEROP-01 Scenario 1 – section 3.4.4]

(http://www.oasis-open.org/committees/download.php/11374/wss-interop1-draft-06-merged-changes.pdf).

This policy says that Requestor/Initiator must send a password in a UsernameToken in a WS-Security header to the Recipient (who as the Authority will validate the password). The password is required because that is the default requirement for the Web Services Security Username Token Profile 1.x [WSS10-USERNAME, WSS11-USERNAME].

This setup is only recommended where confidentiality of the password is not an issue, such as a pre-production test scenario with dummy passwords, which might be used to establish that the Initiator can read the policy and prepare the message correctly, and that connectivity and login to the service can be performed.

 

(P001)     <wsp:Policy>

(P002)       <sp:SupportingTokens>

(P003)         <wsp:Policy>

(P004)           <sp:UsernameToken sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient"

(P005)         </wsp:Policy>

(P006)       </sp:SupportingTokens>

(P007)     </wsp:Policy>

 

An example of a message that conforms to the above stated policy is as follows.

 

(M001)          <?xml version="1.0" encoding="utf-8" ?>

(M002)          <soap:Envelope xmlns:soap="...">

(M003)            <soap:Header>

(M004)              <wsse:Security soap:mustUnderstand=“1” xmlns:wsse="...">

(M005)                <wsse:UsernameToken>

(M006)                  <wsse:Username>Chris</wsse:Username>

(M007)                  <wsse:Password Type=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText”>sirhC</wsse:Password>

(M008)                  <wsse:Nonce EncodingType="...#Base64Binary"

(M009)                     >pN...=</wsse:Nonce>

(M010)                  <wsu:Created>2007-03-28T18:42:03Z</wsu:Created>

(M011)                </wsse:UsernameToken>

(M012)              </wsse:Security>

(M013)            </soap:Header>

(M014)            <soap:Body>

(M015)              <Ping xmlns="http://xmlsoap.org/Ping">

(M016)                <text>EchoString</text>

(M017)              </Ping>

(M018)            </soap:Body>

(M019)     </soap:Envelope>

 

The UsernameToken element starting on line (M005) satisfies the UsernameToken assertion on line (P004). By default, a Password element is included in the UsernameToken on line (M007) holding a plain text password. Lines (M008-M010) contain an optional Nonce element and Created timestamp, which, while optional, are recommended to improve security of requests against replay and other attacks [WSS10‑USERNAME]. All WS-Security compliant implementations should support the UsernameToken with cleartext password with or without the Nonce and Created elements.

2.1.1.2 UsernameToken without password

This policy is the same as 2.1.1.1 except no password is to be placed in the UsernameToken. There are no credentials to further establish the identity of the Requestor and no security binding that the Initiator is required to use. This is a possible production scenario where all the service provider wants is a UsernameToken to associate with the request. There is no explicit Authority implied in this scenario, except possibly that the username extracted from the UsernameToken would be evaluated by a server-side “Authority” that maintained a list of valid username values.

 

(P001)     <wsp:Policy xmlns:wsp="..." xmlns:sp="...">

(P002)       <sp:SupportingTokens>

(P003)         <wsp:Policy>

(P004)           <sp:UsernameToken sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">

(P005)             <wsp:Policy>

(P006)               <sp:NoPassword/>

(P007)             </wsp:Policy>

(P008)           </sp:UsernameToken>

(P009)         </wsp:Policy>

(P010)       </sp:SupportingTokens>

(P011)     </wsp:Policy>

Lines (P002) – (P010) contain the SupportingToken assertion which includes a UsernameToken  indicating that a UsernameToken must be included in the security header.

Line (P006) requires that the wsse:Password element must not be present in the UsernameToken.

An example of an input message that conforms to the above stated policy is as follows:

 

(M001)     <?xml version="1.0" encoding="utf-8" ?>

(M002)     <soap:Envelope xmlns:soap="...">

(M003)       <soap:Header>

(M004)         <wsse:Security soap:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">

(M005)           <wsse:UsernameToken>

(M006)             <wsse:Username>Chris</wsse:Username>

(M007)           </wsse:UsernameToken>

(M008)         </wsse:Security>

(M009)       </soap:Header>

(M010)       <soap:Body>

(M011)         <Ping xmlns="http://xmlsoap.org/Ping">

(M012)           <text>EchoString</text>

(M013)         </Ping>

(M014)       </soap:Body>

(M015)     </soap:Envelope>

Lines (M005) – (M007) hold the unsecured UsernameToken which only contains the name of user (M006), but no password.

2.1.1.3 UsernameToken with timestamp, nonce and password hash

This scenario is similar to 2.1.1.1, except it is more secure, because the Requestor password is protected by combining it with a nonce and timestamp, and then hashing the combination. Therefore, this may be considered as a potential production scenario where passwords may be safely used. It may be assumed that the password must be validated by a server-side ValidatingAuthority and so must meet whatever requirements the specific Authority has established.

 

(P001)     <wsp:Policy xmlns:wsp="..." xmlns:sp="...">

(P002)       <sp:SupportingTokens>

(P003)         <wsp:Policy>

(P004)           <sp:UsernameToken sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">

(P005)             <wsp:Policy>

(P006)               <sp:HashPassword/>

(P007)             </wsp:Policy>

(P008)           </sp:UsernameToken>

(P009)         </wsp:Policy>

(P010)       </sp:SupportingTokens>

(P011)     </wsp:Policy>

 

An example of a message that conforms to the above stated policy is as follows.

 

(M001)          <?xml version="1.0" encoding="utf-8" ?>

(M002)          <soap:Envelope xmlns:soap="..." xmlns:wsu=”...”>

(M003)            <soap:Header>

(M004)              <wsse:Security soap:mustUnderstand=“1” xmlns:wsse="...">

(M005)                <wsse:UsernameToken
                    wsu:Id="uuid-7cee5976-0111-e9c1-e34b-af1e85fa3866">

(M006)                  <wsse:Username>Chris</wsse:Username>

(M007)             <wsse:Password  Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-usernametoken-profile-1.0#PasswordDigest"
                    >
weYI3nXd8LjMNVksCKFV8t3rgHh3Rw==</wsse:Password>

(M008)             <wsse:Nonce>WScqanjCEAC4mQoBE07sAQ==</wsse:Nonce>

(M009)             <wsu:Created>2007-05-01T01:15:30Z</wsu:Created>

(M010)                </wsse:UsernameToken>

(M011)              </wsse:Security>

(M012)            </soap:Header>

(M013)            <soap:Body wsu:Id="uuid-7cee4264-0111-e0cb-8329-af1e85fa3866">

(M014)              <Ping xmlns="http://xmlsoap.org/Ping">

(M015)                <text>EchoString</text>

(M016)              </Ping>

(M017)            </soap:Body>

(M018)     </soap:Envelope>

 

This message is very similar to the one in section 2.1.1.1. A UsernameToken starts on line (M005) to satisfy the UserNameToken assertion. However, in this example the Password element on line (M007) is of type PasswordDigest to satisfy the HashPassword assertion on line (P006). The Nonce (M008) and Created timestamp (M009) are also included as dictated by the HashPassword assertion. The Nonce and timestamp values are included in the password digest on line (M007).

2.1.2 Use of SSL Transport Binding

Both server authentication and mutual (client AND server) authentication SSL [SSL] are supported via use of the sp:TransportBinding policy assertion. (For mutual authentication, a RequireClientCertificate assertion may be inserted within the HttpsToken assertion. The ClientCertificate may be regarded as a credential token for authentication of the Initiator, which in the absence of any additional token requirements would generally imply the Initiator is also the Requestor. The Authority would be the issuer of the client certificate.)

 

<wsp:Policy xmlns:wsp="..." xmlns:sp="...">
  <sp:TransportBinding>
    <wsp:Policy>
      <sp:TransportToken>
        <wsp:Policy>
          <sp:HttpsToken />
        </wsp:Policy>
      </sp:TransportToken>
      <sp:AlgorithmSuite>
        <wsp:Policy>
          <sp:Basic256 />
        </wsp:Policy>
      </sp:AlgorithmSuite>
      <sp:Layout>
        <wsp:Policy>
          <sp:Strict />
        </wsp:Policy>
      </sp:Layout>
      <sp:IncludeTimestamp />
    </wsp:Policy>
  </sp:TransportBinding>
</wsp:Policy>

2.1.2.1 UsernameToken as supporting token

Additional tokens can be included as supporting tokens. Each of the UsernameTokens described in section 2.1.1 may be used in this scenario and any clear text information or password will be protected by SSL. So, for example, including a user name token over server authentication SSL we have:

 

(P001)  <wsp:Policy xmlns:wsp="..." xmlns:sp="...">

(P002)    <sp:TransportBinding>

(P003)      <wsp:Policy>

(P004)        <sp:TransportToken>

(P005)          <wsp:Policy>

(P006)            <sp:HttpsToken/>

(P007)          </wsp:Policy>

(P008)        </sp:TransportToken>

(P009)        <sp:AlgorithmSuite>

(P010)          <wsp:Policy>

(P011)            <sp:Basic256/>

(P012)          </wsp:Policy>

(P013)        </sp:AlgorithmSuite>

(P014)        <sp:Layout>

(P015)          <wsp:Policy>

(P016)            <sp:Strict/>

(P017)          </wsp:Policy>

(P018)        </sp:Layout>

(P019)        <sp:IncludeTimestamp/>

(P020)      </wsp:Policy>

(P021)    </sp:TransportBinding>

(P022)    <sp:SupportingTokens>

(P023)      <wsp:Policy>

(P024)        <sp:UsernameToken/>

(P025)      </wsp:Policy>

(P026)    </sp:SupportingTokens>

(P027)  </wsp:Policy>

Lines (P002) – (P021) contain the TransportBinding assertion which indicates that the message must be protected by a secure transport protocol like SSL or TLS.

Lines (P004) – (P008) hold the TransportToken assertion, indicating that the transport is secured by means of an HTTPS Transport Token, requiring to perform cryptographic operations based on the transport token using the Basic256 algorithm suite (P011).

In addition, the Layout assertion in lines (P014) – (P018) require that the order of the elements in the SOAP message security header must conform to rules defined by WSSECURITYPOLICY that follow the general principle of 'declare before use'.

Line (P019) indicates that the wsu:Timestamp element must be present in the SOAP message security header.

Lines (P022) – (P026) Lines contain the SupportingToken assertion which includes a UsernameToken  indicating that a UsernameToken must be included in the security header.

An example of an input message prior to the transport encryption that conforms to the above stated policy is as follows:

(M001)  <?xml version="1.0" encoding="utf-8" ?>

(M002)  <soap:Envelope xmlns:soap="..." xmlns:wsu="...">

(M003)    <soap:Header>

(M004)      <wsse:Security soap:mustUnderstand="1" 
              xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-   
              wss-wssecurity-secext-1.0.xsd">

(M005)        <wsu:Timestamp wsu:Id="uuid-8066364f-0111-f371-47bf-ba986d2d7dc4">

(M006)          <wsu:Created>2001-09-13T08:42:00Z</wsu:Created>

(M007)        </wsu:Timestamp>

(M008)        <wsse:UsernameToken
                 wsu:Id="uuid-8066368d-0111-e744-f37b-ba986d2d7dc4">

(M009)          <wsse:Username>Chris</wsse:Username>

(M010)          <wsse:Password Type=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText”>sirhC</wsse:Password>

(M011)        </wsse:UsernameToken>

(M012)      </wsse:Security>

(M013)    </soap:Header>

(M014)    <soap:Body wsu:Id="uuid-8066363f-0111-ffdc-de48-ba986d2d7dc4">

(M015)      <Ping xmlns="http://xmlsoap.org/Ping">

(M016)        <text>EchoString</text>

(M017)      </Ping>

(M018)    </soap:Body>

(M019)  </soap:Envelope>

Lines (M005) – (M007) hold Timestamp element according to the IncludeTimestamp assertion.

Lines (M008) – (M011) hold the UsernameToken which contains the name (M009) and password (M010) of the user sending this message.


2.1.3 (WSS 1.0) UsernameToken with Mutual X.509v3 Authentication, Sign, Encrypt

This scenario is based on WS-I SCM Security Architecture Technical requirements for securing the SCM Sample Application, March 2006 [WSI-SCM-SAMPLEAPPL – GetCatalogRequest, SubmitOrderRequest].

This use case corresponds to the situation where both parties have X.509v3 certificates (and public-private key pairs). The Initiator includes a user name token that may stand for the Requestor on-behalf-of which the Initiator is acting. The UsernameToken is included as a SupportingToken; this is also encrypted. The Authority for this request is generally the Subject of the Initiator’s trusted X.509 Certificate.

We model this by using the asymmetric security binding [WSSP] with a UsernameToken SupportingToken.

The message level policies in this section and subsequent sections cover a different scope of the web service definition than the security binding level policy and so appear as separate policies and are attached at WSDL Message Policy Subject. These are shown below as input and output policies.  Thus, we need a set of coordinated policies one with endpoint subject and two with message subjects to achieve this use case.

The policy is as follows:

(P001)  <wsp:Policy wsu:Id="wss10_up_cert_policy" >

(P002)    <wsp:ExactlyOne>

(P003)      <wsp:All>

(P004)        <sp:AsymmetricBinding>

(P005)          <wsp:Policy>

(P006)            <sp:InitiatorToken>

(P007)              <wsp:Policy>

(P008)                <sp:X509Token sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">

(P009)                  <wsp:Policy>

(P010)                    <sp:WssX509V3Token10/>

(P011)                  </wsp:Policy>

(P012)                </sp:X509Token>

(P013)              </wsp:Policy>

(P014)            </sp:InitiatorToken>

(P015)            <sp:RecipientToken>

(P016)              <wsp:Policy>

(P017)                <sp:X509Token sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never">

(P018)                  <wsp:Policy>

(P019)                    <sp:WssX509V3Token10/>

(P020)                  </wsp:Policy>

(P021)                </sp:X509Token>

(P022)              </wsp:Policy>

(P023)            </sp:RecipientToken>

(P024)            <sp:AlgorithmSuite>

(P025)              <wsp:Policy>

(P026)                <sp:Basic256/>

(P027)              </wsp:Policy>

(P028)            </sp:AlgorithmSuite>

(P029)            <sp:Layout>

(P030)              <wsp:Policy>

(P031)                <sp:Strict/>

(P032)              </wsp:Policy>

(P033)            </sp:Layout>

(P034)            <sp:IncludeTimestamp/>

(P035)            <sp:OnlySignEntireHeadersAndBody/>

(P036)          </wsp:Policy>

(P037)        </sp:AsymmetricBinding>

(P038)        <sp:Wss10>

(P039)          <wsp:Policy>

(P040)            <sp:MustSupportRefKeyIdentifier/>

(P041)          </wsp:Policy>

(P042)        </sp:Wss10>

(P043)        <sp:SignedEncryptedSupportingTokens>

(P044)          <wsp:Policy>

(P045)            <sp:UsernameToken sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">

(P046)              <wsp:Policy>

(P047)                <sp:WssUsernameToken10/>

(P048)              </wsp:Policy>

(P049)            </sp:UsernameToken>

(P050)          </wsp:Policy>

(P051)        </sp:SignedEncryptedSupportingTokens>

(P052)      </wsp:All>

(P053)    </wsp:ExactlyOne>

</wsp:Policy>

 

(P054)  <wsp:Policy wsu:Id="WSS10UsernameForCertificates_input_policy">

(P055)    <wsp:ExactlyOne>

(P056)      <wsp:All>

(P057)        <sp:SignedParts>

(P058)          <sp:Body/>

(P059)        </sp:SignedParts>

(P060)        <sp:EncryptedParts>

(P061)          <sp:Body/>

(P062)        </sp:EncryptedParts>

(P063)      </wsp:All>

(P064)    </wsp:ExactlyOne>

(P065)  </wsp:Policy>

 

(P066)  <wsp:Policy wsu:Id="WSS10UsernameForCertificate_output_policy">

(P067)    <wsp:ExactlyOne>

(P068)      <wsp:All>

(P069)        <sp:SignedParts>

(P070)          <sp:Body/>

(P071)        </sp:SignedParts>

(P072)        <sp:EncryptedParts>

(P073)          <sp:Body/>

(P074)        </sp:EncryptedParts>

(P075)      </wsp:All>

(P076)    </wsp:ExactlyOne>

(P077)  </wsp:Policy>

Lines (P004) – (P037) contain the AsymmetricBinding assertion which indicates that the initiator’s token must be used for the message signature and the recipient’s token must be used for message encryption.

Lines (P006) – (P014) contain the InitiatorToken assertion. Within that assertion lines (P008) – (P012) indicate that the initiator token must be an X.509 token that must be included with all messages sent to the recipient. Line (P010) dictates the X.509 token must be an X.509v3 security token as described in the WS-Security 1.0 X.509 Token Profile.

Lines (P015) – (P023) contain the RecipientToken assertion. Within that assertion lines (P017) – (P021) dictate the recipient token must also be an X.509 token as described in the WS-Security 1.0 X.509 Token Profile, however as stated on line (P017) it must not be included in any message. Instead, according to the MustSupportKeyRefIdentitier assertion on line (P040) a KeyIdentifier must be used to identify the token in any messages where the token is used.

Line (P034) requires the inclusion of a timestamp.

Lines (P043) – (P051) contain a SignedEncryptedSupportingTokens assertion which identifies the inclusion of an additional token which must be included in the message signature and encrypted. Lines (P045) – (P049) indicate that the supporting token must be a UsernameToken and must be included in all messages to the recipient. Line (P047) dictates the UsernameToken must conform to the WS-Security 1.0 UsernameToken Profile.

Lines (P055) – (P066) contain a policy that is attached to the input message. Lines (P058) – (P060) require that the body of the input message must be signed. Lines (P061) – (P063) require the body of the input message must be encrypted.

Lines (P067) – (P078) contain a policy that is attached to the output message. Lines (P070) – (P072) require that the body of the output message must be signed. Lines (P073) – (P075) require the body of the output message must be encrypted.

An example of an input message that conforms to the above stated policy is as follows.

(M001)  <?xml version="1.0" encoding="utf-8" ?>

(M002)  <soap:Envelope xmlns:soap="..." xmlns:xenc="..." xmlns:ds="...">

(M003)    <soap:Header>

(M004)      <wsse:Security soap:mustUnderstand=“1” xmlns:wsse="..." xmlns:wsu="...">

(M005)        <xenc:ReferenceList>

(M006)          <xenc:DataReference URI="#encUT"/>

(M007)          <xenc:DataReference URI=”#encBody”/>

(M008)        </xenc:ReferenceList>

(M009)        <wsu:Timestamp wsu:Id="T0">

(M010)          <wsu:Created>2001-09-13T08:42:00Z</wsu:Created>

(M011)        </wsu:Timestamp>

(M012)        <wsse:BinarySecurityToken wsu:Id="binaryToken" ValueType="…#X509v3" EncodingType="…#Base64Binary">

(M013)          MIIEZzCCA9CgAwIBAgIQEmtJZc0…

(M014)        </wsse:BinarySecurityToken>

(M015)        <xenc:EncryptedData wsu:Id="encUT">

(M016)          <ds:KeyInfo>

(M017)            <wsse:SecurityTokenReference>

(M018)              <wsse:KeyIdentifier EncodingType="...#Base64Binary" ValueType="...#X509SubjectKeyIdentifier">

(M019)                MIGfMa0GCSq…

(M020)              </wsse:KeyIdentifier>

(M021)            </wsse:SecurityTokenReference>

(M022)          </ds:KeyInfo>

(M023)          <xenc:CipherData>

(M024)            <xenc:CipherValue>...</xenc:CipherValue>

(M025)          </xenc:CipherData>

(M026)        </xenc:EncryptedData>

(M027)        <ds:Signature>

(M028)          <ds:SignedInfo>…

(M029)            <ds:Reference URI="#T0">…</ds:Reference>

(M030)            <ds:Reference URI="#usernameToken">…</ds:Reference>

(M031)            <ds:Reference URI="#body">…</ds:Reference>

(M032)          </ds:SignedInfo>

(M033)          <ds:SignatureValue>HFLP…</ds:SignatureValue>

(M034)          <ds:KeyInfo>

(M035)            <wsse:SecurityTokenReference>

(M036)              <wsse:Reference URI="#binaryToken"/>

(M037)            </wsse:SecurityTokenReference>

(M038)          </ds:KeyInfo>

(M039)        </ds:Signature>

(M040)      </wsse:Security>

(M041)    </soap:Header>

(M042)    <soap:Body wsu:Id="body">

(M043)      <xenc:EncryptedData wsu:Id="encBody">

(M044)        <ds:KeyInfo>

(M045)          <wsse:SecurityTokenReference>

(M046)            <wsse:KeyIdentifier EncodingType="...#Base64Binary" ValueType="...#X509SubjectKeyIdentifier">

(M047)              MIGfMa0GCSq…

(M048)            </wsse:KeyIdentifier>

(M049)          </wsse:SecurityTokenReference>

(M050)        </ds:KeyInfo>

(M051)        <xenc:CipherData>

(M052)          <xenc:CipherValue>...</xenc:CipherValue>

(M053)        </xenc:CipherData>

(M054)      </xenc:EncryptedData>

(M055)    </soap:Body>

(M056)  </soap:Envelope>

Line (M006) is an encryption data reference that references the encrypted UsernameToken on lines (M015) – (M024) which was required to be included by the SignedEncryptedSupportingTokens assertion. Lines (M018) – (M020) hold a KeyIdentifier of the recipient’s token used to encrypt the UsernameToken as required by the AsymmetricBinding assertion. Because the RecipientToken assertion disallowed the token from being inserted into the message, a KeyIdentifier is used instead of a reference to an included token.

Line (M007) is an encryption data reference that references the encrypted body of the message on lines (M043) – (M054). The encryption was required by the EncryptedParts assertion of the input message policy. It also uses the recipient token as identified by the KeyIdentifier.

Lines (M009) – (M011) contain a timestamp for the message as required by the IncludeTimestamp assertion.

Lines (M012) – (M014) contain the BinarySecurityToken holding the X.509v3 certificate of the initiator as required by the InitiatorToken assertion.

Lines (M027) – (M039) contain the message signature.

Line (M029) indicates the message timestamp is included in the signature as required by the IncludeTimestamp assertion definition.

Line (M030) indicates the supporting UsernameToken is included in the signature as required by the SignedEncryptedSupportingTokens assertion. Because the token was encrypted its content prior to encryption is included below to better illustrate the reference.

(M057)   <wsse:UsernameToken wsu:Id="usernameToken">

(M058)     <wsse:Username>Chris</wsse:Username>

(M059)     <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">sirhC</wsse:Password>

(M060)   </wsse:UsernameToken>

Line (M031) indicates the message body is included in the signature as required by the SignedParts assertion of the input message policy.

Note that the initiator’s BinarySecurityToken is not included in the message signature as it was not required by policy.

Line (M036) references the initiator’s BinarySecurityToken included in the message for identifying the key used for signing as dictated by the AsymmetricBinding assertion.

2.1.3.1  (WSS 1.0) Encrypted UsernameToken with X.509v3

This scenario is based on the first WS-Security Interop Scenarios Document [WSS10-INTEROP-01 Scenario 2 – section 4.4.4]

(http://www.oasis-open.org/committees/download.php/11374/wss-interop1-draft-06-merged-changes.pdf).

This policy says that Requestor/Initiator must send a password in an encrypted UsernameToken in a WS-Security header to the Recipient (who as the Authority will validate the password). The password is required because that is the default requirement for the Web Services Security Username Token Profile 1.x [WSS10-USERNAME, WSS11-USERNAME].

This setup is only recommended when the sender cannot provide the “message signature” and it is recommended that the receiver employs some security mechanisms external to the message to prevent the spoofing attacks. 

The policy is as follows:

(P001)  <wsp:Policy wsu:Id="wss10_encrypted_unt_policy" >

(P002)    <sp:AsymmetricBinding>

(P003)      <wsp:Policy>

(P004)        <sp:InitiatorEncryptionToken>

(P005)          <wsp:Policy>

(P006)            <sp:X509Token sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never">

(P007)              <wsp:Policy>

(P008)                <sp:WssX509V3Token10/>

(P009)              </wsp:Policy>

(P010)            </sp:X509Token>

(P011)          </wsp:Policy>

(P012)        </sp:InitiatorEncryptionToken>

(P013)        <sp:RecipientSignatureToken>

(P014)          <wsp:Policy>

(P015)            <sp:X509Token sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never">

(P016)              <wsp:Policy>

(P017)                <sp:WssX509V3Token10/>

(P018)              </wsp:Policy>

(P019)            </sp:X509Token>

(P020)          </wsp:Policy>

(P021)        </sp:RecipientSignatureToken>

(P022)        <sp:AlgorithmSuite>

(P023)          <wsp:Policy>

(P024)            <sp:Basic256/>

(P025)          </wsp:Policy>

(P026)        </sp:AlgorithmSuite>

(P027)        <sp:Layout>

(P028)          <wsp:Policy>

(P029)            <sp:Lax/>

(P030)          </wsp:Policy>

(P031)        </sp:Layout>

(P032)        <sp:IncludeTimestamp/>

(P033)        <sp:OnlySignEntireHeadersAndBody/>

(P034)      </wsp:Policy>

(P035)   </sp:AsymmetricBinding>

(P036)   <sp:Wss10>

(P037)     <wsp:Policy>

(P038)       <sp:MustSupportRefKeyIdentifier/>

(P039)       <sp:MustSupportRefIssuerSerial/>

(P040)     </wsp:Policy>

(P041)    </sp:Wss10>

(P042)    <sp:EncryptedSupportingTokens>

(P043)      <wsp:Policy>

(P044)        <sp:UsernameToken sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">

(P045)          <wsp:Policy>

(P046)            <sp:HashPassword/>

(P047)            <sp:WssUsernameToken10/>

(P048)          </wsp:Policy>

(P049)        </sp:UsernameToken>

(P050)      </wsp:Policy>

(P051)    </sp:EncryptedSupportingTokens>

(P052)  </wsp:Policy>

(P053)  <wsp:Policy wsu:Id="WSS10UsernameForCertificates_input_policy">

(P054)    <wsp:ExactlyOne>

(P055)      <wsp:All>

(P056)        <sp:EncryptedParts>

(P057)          <sp:Body/>

(P058)        </sp:EncryptedParts>

(P059)      </wsp:All>

(P060)    </wsp:ExactlyOne>

(P061)  </wsp:Policy>

(P062)  <wsp:Policy wsu:Id="WSS10UsernameForCertificate_output_policy">

(P063)    <wsp:ExactlyOne>

(P064)      <wsp:All>

(P065)        <sp:SignedParts>

(P066)          <sp:Body/>

(P067)        </sp:SignedParts>

(P068)      </wsp:All>

(P069)    </wsp:ExactlyOne>

(P070)  </wsp:Policy>

Lines (P002) – (P035) contain the AsymmetricBinding assertion which indicates that the recipient’s token must be used for both message signature and encryption.

Lines (P004) – (P012) contain the InitiatorEncryptionToken assertion. Within that assertion lines (P006) – (P010) indicate that the initiator token must be an X.509 token. Line (P008) dictates the X.509 token must be an X.509v3 security token as described in the WS-Security 1.0 X.509 Token Profile, however as stated on line (P006) it must not be included in any message.

Lines (P013) – (P021) contain the RecipientSignatureToken assertion. Within that assertion lines (P015) – (P019) dictate the recipient token must also be an X.509 token as described in the WS-Security 1.0 X.509 Token Profile for message signature, however as stated on line (P017) it must not be included in any message.

Line (P032) requires the inclusion of a timestamp.

Line (P035) OnlySignEntireHeadersAndBody assertion will only apply to the response message, as there is no signature token defined for the Initiator.

Lines (P036) – (P041) contain some WS-Security 1.0 related interoperability requirements, specifically support for key identifier, and issuer serial number.

Lines (P042) – (P051) contain an EncryptedSupportingTokens assertion which identifies the inclusion of an additional token which must be included in the message and encrypted. Lines (P044) – (P049) indicate that the supporting token must be a UsernameToken and must be included in all messages to the recipient. Line (P046) dictates the UsernameToken must be hash into digest format, instead of clear text password. Line (P047) dictates the UsernameToken must conform to the WS-Security 1.0 UsernameToken Profile.

Lines (P053) – (P061) contain a policy that is attached to the input message. Lines (P056) – (P058) require the body of the input message must be encrypted.

Lines (P062) – (P070) contain a policy that is attached to the output message. Lines (P065) – (P068) require the body of the output message must be signed.

 

An example of a request message that conforms to the above stated policy is as follows.

(M001)  <?xml version="1.0" encoding="utf-8" ?>

(M002)  <soapenv:Envelope  xmlns:soapenv="..."   xmlns:xenc="..." . . . >

(M003)    <soapenv:Header>

(M004)      <wsse:Security xmlns:wsse="..." xmlns:wsu="..." xmlns:ds="..." soapenv:mustUnderstand="1"  >

(M005)        <xenc:EncryptedKey>

(M006)          <xenc:EncryptionMethod Algorithm=". . .#rsa-oaep-mgf1p">

(M007)            <ds:DigestMethod Algorithm=". . .#sha1" />

(M008)          </xenc:EncryptionMethod>

(M009)          <ds:KeyInfo>

(M010)            <wsse:SecurityTokenReference >

(M011)              <wsse:KeyIdentifier EncodingType="...#Base64Binary"

(M012)                ValueType="...#X509SubjectKeyIdentifier">CuJ. . .=</wsse:KeyIdentifier>

(M013)            </wsse:SecurityTokenReference>

(M014)          </ds:KeyInfo>

(M015)          <xenc:CipherData>

(M016)            <xenc:CipherValue>dbj...=</xenc:CipherValue>

(M017)          </xenc:CipherData>

(M018)          <xenc:ReferenceList>

(M019)            <xenc:DataReference URI="#encBody"/>

(M020)            <xenc:DataReference URI="#encUnt"/>

(M021)          </xenc:ReferenceList>

(M022)        </xenc:EncryptedKey>

(M023)        <xenc:EncryptedData Id="encUnt" Type="...#Element" MimeType="text/xml" Encoding="UTF-8" >

(M024)          <xenc:EncryptionMethod Algorithm="...#aes256-cbc"/>

(M025)          <xenc:CipherData>

(M026)            <xenc:CipherValue>KZf...=</xenc:CipherValue>

(M027)          </xenc:CipherData>

(M028)        </xenc:EncryptedData>

(M029)        <wsu:Timestamp >

(M030)          <wsu:Created>2007-03-28T18:42:03Z</wsu:Created>

(M031)        </wsu:Timestamp>

(M032)      </wsse:Security>

(M033)    </soapenv:Header>

(M034)    <soapenv:Body >

(M035)      <xenc:EncryptedData Id="encBody" Type="...#Content" MimeType="text/xml" Encoding="UTF-8" >

(M036)        <xenc:EncryptionMethod Algorithm="...#aes256-cbc"/>

(M037)        <xenc:CipherData>

(M038)          <xenc:CipherValue>a/9...B</xenc:CipherValue>

(M039)        </xenc:CipherData>

(M040)      </xenc:EncryptedData>

(M041)    </soapenv:Body>

(M042)  </soapenv:Envelope>

Line (M020) is an encryption data reference that references the encrypted UsernameToken on lines (M023) – (M028) which was required to be included by the EncryptedSupportingTokens assertion. Lines (M009) – (M014) hold a KeyIdentifier of the recipient’s token used to encrypt the UsernameToken as required by the AsymmetricBinding assertion. Because the InitiatorEncryptionAssertion disallowed the token from being inserted into the message, a KeyIdentifier is used instead of a reference to an included token.

Line (M019) is an encryption data reference that references the encrypted body of the message on lines (M035) – (M040). The encryption was required by the EncryptedParts assertion of the input message policy. It also uses the recipient token as identified by the KeyIdentifier.

Lines (M029) – (M031) contain a timestamp for the message as required by the IncludeTimestamp assertion.

Because the username token was encrypted its content prior to encryption is included below to better illustrate the reference.

(M043)   <wsse:UsernameToken wsu:Id="usernameToken">

(M044)     <wsse:Username>Chris</wsse:Username>

(M045)     <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">oY...=</wsse:Password>

(M046)        <wsse:Nonce EncodingType="...#Base64Binary">pN...=</wsse:Nonce>

(M047)     <wsu:Created>2007-03-28T18:42:03Z</wsu:Created>

(M048)   </wsse:UsernameToken>

Line (M046) contains the Nonce element and Line (M047) contains a timestamp. It is recommended that these two elements should also be included in the PasswordText case for better security [WSS10‑USERNAME].

2.1.4 (WSS 1.1), User Name with Certificates, Sign, Encrypt

This scenario is based on the “Examples of Secure Web Service Message Exchange Document” [WS‑SECURE-INTEROP].      

The use case here is the following: the Initiator generates a symmetric key; the symmetric key is encrypted using the Recipient’s certificate and placed in an encrypted key element. The UsernameToken identifying the Requestor and message body are signed using the symmetric key. The body and UsernameToken are also encrypted. The Authority for this request is generally the Subject of the Initiator’s X509 certificate.

We can use the symmetric security binding [WSSP] with X509token as the protection token to illustrate this case. If derived keys are to be used, then the derived keys property of X509Token should be set.

The policy is as follows:

(P001)     <wsp:Policy wsu:Id="WSS11UsernameWithCertificates_policy">

(P002)       <wsp:ExactlyOne>

(P003)         <wsp:All>

(P004)           <sp:SymmetricBinding>

(P005)             <wsp:Policy>

(P006)               <sp:ProtectionToken>

(P007)                 <wsp:Policy>

(P008)                   <sp:X509Token sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never”>

(P009)                     <wsp:Policy>

(P010)                       <sp:RequireThumbprintReference/>

(P011)                       <sp:WssX509V3Token11/>

(P012)                     </wsp:Policy>

(P013)                   </sp:X509Token>

(P014)                 </wsp:Policy>

(P015)               </sp:ProtectionToken>

(P016)               <sp:AlgorithmSuite>

(P017)                 <wsp:Policy>

(P018)                   <sp:Basic256/>

(P019)                 </wsp:Policy>

(P020)               </sp:AlgorithmSuite>

(P021)               <sp:Layout>

(P022)                 <wsp:Policy>

(P023)                   <sp:Strict/>

(P024)                 </wsp:Policy>

(P025)               </sp:Layout>

(P026)               <sp:IncludeTimestamp/>

(P027)               <sp:OnlySignEntireHeadersAndBody/>

(P028)             </wsp:Policy>

(P029)           </sp:SymmetricBinding>

(P030)           <sp:SignedEncryptedSupportingTokens>

(P031)             <wsp:Policy>

(P032)               <sp:UsernameToken sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">

(P033)                 <wsp:Policy>

(P034)                   <sp:WssUsernameToken11/>

(P035)                 </wsp:Policy>

(P036)               </sp:UsernameToken>

(P037)             </wsp:Policy>

(P038)           </sp:SignedEncryptedSupportingTokens>

(P039)           <sp:Wss11>

(P040)             <wsp:Policy>

(P041)               <sp:MustSupportRefKeyIdentifier/>

(P042)               <sp:MustSupportRefIssuerSerial/>

(P043)               <sp:MustSupportRefThumbprint/>

(P044)               <sp:MustSupportRefEncryptedKey/>

(P045)             </wsp:Policy>

(P046)           </sp:Wss11>

(P047)         </wsp:All>

(P048)       </wsp:ExactlyOne>

(P049)     </wsp:Policy>

 

(P050)     <wsp:Policy wsu:Id="UsernameForCertificates_input_policy">

(P051)       <wsp:ExactlyOne>

(P052)         <wsp:All>

(P053)           <sp:SignedParts>

(P054)             <sp:Body/>

(P055)           </sp:SignedParts>

(P056)           <sp:EncryptedParts>

(P057)             <sp:Body/>

(P058)           </sp:EncryptedParts>

(P059)         </wsp:All>

(P060)       </wsp:ExactlyOne>

(P061)     </wsp:Policy>

 

(P062)     <wsp:Policy wsu:Id="UsernameForCertificate_output_policy">

(P063)       <wsp:ExactlyOne>

(P064)         <wsp:All>

(P065)           <sp:SignedParts>

(P066)             <sp:Body/>

(P067)           </sp:SignedParts>

(P068)           <sp:EncryptedParts>

(P069)             <sp:Body/>

(P070)           </sp:EncryptedParts>

(P071)         </wsp:All>

(P072)       </wsp:ExactlyOne>

(P073)     </wsp:Policy>

Lines (P004) – (P297) contain a SymmetricBinding assertion which indicates the use of one token to both sign and encrypt a message.

Lines (P006) – (P015) contain the ProtectionToken assertion. Within that assertion lines (P008) – (P012) indicate that the protection token must be an X.509 token that must never be included in any messages in the message exchange. Line (P010) dictates the X.509 token must be an X.509v3 security token as described in the WS-Security 1.1 X.509 Token Profile. Line (P011) dicates a thumbprint reference must be used to identify the token in any message.

Line (P026) requires the inclusion of a timestamp.

Lines (P030) – (P038) contain a SignedEncryptedSupportingTokens assertion which identifies the inclusion of an additional token which must be included in the message signature and encrypted. Lines (P032) – (P036) indicate that the supporting token must be a UsernameToken and must be included in all messages to the recipient. Line (P034) dictates the UsernameToken must conform to the WS-Security 1.1 UsernameToken Profile.

Lines (P040) – (P046) contain some WS-Security 1.1 related interoperability requirements, specifically support for key identifier, issuer serial number, thumbprint, and encrypted key references.

Lines (P050) – (P061) contain a policy that is attached to the input message. Lines (P053) – (P055) require that the body of the input message must be signed. Lines (P056) – (P058) require the body of the input message must be encrypted.

Lines (P062) – (P073) contain a policy that is attached to the output message. Lines (P065) – (P067) require that the body of the output message must be signed. Lines (P068) – (P070) require the body of the output message must be encrypted.

An example of an input message that conforms to the above stated policy is as follows.

(M001)     <?xml version="1.0" encoding="utf-8" ?>

(M002)     <soap:Envelope xmlns:soap="..." xmlns:xenc="..." xmlns:ds="...">

(M003)       <soap:Header>

(M004)         <wsse:Security soap:mustUnderstand=“1” xmlns:wsse="..." xmlns:wsu="...">

(M005)           <xenc:EncryptedKey wsu:Id=”EK”>

(M006)             <xenc:EncryptionMethod Algorithm=”http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p”/>

(M007)              <ds:KeyInfo>

(M008)             <wsse:SecurityTokenReference>

(M009)               <wsse:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#ThumbPrintSHA1">

(M010)                 LKiQ/CmFrJDJqCLFcjlhIsmZ/+0=

(M011)               </wsse:KeyIdentifier>

(M012)             </wsse:SecurityTokenReference>

(M013)           </ds:KeyInfo>

(M014)           </xenc:EncryptedKey>

(M015)           <xenc:ReferenceList>

(M016)             <xenc:DataReference URI=”#encUT”/>

(M017)             <xenc:DataReference URI=”#encBody”/>

(M018)           </xenc:ReferenceList>

(M019)           <wsu:Timestamp wsu:Id="T0">

(M020)             <wsu:Created>2001-09-13T08:42:00Z</wsu:Created>

(M021)           </wsu:Timestamp>

(M022)           <xenc:EncryptedData wsu:Id="encUT">

(M023)             <xenc:EncryptionMethod Algorithm=”http://www.w3.org/2001/04/xmlenc#aes256-cbc”/>

(M024)             <ds:KeyInfo>

(M025)               <wsse:SecurityTokenReference>

(M026)                 <wsse:Reference URI=”#EK”/>

(M027)               </wsse:SecurityTokenReference>

(M028)             </ds:KeyInfo>

(M029)             <xenc:CipherData>

(M030)               <xenc:CipherValue>...</xenc:CipherValue>

(M031)             </xenc:CipherData>

(M032)           </xenc:EncryptedData>

(M033)           <ds:Signature>

(M034)             <ds:SignedInfo>…

(M035)               <ds:Reference URI="#T0">…</ds:Reference>

(M036)               <ds:Reference URI="#usernameToken">…</ds:Reference>

(M037)               <ds:Reference URI="#body">…</ds:Reference>

(M038)             </ds:SignedInfo>

(M039)             <ds:SignatureValue>HFLP…</ds:SignatureValue>

(M040)             <ds:KeyInfo>

(M041)               <wsse:SecurityTokenReference>

(M042)                 <wsse:Reference URI=”#EK”/>

(M043)               </wsse:SecurityTokenReference>

(M044)             </ds:KeyInfo>

(M045)           </ds:Signature>

(M046)         </wsse:Security>

(M047)       </soap:Header>

(M048)       <soap:Body wsu:Id="body">

(M049)         <xenc:EncryptedData wsu:Id="encBody">

(M050)           <xenc:EncryptionMethod Algorithm=”http://www.w3.org/2001/04/xmlenc#aes256-cbc”/>

(M051)           <ds:KeyInfo>

(M052)             <wsse:SecurityTokenReference>

(M053)               <wsse:Reference URI=”#EK”/>

(M054)             </wsse:SecurityTokenReference>

(M055)           </ds:KeyInfo>

(M056)           <xenc:CipherData>

(M057)             <xenc:CipherValue>...</xenc:CipherValue>

(M058)           </xenc:CipherData>

(M059)         </xenc:EncryptedData>

(M060)       </soap:Body>

(M061)     </soap:Envelope>

Lines (M005) – (M014) contain the encrypted symmetric key as required by the use of the SymmetricBinding assertion staring on line (P004) with an X509Token ProtectionToken assertion. Line (M006) references the KwRsaOaep Asymmetric Key Wrap algorithm dictated by the Basic 256 Algorithm Suite assertion on line (P018). Lines (M009) – (M011) hold a KeyIdentifier of the protection token used to encrypt the symmetric key as required by the SymmetricBinding assertion. Because the ProtectionToken assertion disallowed the token from being inserted into the message and instead required a thumbprint reference, a thumbprint reference is included to identify the token.

Line (M016) is an encryption data reference that references the encrypted supporting UsernameToken on lines (M022) – (M032). The encryption was required by the SignedEncryptedSupportingTokens assertion on line (P038). Line (M023) references the Aes256 Encryption algorithm dictated by the Basic 256 Algorithm Suite assertion on line (P018). The encrypted symmetric key is used to encrypt the UsernameToken as referenced on line (M026).

Line (M017) is an encryption data reference that references the encrypted body of the message on lines (M049) – (M059). The encryption was required by the EncryptedParts assertion of the input message policy. The encrypted symmetric key is used to encrypt the UsernameToken as referenced on line (M053). 

Lines (M019) – (M021) contain a timestamp for the message as required by the IncludeTimestamp assertion.

Lines (M033) – (M045) contain the message signature.

Line (M035) indicates the message timestamp is included in the signature as required by the IncludeTimestamp assertion definition.

Line (M036) indicates the supporting UsernameToken is included in the signature as required by the SignedSupportingTokens assertion. Because the token was encrypted its content prior to encryption is included below to better illustrate the reference.

(M062)          <wsse:UsernameToken wsu:Id="usernameToken">

(M063)            <wsse:Username>Chris</wsse:Username>

(M064)            <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText ">sirhC</wsse:Password>

(M065)          </wsse:UsernameToken>

Line (M037) indicates the message body is included in the signature as required by the SignedParts assertion of the input message policy.

Line (M042) references the encrypted symmetric key for signing as dictated by the SymmetricBinding assertion.

2.2 X.509 Token Authentication Scenario Assertions

2.2.1 (WSS1.0) X.509 Certificates, Sign, Encrypt

This use-case corresponds to the situation where both parties have X.509v3 certificates (and public-private key pairs). The requestor identifies itself to the service. The message exchange is integrity protected and encrypted.

This modeled by use of an asymmetric security binding assertion.

The message level policies in this and subsequent sections cover a different scope of the web service definition than the security binding level policy and so appear as separate policies and are attached at WSDL Message Policy Subject. These are shown below as input and output policies.  Thus, we need a set of coordinated policies one with endpoint subject and two with message subjects to achieve this use case.

The policies are as follows:

(P001)  <wsp:Policy wsu:Id="wss10_anonymous_with_cert_policy" >

(P002)    <wsp:ExactlyOne>

(P003)      <wsp:All>

(P004)        <sp:AsymmetricBinding>

(P005)          <wsp:Policy>

(P006)            <sp:InitiatorToken>

(P007)              <wsp:Policy>

(P008)                <sp:X509Token sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">

(P009)                  <wsp:Policy>

(P010)                    <sp:WssX509V3Token10/>

(P011)                  </wsp:Policy>

(P012)                </sp:X509Token>

(P013)              </wsp:Policy>

(P014)            </sp:InitiatorToken>

(P015)            <sp:RecipientToken>

(P016)              <wsp:Policy>

(P017)                <sp:X509Token sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never">

(P018)                  <wsp:Policy>

(P019)                    <sp:WssX509V3Token10/>

(P020)                  </wsp:Policy>

(P021)                </sp:X509Token>

(P022)              </wsp:Policy>

(P023)            </sp:RecipientToken>

(P024)            <sp:AlgorithmSuite>

(P025)              <wsp:Policy>

(P026)                <sp:Basic256/>

(P027)              </wsp:Policy>

(P028)            </sp:AlgorithmSuite>

(P029)            <sp:Layout>

(P030)              <wsp:Policy>

(P031)                <sp:Strict/>

(P032)              </wsp:Policy>

(P033)            </sp:Layout>

(P034)            <sp:IncludeTimestamp/>

(P035)            <sp:OnlySignEntireHeadersAndBody/>

(P036)          </wsp:Policy>

(P037)        </sp:AsymmetricBinding>

(P038)        <sp:Wss10>

(P039)          <wsp:Policy>

(P040)            <sp:MustSupportRefKeyIdentifier/>

(P041)          </wsp:Policy>

(P042)        </sp:Wss10>

(P043)      </wsp:All>

(P044)    </wsp:ExactlyOne>

(P045)  </wsp:Policy>

(P046)  <wsp:Policy wsu:Id="WSS10Anonymous_with_Certificates_input_policy">

(P047)    <wsp:ExactlyOne>

(P048)      <wsp:All>

(P049)        <sp:SignedParts>

(P050)          <sp:Body/>

(P051)        </sp:SignedParts>

(P052)        <sp:EncryptedParts>

(P053)          <sp:Body/>

(P054)        </sp:EncryptedParts>

(P055)      </wsp:All>

(P056)    </wsp:ExactlyOne>

(P057)  </wsp:Policy>

(P058)  <wsp:Policy wsu:Id="WSS10anonymous_with_certs_output_policy">

(P059)    <wsp:ExactlyOne>

(P060)      <wsp:All>

(P061)        <sp:SignedParts>

(P062)          <sp:Body/>

(P063)        </sp:SignedParts>

(P064)        <sp:EncryptedParts>

(P065)          <sp:Body/>

(P066)        </sp:EncryptedParts>

(P067)      </wsp:All>

(P068)    </wsp:ExactlyOne>

(P069)  </wsp:Policy>

Lines (P004) – (P037) contain the AsymmetricBinding assertion which indicates that the initiator’s token must be used for the message signature and the recipient’s token must be used for message encryption.

Lines (P006) – (P014) contain the InitiatorToken assertion. Within that assertion lines (P008) – (P012) indicate that the initiator token must be an X.509 token that must be included with all messages sent to the recipient. Line (P010) dictates the X.509 token must be an X.509v3 security token as described in the WS-Security 1.0 X.509 Token Profile.

Lines (P015) – (P023) contain the RecipientToken assertion. Within that assertion lines (P017) – (P021) dictate the recipient token must also be an X.509 token as described in the WS-Security 1.0 X.509 Token Profile, however as stated on line (P017) it must not be included in any message. Instead, according to the MustSupportKeyRefIdentitier assertion on line (P040) a KeyIdentifier must be used to identify the token in any messages where the token is used.

Line (P034) requires the inclusion of a timestamp.

Lines (P046) – (P057) contain a policy that is attached to the input message. Lines (P049) – (P051) require that the body of the input message must be signed. Lines (P052) – (P054) require the body of the input message must be encrypted.

Lines (P058) – (P069) contain a policy that is attached to the output message. Lines (P061) – (P063) require that the body of the output message must be signed. Lines (P064) – (P066) require the body of the output message must be encrypted.

An example of an input message that conforms to the above stated policy is as follows.

(M001)  <?xml version="1.0" encoding="utf-8" ?>

(M002)  <soap:Envelope xmlns:soap="..." xmlns:xenc="..." xmlns:ds="...">

(M003)    <soap:Header>

(M004)      <wsse:Security soap:mustUnderstand=“1” xmlns:wsse="..." xmlns:wsu="...">

(M005)        <xenc:EncryptedKey >

(M006)          <xenc:EncryptionMethod Algorithm="...#rsa-oaep-mgf1p">

(M007)            <ds:DigestMethod Algorithm="...#sha1"/>

(M008)          </xenc:EncryptionMethod>

(M009)          <ds:KeyInfo>

(M010)            <wsse:SecurityTokenReference >

(M011)              <wsse:KeyIdentifier EncodingType="...#Base64Binary" ValueType="...#X509SubjectKeyIdentifier">

(M012)              MIGfMa0GCSq…

(M013)              </wsse:KeyIdentifier>

(M014)            </ds:KeyInfo>

(M015)          <xenc:CipherData>

(M016)            <xenc:CipherValue>Hyx...=</xenc:CipherValue>

(M017)          </xenc:CipherData>

(M018)          <xenc:ReferenceList>

(M019)            <xenc:DataReference URI="#encBody"/>

(M020)          </xenc:ReferenceList>

(M021)        </xenc:EncryptedKey>

(M022)        <wsu:Timestamp wsu:Id="T0">

(M023)          <wsu:Created>2001-09-13T08:42:00Z</wsu:Created>

(M024)        </wsu:Timestamp>

(M025)        <wsse:BinarySecurityToken wsu:Id="binaryToken" ValueType="…#X509v3" EncodingType="…#Base64Binary">

(M026)          MIIEZzCCA9CgAwIBAgIQEmtJZc0…

(M027)        </wsse:BinarySecurityToken>

(M028)        <ds:Signature>

(M029)          <ds:SignedInfo>…

(M030)            <ds:Reference URI="#T0">…</ds:Reference>

(M031)            <ds:Reference URI="#body">…</ds:Reference>

(M032)          </ds:SignedInfo>

(M033)          <ds:SignatureValue>HFLP…</ds:SignatureValue>

(M034)          <ds:KeyInfo>

(M035)            <wsse:SecurityTokenReference>

(M036)              <wsse:Reference URI="#binaryToken"/>

(M037)            </wsse:SecurityTokenReference>

(M038)          </ds:KeyInfo>

(M039)        </ds:Signature>

(M040)      </wsse:Security>

(M041)    </soap:Header>

(M042)    <soap:Body wsu:Id="body">

(M043)      <xenc:EncryptedData wsu:Id="encBody">

(M044)        <xenc:CipherData>

(M045)          <xenc:CipherValue>...</xenc:CipherValue>

(M046)        </xenc:CipherData>

(M047)      </xenc:EncryptedData>

(M048)    </soap:Body>

(M049)  </soap:Envelope>

Line (M019) is an encryption data reference that references the encrypted body of the message on lines (M043) – (M047). The encryption was required by the EncryptedParts assertion of the input message policy. Lines (M011) – (M013) hold a KeyIdentifier of the recipient’s token used to encrypt the body as required by the AsymmetricBinding assertion. Because the RecipientToken assertion disallowed the token from being inserted into the message, a KeyIdentifier is used instead of a reference to an included token.

Lines (M022) – (M024) contain a timestamp for the message as required by the IncludeTimestamp assertion.

Lines (M025) – (M027) contain the BinarySecurityToken holding the X.509v3 certificate of the initiator as required by the InitiatorToken assertion.

Lines (M028) – (M039) contain the message signature.

Line (M030) indicates the message timestamp is included in the signature as required by the IncludeTimestamp assertion definition.

Line (M031) indicates the message body is included in the signature as required by the SignedParts assertion of the input message policy.

Note that the initiator’s BinarySecurityToken is not included in the message signature as it was not required by policy.

Lines (M035) – (M037) references the initiator’s BinarySecurityToken included in the message for identifying the key used for signing as dictated by the AsymmetricBinding assertion.

2.2.2  (WSS1.0) Mutual Authentication with X.509 Certificates, Sign, Encrypt

This scenario is based on WSS Interop, Scenario 3, Web Services Security: Interop 1, Draft 06, Editor, Hal Lockhart, BEA Systems

This use case corresponds to the situation where both parties have X.509v3 certificates (and public-private key pairs). The requestor wishes to identify itself to the service using its X.509 credential (strong authentication). The message exchange needs to be integrity protected and encrypted as well. The difference from previous use case is that the X509 token inserted by the client is included in the message signature (see <ProtectTokens />).

The policy is as follows:

(P001)  <wsp:Policy wsu:Id="wss10_anonymous_with_cert_policy" >

(P002)    <wsp:ExactlyOne>

(P003)      <wsp:All>

(P004)        <sp:AsymmetricBinding>

(P005)          <wsp:Policy>

(P006)            <sp:InitiatorToken>

(P007)              <wsp:Policy>

(P008)                <sp:X509Token sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">

(P009)                  <wsp:Policy>

(P010)                    <sp:WssX509V3Token10/>

(P011)                  </wsp:Policy>

(P012)                </sp:X509Token>

(P013)              </wsp:Policy>

(P014)            </sp:InitiatorToken>

(P015)            <sp:RecipientToken>

(P016)              <wsp:Policy>

(P017)                <sp:X509Token sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never">

(P018)                  <wsp:Policy>

(P019)                    <sp:WssX509V3Token10/>

(P020)                  </wsp:Policy>

(P021)                </sp:X509Token>

(P022)              </wsp:Policy>

(P023)            </sp:RecipientToken>

(P024)            <sp:AlgorithmSuite>

(P025)              <wsp:Policy>

(P026)                <sp:Basic256/>

(P027)              </wsp:Policy>

(P028)            </sp:AlgorithmSuite>

(P029)            <sp:Layout>

(P030)              <wsp:Policy>

(P031)                <sp:Strict/>

(P032)              </wsp:Policy>

(P033)            </sp:Layout>

(P034)            <sp:IncludeTimestamp/>

(P035)            <sp:ProtectTokens />

(P036)            <sp:OnlySignEntireHeadersAndBody/>

(P037)          </wsp:Policy>

(P038)        </sp:AsymmetricBinding>

(P039)        <sp:Wss10>

(P040)          <wsp:Policy>

(P041)            <sp:MustSupportRefKeyIdentifier/>

(P042)          </wsp:Policy>

(P043)        </sp:Wss10>

(P044)      </wsp:All>

(P045)    </wsp:ExactlyOne>

(P046)  </wsp:Policy>

(P047)  <wsp:Policy wsu:Id="WSS10Anonymous with Certificates_input_policy">

(P048)    <wsp:ExactlyOne>

(P049)      <wsp:All>

(P050)        <sp:SignedParts>

(P051)          <sp:Body/>

(P052)        </sp:SignedParts>

(P053)        <sp:EncryptedParts>

(P054)          <sp:Body/>

(P055)        </sp:EncryptedParts>

(P056)      </wsp:All>

(P057)    </wsp:ExactlyOne>

(P058)  </wsp:Policy>

(P059)  <wsp:Policy wsu:Id="WSS10anonymous with certs_output_policy">

(P060)    <wsp:ExactlyOne>

(P061)      <wsp:All>

(P062)        <sp:SignedParts>

(P063)          <sp:Body/>

(P064)        </sp:SignedParts>

(P065)        <sp:EncryptedParts>

(P066)          <sp:Body/>

(P067)        </sp:EncryptedParts>

(P068)      </wsp:All>

(P069)    </wsp:ExactlyOne>

(P070)  </wsp:Policy>

Lines (P004) – (P038) contain the AsymmetricBinding assertion which indicates that the initiator’s token must be used for the message signature and the recipient’s token must be used for message encryption.

Lines (P006) – (P014) contain the InitiatorToken assertion. Within that assertion lines (P008) – (P012) indicate that the initiator token must be an X.509 token that must be included with all messages sent to the recipient. Line (P010) dictates the X.509 token must be an X.509v3 security token as described in the WS-Security 1.0 X.509 Token Profile.

Lines (P015) – (P023) contain the RecipientToken assertion. Within that assertion lines (P017) – (P021) dictate the recipient token must also be an X.509 token as described in the WS-Security 1.0 X.509 Token Profile, however as stated on line (P017) it must not be included in any message. Instead, according to the MustSupportKeyRefIdentitier assertion on line (P040) a KeyIdentifier must be used to identify the token in any messages where the token is used.

Line (P034) requires the inclusion of a timestamp.

Line (P035) requires token protection (ProtectTokens) which dictates that the signature must cover the token used to generate that signature.

Lines (P047) – (P058) contain a policy that is attached to the input message. Lines (P050) – (P052) require that the body of the input message must be signed. Lines (P053) – (P055) require the body of the input message must be encrypted.

Lines (P059) – (P070) contain a policy that is attached to the output message. Lines (P062) – (P064) require that the body of the output message must be signed. Lines (P064) – (P066) require the body of the output message must be encrypted.

An example of an input message that conforms to the above stated policy is as follows.

(M001)  <?xml version="1.0" encoding="utf-8" ?>

(M002)  <soapenv:Envelope  xmlns:soapenv="..." xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsu="..." xmlns:xenc="..." ...>

(M003)    <soapenv:Header>

(M004)      <wsse:Security xmlns:wsse="..." xmlns:ds="..." soapenv:mustUnderstand="1">

(M005)        <xenc:EncryptedKey >

(M006)          <xenc:EncryptionMethod Algorithm="...#rsa-oaep-mgf1p">

(M007)            <ds:DigestMethod Algorithm="...#sha1"/>

(M008)          </xenc:EncryptionMethod>

(M009)          <ds:KeyInfo>

(M010)            <wsse:SecurityTokenReference >

(M011)              <wsse:KeyIdentifier EncodingType="...#Base64Binary"                ValueType="...#X509SubjectKeyIdentifier">CuJd...=</wsse:KeyIdentifier>

(M012)            </wsse:SecurityTokenReference>

(M013)          </ds:KeyInfo>

(M014)          <xenc:CipherData>

(M015)            <xenc:CipherValue>Hyx...=</xenc:CipherValue>

(M016)          </xenc:CipherData>

(M017)          <xenc:ReferenceList>

(M018)            <xenc:DataReference URI="#encBody"/>

(M019)          </xenc:ReferenceList>

(M020)        </xenc:EncryptedKey>

(M021)        <wsu:Timestamp wsu:Id="Timestamp" >

(M022)          <wsu:Created>2007-03-26T16:53:39Z</wsu:Created>

(M023)        </wsu:Timestamp>

(M024)        <wsse:BinarySecurityToken wsu:Id="bst" ValueType="...#X509v3"           EncodingType="...#Base64Binary">MIID...=</wsse:BinarySecurityToken>

(M025)        <ds:Signature>

(M026)          <ds:SignedInfo>

(M027)            <ds:CanonicalizationMethod Algorithm=".../xml-exc-c14n#"/>

(M028)            <ds:SignatureMethod Algorithm="...#rsa-sha1"/>

(M029)            <ds:Reference URI="#Timestamp">

(M030)              <ds:Transforms>... </ds:Transforms>

(M031)              <ds:DigestMethod Algorithm="...#sha1"/>

(M032)              <ds:DigestValue>+g0I...=</ds:DigestValue>

(M033)            </ds:Reference>

(M034)            <ds:Reference URI="#Body">...</ds:Reference>

(M035)            <ds:Reference URI="#bst">..</ds:Reference>

(M036)          </ds:SignedInfo>

(M037)          <ds:SignatureValue>RRT...=</ds:SignatureValue>

(M038)          <ds:KeyInfo>

(M039)            <wsse:SecurityTokenReference >

(M040)              <wsse:KeyIdentifier EncodingType="...#Base64Binary"                ValueType="...#X509SubjectKeyIdentifier">Xeg5...=</wsse:KeyIdentifier>

(M041)            </wsse:SecurityTokenReference>

(M042)          </ds:KeyInfo>

(M043)        </ds:Signature>

(M044)      </wsse:Security>

(M045)    </soapenv:Header>

(M046)    <soapenv:Body wsu:Id="Body" >

(M047)      <xenc:EncryptedData Id="encBody" Type="...#Content"

(M048)         MimeType="text/xml" Encoding="UTF-8" >

(M049)        <xenc:EncryptionMethod Algorithm="...#aes256-cbc"/>

(M050)        <xenc:CipherData>

(M051)          <xenc:CipherValue>W84fn...1</xenc:CipherValue>

(M052)        </xenc:CipherData>

(M053)      </xenc:EncryptedData>

(M054)    </soapenv:Body>

(M055)  </soapenv:Envelope>

Line (M018) is an encryption data reference that references the encrypted body of the message on lines (M047) – (M048). The encryption was required by the EncryptedParts assertion of the input message policy. Lines (M009) – (M013) hold a KeyIdentifier of the recipient’s token used to encrypt the body as required by the AsymmetricBinding assertion. Because the RecipientToken assertion disallowed the token from being inserted into the message, a KeyIdentifier is used instead of a reference to an included token.

Lines (M021) – (M023) contain a timestamp for the message as required by the IncludeTimestamp assertion.

Line (M024) contains the BinarySecurityToken holding the X.509v3 certificate of the initiator as required by the InitiatorToken assertion.

Lines (M025) – (M043) contain the message signature.

Line (M029) indicates the message timestamp is included in the signature as required by the IncludeTimestamp assertion definition.

Line (M034) indicates the message body is included in the signature as required by the SignedParts assertion of the input message policy.

Line (M035) indicates the BinarySecurityToken on Line (M024) is included in the signature as required by the ProtectTokens assertion of the AsymmetricBinding assertion policy.

Note that the recipient’s token is not explicitly included in the security header, as it is required not to be by policy (P017). Instead a KeyIdentifier, line (M011) is used to identify the recipient’s that should be used to decrypt the EncryptedData.

Lines (M039) – (M041) reference the initiator’s BinarySecurityToken on line (M034), which is included in the message to contain the key used for verifying as dictated by the AsymmetricBinding assertion.

2.2.2.1  (WSS1.0) Mutual Authentication, X.509 Certificates, Symmetric Encryption

This scenario is based on WSS Interop, Scenario 4, Web Services Security: Interop 2.

A common variation on the previous example is where X.509 Certificates are still used for authentication, but a mutually agreed upon symmetric key is used for encryption.

In this use case the policy is the same except that the InitiatorToken and RecipientToken are now each just SignatureTokens.

A second variation in this use case is that the mutually agreed upon symmetric encryption key is characterized as an “IssuedToken” with a mutually agreed upon URI used to identify the out of band (not included in the message) token, which is included in a SupportingTokens element.

The policy is as follows:

(P001)  <wsp:Policy wsu:Id="wss10_anonymous_with_cert_policy" >

(P002)    <wsp:ExactlyOne>

(P003)      <wsp:All>

(P004)        <sp:AsymmetricBinding>

(P005)          <wsp:Policy>

(P006)            <sp:InitiatorSignatureToken>

(P007)              <wsp:Policy>

(P008)                <sp:X509Token sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">

(P009)                  <wsp:Policy>

(P010)                    <sp:WssX509V3Token10/>

(P011)                  </wsp:Policy>

(P012)                </sp:X509Token>

(P013)              </wsp:Policy>

(P014)            </sp:InitiatorSignatureToken>

(P015)            <sp:RecipientSignatureToken>

(P016)              <wsp:Policy>

(P017)                <sp:X509Token sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never">

(P018)                  <wsp:Policy>

(P019)                    <sp:WssX509V3Token10/>

(P020)                  </wsp:Policy>

(P021)                </sp:X509Token>

(P022)              </wsp:Policy>

(P023)            </sp:RecipientSignatureToken>

(P024)            <sp:AlgorithmSuite>

(P025)              <wsp:Policy>

(P026)                <sp:Basic256/>

(P027)              </wsp:Policy>

(P028)            </sp:AlgorithmSuite>

(P029)            <sp:Layout>

(P030)              <wsp:Policy>

(P031)                <sp:Strict/>

(P032)              </wsp:Policy>

(P033)            </sp:Layout>

(P034)            <sp:IncludeTimestamp/>

(P035)            <sp:ProtectTokens />

(P036)            <sp:OnlySignEntireHeadersAndBody/>

(P037)          </wsp:Policy>

(P038)        </sp:AsymmetricBinding>

(P039)        <sp:SupportingTokens>

(P040)          <wsp:Policy>

(P041)            <sp:IssuedToken>

(P042)              <sp:Issuer>SomeMutuallyAgreedURI</sp:Issuer>

(P043)              <sp:RequireExternalReference/>

(P044)            </sp:IssuedToken>

(P045)            <sp:EncryptedParts>

(P046)               <sp:Body/>

(P047)            </sp:EncryptedParts>

(P048)          </wsp:Policy>

(P049)        </sp:SupportingTokens>

(P050)        <sp:Wss10>

(P051)          <wsp:Policy>

(P052)            <sp:MustSupportRefKeyIdentifier/>

(P053)          </wsp:Policy>

(P054)        </sp:Wss10>

(P055)      </wsp:All>

(P056)    </wsp:ExactlyOne>

(P057)  </wsp:Policy>

(P058)  <wsp:Policy wsu:Id="WSS10Anonymous with Certificates_input_policy">

(P059)    <wsp:ExactlyOne>

(P060)      <wsp:All>

(P061)        <sp:SignedParts>

(P062)          <sp:Body/>

(P063)        </sp:SignedParts>

(P064)        <sp:EncryptedParts>

(P065)          <sp:Body/>

(P066)        </sp:EncryptedParts>

(P067)      </wsp:All>

(P068)    </wsp:ExactlyOne>

(P069)  </wsp:Policy>

(P070)  <wsp:Policy wsu:Id="WSS10anonymous with certs_output_policy">

(P071)    <wsp:ExactlyOne>

(P072)      <wsp:All>

(P073)        <sp:SignedParts>

(P074)          <sp:Body/>

(P075)        </sp:SignedParts>

(P076)        <sp:EncryptedParts>

(P077)          <sp:Body/>

(P078)        </sp:EncryptedParts>

(P079)      </wsp:All>

(P080)    </wsp:ExactlyOne>

(P081)  </wsp:Policy>

Lines (P004) – (P038) contain the AsymmetricBindingAssertion which indicates that the initiator’s token must be used for the message signature and the recipient’s token must be used for message encryption.

Lines (P006) – (P014) contain the InitiatorSignatureToken assertion. Within that assertion lines (P008) – (P012) indicate that the initiator token must be an X.509 token that must be included with all messages sent to the recipient. Line (P010) dictates the X.509 token must be an X.509v3 security token as described in the WS-Security 1.0 X.509 Token Profile. By specifying that this is an InitiatorSignatureToken, it will only be used to sign the message and not used for encryption.

Lines (P015) – (P023) contain the RecipientSignatureToken assertion. Within that assertion lines (P017) – (P021) dictate the recipient token must also be an X.509 token as described in the WS-Security 1.0 X.509 Token Profile, however as stated on line (P017) it must not be included in any message. Instead, according to the MustSupportKeyRefIdentitier assertion on line (P040) a KeyIdentifier must be used to identify the token in any messages where the token is used. By specifying that this is an RecipientSignatureToken, it will only be used to sign the response and not used for encryption.

Line (P034) requires the inclusion of a timestamp.

Line (P035) requires token protection (ProtectTokens) which dictates that the signature must cover the token or token reference associated with the generation of that signature.

Lines (P039) – (P049) contain a SupportingTokens assertion that contains an IssuedToken (P041) – (P044), which contains an Issuer element (P042) that identifies an explicit URI (“SomeMutuallyAgreedURI”) that must be used to indicate what token will be used. (Since the content of the IssuedToken element is specific to the Issuer, any mechanism can be used to identify the key, and in this case the simplest method of identifying the issuer with the explicit key has been chosen only to illustrate one possible method, but not to recommend as opposed to any other method.) Line (P043), RequireExternalReference indicates that the IssuedToken requires a token that is referenced external to the message. Lines (P045) – (P047) indicate that the token is to be used for encrypting parts of the message, explicitly, line (P046), the Body of the message.

Lines (P058) – (P069) contain a policy that is attached to the input message. Lines (P061) – (P063) require that the body of the input message must be signed. Lines (P064) – (P066) require the body of the input message must be encrypted.

Lines (P070) – (P081) contain a policy that is attached to the output message. Lines (P073) – (P075) require that the body of the output message must be signed. Lines (P076) – (P078) require the body of the output message must be encrypted.

 

The following example message is derived from the WSS Interop2 document.

 

(M001)     <?xml version="1.0" encoding="utf-8" ?>

(M002)     <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"

(M003)       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

(M004)       xmlns:xsd="http://www.w3.org/2001/XMLSchema">

(M005)      <soap:Header> 

(M006)       <wsse:Security soap:mustUnderstand="1"

(M007)         xmlns:wsse="http://schemas.xmlsoap.org/ws/2003/06/secext">

(M008)        <xenc:ReferenceList xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">

(M009)          <xenc:DataReference URI="#enc" />

(M010)        </xenc:ReferenceList>

(M011)        <wsu:Timestamp xmlns:wsu="http://schemas.xmlsoap.org/ws/2003/06/utility"

(M012)           wsu:Id="timestamp">

(M013)         <wsu:Created>2003-03-18T19:53:13Z</wsu:Created>

(M014)        </wsu:Timestamp>

(M015)        <wsse:BinarySecurityToken ValueType="wsse:X509v3"

(M016)          EncodingType="wsse:Base64Binary"

(M017)          xmlns:wsu="http://schemas.xmlsoap.org/ws/2003/06/utility"

(M018)          wsu:Id="myCert">MII...hk</wsse:BinarySecurityToken>

(M019)        <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">

(M020)         <SignedInfo>

(M021)          <CanonicalizationMethod

(M022)            Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />

(M023)          <SignatureMethod

(M024)            Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>

(M025)          <Reference URI="#body">

(M026)           <Transforms>

(M027)            <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

(M028)           </Transforms>

(M029)           <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>

(M030)           <DigestValue>QTV...dw=</DigestValue>

(M031)          </Reference>

(M032)          <Reference URI="#myCert">

(M033)           <Transforms>

(M034)            <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

(M035)           </Transforms>

(M036)           <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>

(M037)           <DigestValue>XYZ...ab=</DigestValue>

(M038)          </Reference>

(M039)          <Reference URI="#timestamp">

(M040)           <Transforms>

(M041)            <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

(M042)           </Transforms>

(M043)           <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>

(M044)           <DigestValue>XYZ...ab=</DigestValue>

(M045)          </Reference>

(M046)         </SignedInfo>

(M047)         <SignatureValue>H+x0...gUw=</SignatureValue>

(M048)         <KeyInfo>

(M049)          <wsse:SecurityTokenReference>

(M050)           <wsse:Reference URI="#myCert" />

(M051)          </wsse:SecurityTokenReference>

(M052)         </KeyInfo>

(M053)        </Signature>

(M054)       </wsse:Security>

(M055)      </soap:Header>

(M056)      <soap:Body wsu:Id="body"

(M057)        xmlns:wsu="http://schemas.xmlsoap.org/ws/2003/06/utility">

(M058)       <xenc:EncryptedData Id="enc"

(M059)         Type="http://www.w3.org/2001/04/xmlenc#Content"

(M060)         xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">

(M061)        <xenc:EncryptionMethod

(M062)          Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />

(M063)        <xenc:KeyInfo>

(M064)         <xenc:KeyName>SomeMutuallyAgreedURI</xenc:Keyname>

(M065)        </xenc:KeyInfo>

(M066)        <xenc:CipherData>

(M067)         <xenc:CipherValue>AYb...Y8=</xenc:CipherValue>

(M068)        </xenc:CipherData>

(M069)       </xenc:EncryptedData>

(M070)      </soap:Body>

(M071)     </soap:Envelope>

In the above example, the main point of attention is line (M064), where the KeyName of the EncryptedData element is “SomeMutuallyAgreedURI”. As indicated above the specific techniques used to identify and apply this token are totally within agreed upon methods define by the mutual parties.

Lines (M005) – (M055) contain the SOAP Header element, which contains the WS-Security header (M006) – (M054).

The ReferenceList (M008) – (M010) contains an internal reference (M009), “enc”, identifying the EncryptedData element Id, line (M058). This EncryptedData (M058) – (M069) inside the SOAP Body, (M056) – (M070), was required to be encrypted by the policy (P058) – (P069) as described above.

The Timestamp (M011) – (M014) is required by the policy line (P034).

The BinarySecurityToken (M015) – (M018) contains the actual certificate used to sign the request as required by the policy, (P008), IncludeToken/AlwaysToRecipient.

The Signature (M019) – (M053) contains a SignedInfo (M020) – (M046) that identifies the “#body” (M025) the “#myCert” (M032), and the “#timestamp” (M039) as the elements covered by the signature. The Reference (M032) – (M038) with URI=”#myCert” that covers the BinarySecurityToken (M015) – (M018) was required by ProtectTokens in the policy (P035).

The KeyInfo (M048) – (M052) uses a SecurityTokenReference to point to the “myCert” BinarySecurityToken.

The EncryptedData (M058) – (M069) was described above, where it was pointed out that line (M064) contains the external reference (“SomeMutuallyAgreedURI”) to the mutually shared symmetric key used for encryption.

2.2.3  (WSS1.1) Anonymous with X.509 Certificate, Sign, Encrypt

This scenario is based on the the “Examples of Secure Web Service Message Exchange Document”  [WS‑SECURE-INTEROP] (see also sec 2.1.4)

In this use case the Request is signed using DerivedKeyToken1(K), then encrypted using a DerivedKeyToken2(K) where K is ephemeral key protected for the server's certificate. Response is signed using DKT3(K), (if needed) encrypted using DKT4(K). The requestor does not wish to identify himself; the message exchange is protected using derived symmetric keys. As a simpler, but less secure, alternative, ephemeral key K (instead of derived keys) could be used for message protection by simply omitting the sp:RequireDerivedKeys assertion.

The policy is as follows:

(P001)  <wsp:Policy wsu:Id="WSS11_AnonymousForX509SignEncrypt_Policy">

(P002)    <wsp:ExactlyOne>

(P003)      <wsp:All>

(P004)        <sp:SymmetricBinding>

(P005)          <wsp:Policy>

(P006)            <sp:ProtectionToken>

(P007)              <wsp:Policy>

(P008)                <sp:X509Token sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never">

(P009)                  <wsp:Policy>

(P010)                    <sp:RequireDerivedKeys/>

(P011)                    <sp:RequireThumbprintReference/>

(P012)                    <sp:WssX509V3Token11/>

(P013)                  </wsp:Policy>

(P014)                </sp:X509Token>

(P015)              </wsp:Policy>

(P016)            </sp:ProtectionToken>

(P017)            <sp:AlgorithmSuite>

(P018)              <wsp:Policy>

(P019)                <sp:Basic256/>

(P020)              </wsp:Policy>

(P021)            </sp:AlgorithmSuite>

(P022)            <sp:Layout>

(P023)              <wsp:Policy>

(P024)                <sp:Strict/>

(P025)              </wsp:Policy>

(P026)            </sp:Layout>

(P027)            <sp:IncludeTimestamp/>

(P028)            <sp:OnlySignEntireHeadersAndBody/>

(P029)          </wsp:Policy>

(P030)        </sp:SymmetricBinding>

(P031)        <sp:Wss11>

(P032)          <wsp:Policy>

(P033)            <sp:MustSupportRefKeyIdentifier/>

(P034)            <sp:MustSupportRefIssuerSerial/>

(P035)            <sp:MustSupportRefThumbprint/>

(P036)            <sp:MustSupportRefEncryptedKey/>

(P037)            <sp:RequireSignatureConfirmation/>

(P038)          </wsp:Policy>

(P039)        </sp:Wss11>

(P040)      </wsp:All>

(P041)    </wsp:ExactlyOne>

(P042)  </wsp:Policy>

(P043)  <wsp:Policy wsu:Id=" WSS11_AnonymousForX509SignEncrypt_input_policy">

(P044)    <wsp:ExactlyOne>

(P045)      <wsp:All>

(P046)        <sp:SignedParts>

(P047)          <sp:Body/>

(P048)        </sp:SignedParts>

(P049)        <sp:EncryptedParts>

(P050)          <sp:Body/>

(P051)        </sp:EncryptedParts>

(P052)      </wsp:All>

(P053)    </wsp:ExactlyOne>

(P054)  </wsp:Policy>

 

(P055)  <wsp:Policy wsu:Id=" WSS11_AnonymousForX509SignEncrypt_output_policy">

(P056)    <wsp:ExactlyOne>

(P057)      <wsp:All>

(P058)        <sp:SignedParts>

(P059)          <sp:Body/>

(P060)        </sp:SignedParts>

(P061)        <sp:EncryptedParts>

(P062)          <sp:Body/>