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].
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:
- The
entity requesting the transaction (for example, if the transaction
is about an application for a home mortgage loan, then the entity
requesting the transaction is the prospective homeowner who will be liable
to make the payments on the loan if it is approved).
- The
entity approving the transaction to be requested. This entity is
generally known as an “identity provider”, or an “authority”, and the
purpose of this approving entity is to guarantee to a recipient entity
that the requesting entity is making a legitimate request (continuing the
above example, the authorizing entity in this case would be the
organization that helps the prospective homeowner properly fill out the
application, possibly a loan officer at the bank, saying that the loan
application is approved for further processing).
- The
entity initiating the actual electonic transaction message (in the
above example, this entity is simply the technical software used to
securely transmit the mortgage application request to a recipient
entity that will handle the processing of the mortgage application).
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.
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.)
- Requestor:
the person or entity requesting the service and who will be supplying
credentials issued by the IssuingAuthority and will be validated by a
ValidatingAuthority. The Requestor is the logical entity that supplies the
credentials that ultimately get passed to the Recipient that will be
trusted by the RelyingParty if they are validated by the
ValidatingAuthority. (Note: the logistics of supplying the trusted
credential is distinct from the logistics of packaging up the credentials
within a WS-Security header in a SOAP message and transmitting that
message to the Recipient. The latter logistics are covered by the
Initiator, described below. The Requestor and Initiator may be combined into
a single physical entity and this is a common occurrence, however they do
not have to be and it is also a common occurrence that they are separate
physical entities. The latter case is typified by the Requestor being a
user at a browser that may be promped for credentials by the Initiator on
a server using HTTP to challenge the Requestor for a username and
password.)
- IssuingAuthority:
a Security Token Service (STS), which is an organization or entity that
typically issues authentication credentials for Requestors. Examples
include X509 Certificate Authority, Saml Token Authority, Kerberos Token
Authority. (For user passwords, the IssuingAuthority may be thought of as
the entity the user contacts for password services, such as changing
password, setting reminder phrases, etc.)
- Initiator:
the system or entity that sends the message(s) to the Recipient requesting
use of the service on behalf of the Requestor. Typically, the Initiator
will first contact the Recipient on behalf of the Requestor and obtain the
WS-SP policy and determine what tokens from what kind of IssuingAuthority
(X509, SAML, Kerberos, etc) that the Requestor will require to access the
service and possibly assist the Requestor to obtain those credentials. In
addition, based on the WS-SP policy, the Initiator determines how to
format the WS-Security headers of the messages being sent and how to use
the security binding required by the policy.
- Recipient:
the system or entity or organization that provides a web service for use
and is the supplier of the WS-SP policy that is contained in each example
and is the recipient of messages sent by Initiators. The Recipient manages
all the processing of the request message. It may rely on the services of
a ValidatingAuthority to validate the credentials contained in the
message. When the Recipient has completed the WS-SP directed processing of
the message it will generally be delivered to the RelyingParty which
continues processing of the message based on the assurances that the
Recipient has established by verifying the message is in compliance with
the WS-SP policies that are attached to the service description.
- ValidatingAuthority:
the organization or entity that typically validates Requestor credentials
for Relying Parties, and, in general, maintains those credentials in an
ongoing reliable manner. Typically, the Recipient will request the
ValidatingAuthority to validate the credentials before delivering the
Request to the RelyingParty for further processing.
- RelyingParty:
the organization or entity that relies on the security tokens contained in
the messages sent by the Initiator as a basis for providing the service.
For this document, the RelyingParty may simply be considered to be the
entity that continues processing the message after the Recipient has
completed all the processing required by the WS-SP policies attached to
the service description.
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".
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.
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
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/
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)
2.1 UsernameToken
UsernameToken authentication scenarios that use simple
username password token for authentication. There are several sub-cases.
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.
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.
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.
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).
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>
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.
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.
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].
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.
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.
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.
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.
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/>
(P063) </sp:EncryptedParts>
(P064)
