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] http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf
[WSS11-SOAPMSG] http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf
[WSS10-USERNAME] http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0.pdf
[WSS11-USERNAME] http://www.oasis-open.org/committees/download.php/16782/wss-v1.1-spec-os-UsernameTokenProfile.pdf
[WSS10-X509-PROFILE] http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0.pdf
[WSS11-X509-PROFILE] http://www.oasis-open.org/committees/download.php/16785/wss-v1.1-spec-os-x509TokenProfile.pdf
[WSS10-SAML11-PROFILE] http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0.pdf
[WSS11-SAML1120-PROFILE] http://www.oasis-open.org/committees/download.php/16768/wss-v1.1-218-spec-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] http://www.oasis‑open.org/committees/tc_home.php?wg_abbrev=wss
[WS-SECURITYPOLICY] http://www.oasis-open.org/specs/index.php#wssecpolv1.2
[WS-SECURECONVERSATION] http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/ws-secureconversation-1.3-os.pdf
[WS-TRUST]
http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.pdf
[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] http://www.oasis-open.org/committees/download.php/3406/oasis-sstc-saml-core-1.1.pdf
[SAML20-CORE] 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: http://www.oasis-open.org/committees/download.php/11374/wss-interop1-draft-06-merged-changes.pdf
WSS10-INTEROP-02: http://www.oasis-open.org/committees/download.php/11375/wss-interop2-draft-06-merged.doc
WSS11-INTEROP-01:
http://www.oasis-open.org/committees/download.php/12997/wss-11-interop-draft-01.doc
WSS10-KERBEROS-INTEROP:
http://www.oasis-open.org/committees/download.php/10991/wss-kerberos-interop.doc
WSS10-SAML11-INTEROP: http://www.oasis-open.org/committees/download.php/7702/wss-saml-interop1-draft-12.doc
WSS11-SAML1120-INTEROP: http://www.oasis-open.org/committees/download.php/16556/wss-saml2-interop-draft-v4.doc
WSSX-PRE-INTEROP: http://www.oasis-open.org/committees/download.php/16357/Trust_SecureConversation_Interop.2004-10.doc
WSSX-WSTR-WSSC-INTEROP: http://www.oasis-open.org/committees/download.php/20954/ws-sx-interop-ed-10.doc
WS-SECURE-INTEROP: http://www.oasis-open.org/committees/document.php?document_id=28803&wg_abbrev=ws-sx
WSI-SCM-SAMPLEAPPL: http://www.ws-i.org/SampleApplications/SupplyChainManagement/2006-04/SCMSecurityArchitectureWGD5.00.doc
(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)
</wsp:All>
(P065)
</wsp:ExactlyOne>
(P066)
</wsp:Policy>
Lines (P004) – (P030) contain the SymmetricBinding assertion
which indicates that the derived key token must be used for both message
signature and message encryption.
Lines (P007) – (P016) contain the ProtectionToken assertion.
Within that assertion lines (P008) – (P014) indicate that the ProtectionToken
must be an X.509 token that MUST NOT be included with any message sent between
the Initiator and Recipient.
Line (P010) dictates the derived key is required. Line
(P012) dictates the X.509 token must be an X.509v3 security token as described
in the WS-Security 1.1 X.509 Token Profile. According to the MustSupportRefThumbprint assertion on line
(P035) and RequireThumbprintReference on
line (P011), a Thumbprint Reference of KeyIdentifier
must be used to identify the token in any messages where the token is used.
Line (P027) requires the inclusion of a timestamp.
Lines (P031) – (P039) contain some WS-Security 1.1 related
interoperability requirements, specifically support for key identifier, issuer
serial number, thumbprint, encrypted key references, and requires signature
confirmation on the response.
Lines (P043) – (P054) contain a policy that is attached to
the input message. Lines (P045) – (P048) require that the body of the input
message must be signed. Lines (P049) – (P051) require the body of the input
message must be encrypted.
Lines (P055) – (P066) contain a policy that is attached to
the output message. Lines (P057) – (P060) require that the body of the output
message must be signed. Lines (P061) – (P063) 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.
Note: this message uses WS-SecureConversation as a means to
meet the requirements of the policy, however, aside from using the
wsc:DerivedKeyToken elements to meet the policy requirements for the
RequireDerivedKeys assertion (P010) the general protocol mechanisms described
in WS-SecureConversation for SecurityContextTokens are not explicitly
demonstrated.
(M001) <?xml version="1.0"
encoding="utf-8" ?>
(M002) <env:Envelope
xmlns:env="..." xmlns:xenc="http..." xmlns:ds="..." xmlns:wsu="...">
(M003) <env:Header>
(M004) <wsse:Security
xmlns:wsse="..."
xmlns:wsse11="..."
xmlns:wsc="..."
env:mustUnderstand="1">
(M005) <xenc:EncryptedKey
Id="encKey" >
(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="...#ThumbprintSHA1">c2...=</wsse:KeyIdentifier>
(M012) </wsse:SecurityTokenReference>
(M013) </ds:KeyInfo>
(M014) <xenc:CipherData>
(M015) <xenc:CipherValue>TE...=</xenc:CipherValue>
(M016) </xenc:CipherData>
(M017) </xenc:EncryptedKey>
(M018) <wsc:DerivedKeyToken
Algorithm=".../p_sha1"
wsu:Id="DKey1">
(M019) wsse:SecurityTokenReference
wsse11:TokenType="...#EncryptedKey">
(M020) <wsse:Reference
ValueType="...#EncryptedKey"
URI="#encKey"/>
(M021) </wsse:SecurityTokenReference>
(M022) <wsc:Generation>0</wsc:Generation>
(M023) <wsc:Length>32</wsc:Length>
(M024) <wsc:Label>WS-SecureConversationWS-SecureConversation</wsc:Label>
(M025) <wsc:Nonce>39...=</wsc:Nonce>
(M026) </wsc:DerivedKeyToken>
(M027) <xenc:ReferenceList>
(M028) <xenc:DataReference
URI="#encBody"/>
(M029) </xenc:ReferenceList>
(M030) <wsc:DerivedKeyToken
Algorithm=".../p_sha1"
wsu:Id="DKey2">
(M031) <wsse:SecurityTokenReference
wsse11:TokenType="...#EncryptedKey">
(M032) <wsse:Reference
ValueType="...#EncryptedKey"
URI="#encKey"/>
(M033) </wsse:SecurityTokenReference>
(M034) <wsc:Generation>0</wsc:Generation>
(M035) <wsc:Length>32</wsc:Length>
(M036) <wsc:Label>WS-SecureConversationWS-SecureConversation</wsc:Label>
(M037) <wsc:Nonce>...=</wsc:Nonce>
(M038) </wsc:DerivedKeyToken>
(M039) <wsu:Timestamp
wsu:Id="Timestamp" >
(M040) <wsu:Created>2007-03-26T23:43:13Z</wsu:Created>
(M041) </wsu:Timestamp>
(M042) <ds:Signature >
(M043) <ds:SignedInfo>
(M044) ...
(M045) <ds:Reference
URI="#Timestamp">...</ds:Reference>
(M046) <ds:Reference
URI="#Body">...</ds:Reference>
(M047) </ds:SignedInfo>
(M048) <ds:SignatureValue>Yu...=</ds:SignatureValue>
(M049) <ds:KeyInfo>
(M050) <wsse:SecurityTokenReference
>
(M051) <wsse:Reference
URI="#DKey2" ValueType=".../dk"/>
(M052) </wsse:SecurityTokenReference>
(M053) </ds:KeyInfo>
(M054) </ds:Signature>
(M055) </wsse:Security>
(M056) </env:Header>
(M057) <env:Body
wsu:Id="Body" >
(M058) <xenc:EncryptedData Id="encBody"
Type="...#Content"
MimeType="text/xml" Encoding="UTF-8" >
(M059) <xenc:EncryptionMethod
Algorithm="...#aes256-cbc"/>
(M060) <ds:KeyInfo >
(M061) <wsse:SecurityTokenReference
>
(M062) <wsse:Reference
URI="#DKey1" ValueType=".../dk"/>
(M063) </wsse:SecurityTokenReference>
(M064) </ds:KeyInfo>
(M065) <xenc:CipherData>
(M066) <xenc:CipherValue>p53...f</xenc:CipherValue>
(M067) </xenc:CipherData>
(M068) </xenc:EncryptedData>
(M069) </env:Body>
(M070)
</env:Envelope>
Lines (M005) – (M017) is the EncryptedKey information which
will be reference using the WSS1.1 #EncryptedKey SecurityTokenReference
function. Lines (M010) – (M012) is the security token reference. Because the ProtectionToken disallowed the token from being
inserted into the message, a KeyIdentifier is used instead of a reference to an
included token. In addition, Line (M011) the KeyIdentifier has the value type
of #ThumbprintSHA1 for Thumbprint Reference, it is required by the policy line
(P011) of the Thumbprint Reference.
Lines (M018) – (M022) is the first wsc:DerivedKeyToken. It
is derived from the EncryptedKey of lines (M005) – (M017), which is referenced
using the WSS1.1 #EncryptedKey SecurityTokenReference mechanism contained in
lines (M019) – (M021), and used for body encryption and it is referenced on
line (M062).
Lines (M027) – (M029) is an encryption data reference that
references the encrypted body of the message on lines (M058) – (M068). The
encryption was required by the EncryptedParts assertion of the input message
policy.
Lines (M030) – (M038) is the second wsc:DerivedKeyToken. It
is derived from the EncryptedKey of lines (M005) – (M017) and used for
signature referenced on line (M051).
Lines (M039) – (M041) contain a timestamp for the message as
required by the IncludeTimestamp assertion.
Lines (M042) – (M054) contain the message signature.
Line (M045) indicates the message timestamp is included in
the signature as required by the IncludeTimestamp assertion definition.
Line (M046) indicates the message body is included in the
signature as required by the SignedParts assertion of the input message policy.
This scenario is based on the the “Examples of Secure Web
Service Message Exchange Document” [WS‑SECURE-INTEROP]
(see also sec 2.1.4)
Client and server X509 certificates are used for client and
server authorization respectively. Request is signed using K, then encrypted
using K, K is ephemeral key protected for server's certificate. Signature corresponding
to K is signed using client certificate. Response is signed using K, encrypted
using K, encrypted key K is not included in response. Alternatively, derived
keys can be used for each of the encryption and signature operations by simply
adding an 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:EndorsingSupportingTokens>
(P032)
<wsp:Policy>
(P033)
<sp:X509Token
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
(P034)
<wsp:Policy>
(P035)
<sp:RequireThumbprintReference/>
(P036)
<sp:WssX509V3Token11/>
(P037)
</wsp:Policy>
(P038)
</sp:X509Token>
(P039)
</wsp:Policy>
(P040)
</sp:EndorsingSupportingTokens>
(P041)
<sp:Wss11>
(P042)
<wsp:Policy>
(P043)
<sp:MustSupportRefKeyIdentifier/>
(P044)
<sp:MustSupportRefIssuerSerial/>
(P045)
<sp:MustSupportRefThumbprint/>
(P046)
<sp:MustSupportRefEncryptedKey/>
(P047)
<sp:RequireSignatureConfirmation/>
(P048)
</wsp:Policy>
(P049)
</sp:Wss11>
(P050)
</wsp:All>
(P051)
</wsp:ExactlyOne>
(P052)
</wsp:Policy>
(P053)
<wsp:Policy wsu:Id="
WSS11_X509DKSignEncrypt_input_policy">
(P054)
<wsp:ExactlyOne>
(P055)
<wsp:All>
(P056)
<sp:SignedParts>
(P057)
<sp:Body/>
(P058)
</sp:SignedParts>
(P059)
<sp:EncryptedParts>
(P060)
<sp:Body/>
(P061)
</sp:EncryptedParts>
(P062)
</wsp:All>
(P063)
</wsp:ExactlyOne>
(P064)
</wsp:Policy>
(P065)
<wsp:Policy wsu:Id="
WSS11_X509DKSignEncrypt_output_policy">
(P066)
<wsp:ExactlyOne>
(P067)
<wsp:All>
(P068)
<sp:SignedParts>
(P069)
<sp:Body/>
(P070)
</sp:SignedParts>
(P071)
<sp:EncryptedParts>
(P072)
<sp:Body/>
(P073)
</sp:EncryptedParts>
(P074)
</wsp:All>
(P075)
</wsp:ExactlyOne>
(P076)
</wsp:Policy>
Lines (P004) – (P030) contain the SymmetricBinding assertion
which indicates that the derived key token must be used for both message
signature and message encryption.
Lines (P007) – (P016) contain the ProtectionToken assertion.
Within that assertion lines (P008) – (P014) indicate that the initiator token
must be an X.509 token that must not be included with all messages sent between
the recipient and Recipient.
Line (P010) dictates the derived key is required. Line
(P012) dictates the X.509 token must be an X.509v3 security token as described
in the WS-Security 1.1 X.509 Token Profile. According to the MustSupportRefThumbprint assertion on line
(P043) and RequireThumbprintReference on line
(P011), a Thumbprint Reference of KeyIdentifier
must be used to identify the token in any messages where the token is used.
Line (P027) requires the inclusion of a timestamp.
Lines (P031) – (P040) contain the EndorsingSupportingTokens assertion which indicates that the message
signature should be endorsed by client’s X509 certificate on line (P033) –
(P038). Line (P033) IncludeToken=".../AlwaysToRecipient" indicates
the endorsing is only required when the message is sent to recipient. Line
(P036) dictates the X.509 token must be an X.509v3 security token as described
in the WS-Security 1.1 X.509 Token Profile. and RequireThumbprintReference
on line (P035), a Thumbprint Reference of KeyIdentifier
must be used to identify the token in any messages where the token is used.
Lines (P041) – (P049) contain some WS-Security 1.1 related
interoperability requirements, specifically support for key identifier, issuer
serial number, thumbprint, encrypted key references, and requires signature
confirmation on the response.
Lines (P053) – (P064) contain a policy that is attached to
the input message. Lines (P055) – (P058) require that the body of the input
message must be signed. Lines (P059) – (P061) require the body of the input
message must be encrypted.
Lines (P065) – (P076) contain a policy that is attached to
the output message. Lines (P067) – (P070) require that the body of the output
message must be signed. Lines (P071) – (P073) 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.
Note: this message uses WS-SecureConversation as a means to
meet the requirements of the policy, however, aside from using the
wsc:DerivedKeyToken elements to meet the policy requirements for the RequireDerivedKeys
assertion (P010) the general protocol mechanisms described in
WS-SecureConversation for SecurityContextTokens are not explicitly
demonstrated.
(M001) <?xml version="1.0"
encoding="utf-8" ?>
(M002) <env:Envelope
xmlns:env="..." xmlns:xenc="http..." xmlns:ds="..." xmlns:wsu="...">
(M003) <env:Header>
(M004) <wsse:Security
xmlns:wsse="..."
xmlns:wsse11="..."
env:mustUnderstand="1">
(M005) <xenc:EncryptedKey
Id="encKey" >
(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="...#ThumbprintSHA1">c2...=</wsse:KeyIdentifier>
(M013) </wsse:SecurityTokenReference>
(M014) </ds:KeyInfo>
(M015) <xenc:CipherData>
(M016) <xenc:CipherValue>eI...=</xenc:CipherValue>
(M017) </xenc:CipherData>
(M018) </xenc:EncryptedKey>
(M019) <wsse:BinarySecurityToken
ValueType="...#X509v3" EncodingType="...#Base64Binary">MI...=</wsse:BinarySecurityToken>
(M020) <wsc:DerivedKeyToken
xmlns:wsc=".../sc"
Algorithm=".../p_sha1"
wsu:Id="derivedKeyToken1">
(M021) <wsse:SecurityTokenReference
wsse11:TokenType="...#EncryptedKey"
>
(M022) <wsse:Reference
ValueType="...#EncryptedKey"
URI="#encKey"/>
(M023) </wsse:SecurityTokenReference>
(M024) <wsc:Generation>0</wsc:Generation>
(M025) <wsc:Length>32</wsc:Length>
(M026) <wsc:Label>WS-SecureConversationWS-SecureConversation</wsc:Label>
(M027) <wsc:Nonce>+R...=</wsc:Nonce>
(M028) </wsc:DerivedKeyToken>
(M029) <wsu:Timestamp
wsu:Id="Timestamp" >
(M030) <wsu:Created>2007-03-31T04:27:21Z</wsu:Created>
(M031) </wsu:Timestamp>
(M032) <n1:ReferenceList
xmlns:n1=".../xmlenc#">
(M033) <n1:DataReference URI="#encBody"/>
(M034) </n1:ReferenceList>
(M035) <wsc:DerivedKeyToken
xmlns:wsc=".../sc" Algorithm=".../p_sha1" wsu:Id="derivedKeyToken2">
(M036) <wsse:SecurityTokenReference
wsse11:TokenType="...#EncryptedKey"
>
(M037) <wsse:Reference
ValueType="...EncryptedKey"
URI="#encKey"/>
(M038) </wsse:SecurityTokenReference>
(M039) <wsc:Generation>0</wsc:Generation>
(M040) <wsc:Length>32</wsc:Length>
(M041) <wsc:Label>WS-SecureConversationWS-SecureConversation</wsc:Label>
(M042) <wsc:Nonce>wL...=</wsc:Nonce>
(M043) </wsc:DerivedKeyToken>
(M044) <ds:Signature
Id="messageSignature">
(M045) <ds:SignedInfo>
(M046) ...
(M047) <ds:Reference URI="#Timestamp">
(M048) ...
(M049) </ds:Reference>
(M050) <ds:Reference
URI="#Body">
(M051) ...
(M052) </ds:Reference>
(M053) </ds:SignedInfo>
(M054) <ds:SignatureValue>abcdefg=</ds:SignatureValue>
(M055) <ds:KeyInfo>
(M056) <wsse:SecurityTokenReference
>
(M057) <wsse:Reference
URI="#derivedKeyToken2" ValueType=".../dk"/>
(M058) </wsse:SecurityTokenReference>
(M059) </ds:KeyInfo>
(M060) </ds:Signature>
(M061) <ds:Signature
>
(M062) <ds:SignedInfo>
(M063) ...
(M064) <ds:Reference
URI="#messageSignature">
(M065) ...
(M066) </ds:Reference>
(M067) </ds:SignedInfo>
(M068) <ds:SignatureValue>hijklmnop=</ds:SignatureValue>
(M069) <ds:KeyInfo>
(M070) <wsse:SecurityTokenReference
>
(M071) <wsse:KeyIdentifier
EncodingType="...#Base64Binary"
ValueType="...#ThumbprintSHA1">Pj...=</wsse:KeyIdentifier>
(M072) </wsse:SecurityTokenReference>
(M073) </ds:KeyInfo>
(M074) </ds:Signature>
(M075) </wsse:Security>
(M076) </env:Header>
(M077) <env:Body
wsu:Id="Body" >
(M078) <xenc:EncryptedData
Id="encBody" Type="...#Content"
MimeType="text/xml" Encoding="UTF-8" >
(M079) <xenc:EncryptionMethod
Algorithm="http...#aes256-cbc"/>
(M080) <ds:KeyInfo
>
(M081) <wsse:SecurityTokenReference
>
(M082) <wsse:Reference
URI="#derivedKeyToken1" ValueType=".../dk"/>
(M083) </wsse:SecurityTokenReference>
(M084) </ds:KeyInfo>
(M085) <xenc:CipherData>
(M086) <xenc:CipherValue>70...=</xenc:CipherValue>
(M087) </xenc:CipherData>
(M088) </xenc:EncryptedData>
(M089) </env:Body>
(M090) </env:Envelope>
(M091)
Lines (M005) – (M017) is the EncryptedKey information which
will be reference using the WSS1.1 #EncryptedKey SecurityTokenReference
function. Lines (M010) – (M012) is the security token reference. Lines (M010) –
(M012) is the security token reference. Because the ProtectionToken disallowed the token from being inserted into the
message, a KeyIdentifier is used instead of a reference to an included token.
In addition, Line (M011) the KeyIdentifier has the value type of
#ThumbprintSHA1 for Thumbprint Reference, and it is required by the policy line
(P011) of the Thumbprint Reference.
Line (M019) is an X509 BinarySecurityToken that contains the
actual X509 certificate that is used by the endorsing signature described
below. The token is required to be present in the message based on the line
(P033) that requires this token for the message sent to the recipient.
Lines (M020) – (M027) is the first derived key token. It is
derived from the EncryptedKey of lines (M005) – (M017) and used for body
encryption referenced on line (M081).
Lines (M028) – (M030) contain a Timestamp element for the
message as required by the IncludeTimestamp assertion.
Lines (M031) – (M033) contain an encryption data reference
that references the encrypted body of the message on lines (M077) – (M087). The
encryption was required by the EncryptedParts assertion of the input message
policy.
Lines (M034) – (M042) is the second derived key token. It is
derived from the EncryptedKey of lines (M005) – (M017) and used by the
signature that references it on line (M056).
Lines (M043) – (M059) contain the message signature. Lines
(M054) – (M058) is its KeyInfo block that indicates the second derived key
token should be used to verify the message signature.
Line (M057) indicates the message timestamp is included in
the signature as required by the IncludeTimestamp assertion definition.
Line (M060) indicates the message body is included in the
signature as required by the SignedParts assertion of the input message policy.
Lines (M060) – (M073) contain the endorsing signature. It
signs the message signature, referenced on line (M063), per EndorsingSupportingTokens assertion policy requirement
on lines (P031) – (P040). Line (M070), the KeyIdentifier, has the value
type of #ThumbprintSHA1 for Thumbprint Reference, and it is required by the
policy line (P035) of the Thumbprint Reference. This Thumbprint Reference must
match the Thumbprint of the X509 Certificate contained in the
BinarySecurityToken on line (M019), based on the IncludeToken requirement line
(P033).
An example of an output message that conforms to the above
stated policy follows:
(R001) <env:Envelope
xmlns:env="..." xmlns:wsu="...">
(R002) <env:Header>
(R003) <wsse:Security
env:mustUnderstand="1" xmlns:wsse="...">
(R004) <wsu:Timestamp
wsu:Id="Timestamp" >
(R005) <wsu:Created>2007-03-31T04:27:25Z</wsu:Created>
(R006) </wsu:Timestamp>
(R007) <wsc:DerivedKeyToken
wsu:Id="derivedKeyToken1" xmlns:wsc=".../sc">
(R008) <wsse:SecurityTokenReference>
(R009) <wsse:KeyIdentifier
ValueType="...1.1#EncryptedKeySHA1"
(R010) >nazB6DwNC9tcwFsghoSYWXLf2wk=</wsse:KeyIdentifier>
(R011) </wsse:SecurityTokenReference>
(R012) <wsc:Offset>0</wsc:Offset>
(R013) <wsc:Length>24</wsc:Length>
(R014) <wsc:Nonce>NfSNXZLYAA8mocQz19KWjg==</wsc:Nonce>
(R015) </wsc:DerivedKeyToken>
(R016) <wsc:DerivedKeyToken
wsu:Id="derivedKeyToken2" xmlns:wsc=".../sc">
(R017) <wsse:SecurityTokenReference>
(R018) <wsse:KeyIdentifier
ValueType="...1.1#EncryptedKeySHA1"
(R019) >nazB6DwNC9tcwFsghoSYWXLf2wk=</wsse:KeyIdentifier>
(R020) </wsse:SecurityTokenReference>
(R021) <wsc:Nonce>lF/CtyQ9d1Ro8E3+uZYmgQ==</wsc:Nonce>
(R022) </wsc:DerivedKeyToken>
(R023) <enc:ReferenceList
xmlns:enc=".../xmlenc#">
(R024) <enc:DataReference
URI="#encBody"/>
(R025) </enc:ReferenceList>
(R026) <wsse11:SignatureConfirmation
wsu:Id="sigconf1"
(R027) Value="abcdefg="
xmlns:wsse11="..."/>
(R028) <wsse11:SignatureConfirmation
wsu:Id="sigconf2"
(R029) Value="hijklmnop="
xmlns:wsse11="..."/>
(R030) <Signature
xmlns="http://www.w3.org/2000/09/xmldsig#">
(R031) <SignedInfo>
(R032) <CanonicalizationMethod
(R033) Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
(R034) <SignatureMethod
(R035) Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>
(R036) <Reference
URI="#msgBody">
(R037) ...
(R038) </Reference>
(R039) <Reference
URI="#Timestamp">
(R040) ...
(R041) </Reference>
(R042) <Reference
URI="#sigconf1">
(R043) ...
(R044) </Reference>
(R045) <Reference
URI="#sigconf2">
(R046) ...
(R047) </Reference>
(R048) </SignedInfo>
(R049) <SignatureValue>3rAxsfJ2LjF7liRQX2EH/0DBmzE=</SignatureValue>
(R050) <KeyInfo>
(R051) <wsse:SecurityTokenReference>
(R052) <wsse:Reference
URI="#derivedKeyToken1"/>
(R053) </wsse:SecurityTokenReference>
(R054) </KeyInfo>
(R055) </Signature>
(R056) </wsse:Security>
(R057) </env:Header>
(R058) <env:Body
wsu:Id="msgBody">
(R059) <enc:EncryptedData
Id="encBody" Type="...xmlenc#Content"
(R060) xmlns:enc=".../xmlenc#">
(R061) <enc:EncryptionMethod
Algorithm=".../xmlenc#aes256-cbc"/>
(R062) <KeyInfo
xmlns="http://www.w3.org/2000/09/xmldsig#">
(R063) <wsse:SecurityTokenReference
xmlns:wsse="...">
(R064) <wsse:Reference
URI="#derivedKeyToken2"/>
(R065) </wsse:SecurityTokenReference>
(R066) </KeyInfo>
(R067) <enc:CipherData>
(R068) <enc:CipherValue>y+eV...pu</enc:CipherValue>
(R069) </enc:CipherData>
(R070) </enc:EncryptedData>
(R071) </env:Body>
(R072) </env:Envelope>
Lines (R001)-(R072) contain the Response message returned to
the Initiator.
Lines (R004)-(R006) contain the Timestamp required by the
Policy (P027).
Lines (R007)-(R015) and (R016)-(R022) contain the
information necessary for the Initiator to derive the keys using the WS-SecureConversation
shared secret, the identified key (R010) for DK1 and (R019) for DK2, which
reference the same key, and the Nonce (R014) for DK1 and (R021) for DK2, which
are different for the two derived keys.
Lines (R023)-(R025) contain a ReferenceList that indicates
the message Body (R058) contains the data to be encrypted. The encryption was
required by the output policy (P079).
Lines (R026)-(R027) contain the SignatureConfirmation for
the SignatureValue in the request message (M054) which was required to be
included by the policy (P047) RequireSignatureConfirmation.
Lines (R028)-(R029) contain the SignatureConfirmation for
the 2nd SignatureValue in the request message (M068), which is also
required by the policy (P047).
Lines (R030)-(R055) contain the response message signature
that covers the Timestamp element (R039)->(R004) required to be signed by
the policy (P027), the two SignatureConfirmation elements (R042)->(R026) and
(R045)->(R028), which are required to be signed because they are required
elements of the policy (P047), and the message Body (R036)->(R058), which is
required to be signed by the output message policy (P076). The signature may be
verified using derivedKeyToken1 as indicated on line (R052).
Lines (R059)-(R070) contain the encrypted data as required
by the policy (P079) and may be decrypted using derivedKeyToken2 as indicated
on line (R064).
For SAML, the combination of SAML and WSS version numbers is
supported (WssSamlV11Token10, WssSamlV11Token11, WssSamlV20Token11).
Instead of explicitly including the SAML Assertion, a
wsse:KeyIdentifier reference can also be used. To enable this last behavior,
the IncludeToken attribute is set to
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never.
In all of the SAML scenarios, the SAML Assertion
ConfirmationMethod expected to be used by the Initiator is communicated
implicitly by the context of the sp: security binding in use and type of
sp: element containing the SamlToken. There are 3 general SAML
ConfirmationMethod use cases covered: holder-of-key (hk), sender-vouches (sv),
and bearer (br).
For the holder-of-key case,
there is always a contained reference (or value) in the SAML Assertion to key
material that may be used for message protection in the scenario. The hk case
can be assumed if the WssSamlV**Token** element appears either in the
sp:InitiatorToken element of the sp:AsymmetricBinding element, or in the
sp:ProtectionToken element of the sp:SymmetricBinding element. In the
sp:TransportBinding case, if the WssSamlV**Token** element appears in an
sp:EndorsingSupportingTokens or sp:SignedEndorsingSupportingTokens element, the
SAML Assertion type can also be assumed to be hk.
The sender-vouches case can
be assumed if the WssSamlV**Token** version will always appear in an
sp:SignedSupportingTokens element to indicate that the SAML Authority
associated with this token is the Initiator that signs the message.
The bearer case can be
assumed if the WssSamlV**Token** version appears in an sp:SupportingTokens
element (it may be signed as a SignedPart, but it is not involved in the
message protection).
It is recognized that other uses cases might exist, where
these guidelines might need further elaboration in order to address all contingencies,
however that is outside the scope of the current version of this document.
Note: in the discussions below the
term “SamlToken” or “SamlToken assertion” refers to the policy requirement that
a “SAML Assertion” be used as that token.
Note: SAML Assertions have issuers.
In addition, these Assertions are generally signed with an X509 certificate. In
general, the SAML IssuingAuthority may be regarded as the Subject of the X509
certificate, which is trusted by a RelyingParty. In general, as well, there is
usually a known mapping between the Issuer identified within the SAML Assertion
and the Subject of the X509 certificate used to sign that Assertion. It will be
assumed in this document that the SAML IssuingAuthority may be identified by
either of these identities and that, in general, a RelyingParty will check the
details as necessary.
The concept of the sp:”message signature” within the
context of the sp:TransportBinding is not clearly identified within the
current version of [WS-SecurityPolicy],
however, there are certain inferences that are used in the use cases that
follow that are identified here for reference.
- Based on the diagrams in section 8 of [WS-SecurityPolicy], which show messages with
a “message signature” followed by a diagram showing use of transport
security the only difference is that the message signature diagrams
contain a block labelled “Sig1”, which is the message signature, and the
transport security diagrams do not have this block.
- Considering the fact that when [SSL]
Client Certificates are used for client authentication, that the client
uses the client certificate private key to sign hash of SSL handshake
messages in an SSL CertificateVerify message that is part of the SSL
protocol, the assumption is made that subsequent data sent by the client
on this link is effectively protected for the purposes of data integrity
and confidentiality, and that the data sent on the link is authorized to
be sent by the holder of the private key associated with the client
certificate.
- Based on the considerations in the bullets above, and with
intention of maintaining functional consistency with the WS‑SecurityPolicy
notions of sp: message signature, sp:SignedSupportingTokens, and
sp:SignedEndorsingSupportingTokens, use of client certicates with SSL will
be considered equivalent to having a “virtual message signature” provided
by the Initiator’s client certificate which covers all the data in the SOAP
request that the Initiator sends on the SSL link.
- As such, in the above context, the client certificate may
be regarded as providing both a virtual Signing function for tokens and
Timestamp that appear in the wsse:Security header, as well as a virtual
Endorsing function for tokens that contain the client certificate or a
reference to the client certificate that appear in the wsse:Security
header.
The net effect of the above assumptions for the SAML use
cases in this section that use the sp:TransportBinding is that if a client
certifcate is required to be used with the sp:HttpsToken assertion
then:
1.
A SAML sender-vouches Assertion contained in a wsse:Security
header block may be considered to be an sp:SignedSupportingToken when
used in an sp:TransportBinding using an sp:HttpsToken assertion that contains
an sp:RequireClientCertificate assertion, because the client certificate is
being used as the IssuingAuthority behind the SAML sender-vouches Assertion,
which requires the IssuingAuthority to sign the combined message and Assertion.
- A SAML holder-of-key Assertion contained in a
wsse:Security header block may be considered to be an sp:SignedEndorsingSupportingToken
when used in an sp:TransportBinding using an sp:HttpsToken assertion that
contains an sp:RequireClientCerfticate assertion AND that the either the
client certificate or a reference to it is contained in the
saml:SubjectConfirmationData/ds:KeyInfo element of the SAML holder-of-key
Assertion.
- A SAML bearer Assertion contained in a
wsse:Security header block may only be considered to be an sp:SupportingToken,
because they are only “incidentally” covered by the virtual message
signature as a “pass through” token provided by the Requestor to be
evaluated by the Recipient that is being “passed through” by the
Initiator, but which the Initiator takes no responsibility.
Ultimately, the responsibilities associated with the
granting access to resources is determined by the agreements between
RelyingParties and IssuingAuthorities. Those agreements need to take into
consideration the security characteristics of the bindings which support access
requests as to what kind of bindings are required to “adequately protect” the
requests for the associated business purposes. These examples are intended to
show how SAML Assertions can be used in a variety of WS-SecurityPolicy contexts
and how the different SAML token types (hk, sv, bearer) may be used in
different configurations relating the IssuingAuthority, the Requestor, the
Initiator, the Recipient, and the RelyingParty.
Initiator adds a SAML assertion (bearer) representing the
Requestor to the SOAP security header.
Since the SamlToken is listed in the SupportingTokens
element, it will not explicitly be covered by a message signature. The
Initiator may infer that a Saml Bearer Assertion is acceptable to meet this
requirement, because the Initiator is not required to explicitly cover a
SupportingToken with a signature.
The SAML assertion itself could be signed. The
IssuingAuthority in this scenario is the Issuer (and signer, if the Assertion
is signed) of the SAML Assertion. The Initiator simply passes the token through
and is not actively involved in the trust relationship between the
IssuingAuthority that issued the SAML Assertion and the Requestor who is the
Subject of the SAML Assertion.
This scenario might be used in a SAML Federation application
where a browser-based user with a SAML Assertion indicating that user’s SSO
(Single Sign On) credential has submitted a request to a portal using the
Assertion as a credential (either directly or indirectly via a SAML Artifact [SAML11]), and the portal as Initiator is generating a
web service request on behalf of this user, but the trust that the Recipient
has for the Requestor is based on the Assertion and its IssuingAuthority, not
the Initiator who delivered the request.
(P001) <wsp:Policy>
(P002) <sp:SupportingTokens>
(P003) <wsp:Policy>
(P004) <sp:SamlToken
sp:IncludeToken=”http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient”>
(P005) <wsp:Policy>
(P006) <sp:WssSamlV11Token10/>
(P007) </wsp:Policy>
(P008) </sp:SamlToken>
(P009) </wsp:Policy>
(P010) </sp:SupportingTokens>
(P011) </wsp:Policy>
Lines (P001)-(P011) contain the endpoint wsp:Policy, which
contains no bindings because none is required to access the service protected
by this policy, however the service does require that the Requestor provide a
Supporting Token in the sp:SupportingTokens element (P002)-(P010), which must
be an sp:SamlToken (P004)-(P008), which must be an sp:WssSamlV11Token10 (P006),
which means that the SamlToken must be a SAML 1.1 saml:Assertion that is sent
in compliance with the [WSS10‑SAML11‑PROFILE].
As explained in section 2.3 above, the fact that the
sp:SamlToken is simply in an sp:SupportingTokens element indicates to the
Initiator that a SAML bearer Assertion is what is expected to accompany the
request.
The following is a sample request taken from [WSS11-SAML1120-PROFILE] that complies with the
WSS 1.0 compatible policy above
(M001) <S12:Envelope
xmlns:S12="...">
(M002) <S12:Header>
(M003) <wsse:Security
xmlns:wsse="...">
(M004) <saml:Assertion
xmlns:saml="..."
(M005) AssertionID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc"
(M006) IssueInstant="2003-04-17T00:46:02Z"
(M007) Issuer="www.opensaml.org"
(M008) MajorVersion="1"
(M009) MinorVersion="1">
(M010) <saml:AuthenticationStatement>
(M011) <saml:Subject>
(M012) <saml:NameIdentifier
(M013) NameQualifier="www.example.com"
(M014) Format="urn:oasis:names:tc:SAML:1.1:nameidformat:X509SubjectName">
(M015) uid=joe,ou=people,ou=saml-demo,o=baltimore.com
(M016) </saml:NameIdentifier>
(M017) <saml:SubjectConfirmation>
(M018) <saml:ConfirmationMethod>
(M019) urn:oasis:names:tc:SAML:1.0:cm:bearer
(M020) </saml:ConfirmationMethod>
(M021) </saml:SubjectConfirmation>
(M022) </saml:Subject>
(M023) </saml:AuthenticationStatement>
(M024) </saml:Assertion>
(M025) </wsse:Security>
(M026) </S12:Header>
(M027) <S12:Body>
(M028) . . .
(M029) </S12:Body>
(M030) </S12:Envelope>
Lines (M001)-(M030) contains the SOAP:Envelope, which
contains the SOAP:Header (M002)-(M026) and the SOAP:Body (M027)-(M029).
The SOAP Header contains a wsse:Security header block
(M003)-(M025) which simply contains the saml:Assertion.
The saml:Assertion (M004)-(M024) is Version 1.1
(M008)-(M009), which is required by the policy sp:WssSamlV11Token10 assertion
(P006). The Assertion contains a saml:AuthenticationStatement (M010)-(M023)
that contains a saml:NameIdentifier (M012)-(M016) that identifies the
saml:Subject, who is the Requestor (who submitted the request from a browser)
and it contains a saml:SubjectConfirmation element (M017)-(M021), which
specifies the saml:ConfirmationMethod to be “bearer” (M019), which meets the
policy requirement (P006).
For general context to relate this scenario to Figure 1, the
Requestor at a browser will have obtained either the saml:Assertion above or an
Artifact identifying that Assertion from an IssuingAuthority and sent it to the
portal in the context of some request the Requestor is trying to make. The
portal recognizes that to meet the needs of this request that it must invoke a
web service that has publicized the policy above (P001)-(P011). Therefore, the
portal will now take on the role of Initiator (Fig 1) and assemble a SOAP
request (M001)-(M030) and submit it to the service as described in detail
above.
This scenario is based on first WSS SAML Profile InterOp [WSS10-SAML11-INTEROP Scenario #2 section 4.4.4]
Initiator adds a SAML Assertion (sv) to the SOAP Security
Header. Because the TransportBinding requires a Client Certificate AND the SAML
token is in a SignedSupportingTokens element, when the Initiator uses the
Client Certificate to protect the message under SSL, the Initiator may be
considered as effectively “signing” the SAML sv Assertion and acting as a SAML
Authority (i.e. the issuer of the sv Assertion). By including the sv assertion
in the header and using the Client Certificate to protect the message, the
Initiator takes responsibility for binding the Requestor, who is the Subject of
the Assertion to the contents of the message.
Note: because SSL does not retain cryptographic
protection of the message after the message is delivered, messages protected
using only this mechanism cannot be used as the basis for non‑repudiation.
(P001)
<wsp:Policy xmlns:wsp="..." xmlns:wsu="..."
xmlns:sp="..." wsu:Id="Wss10SamlSvV11Tran_policy">
(P002)
<sp:TransportBinding>
(P003)
<wsp:Policy>
(P004)
<sp:TransportToken>
(P005)
<wsp:Policy>
(P006)
<sp:HttpsToken>
(P007)
<wsp:Policy>
(P008)
<sp:RequireClientCertificate>
(P009)
</wsp:Policy>
(P010)
</sp:HttpsToken>
(P011)
</wsp:Policy>
(P012)
</sp:TransportToken>
(P013)
<sp:AlgorithmSuite>
(P014)
<wsp:Policy>
(P015)
<sp:Basic256 />
(P016)
</wsp:Policy>
(P017)
</sp:AlgorithmSuite>
(P018)
<sp:Layout>
(P019)
<wsp:Policy>
(P020)
<sp:Strict />
(P021)
</wsp:Policy>
(P022)
</sp:Layout>
(P023)
<sp:IncludeTimestamp />
(P024)
</wsp:Policy>
(P025)
</sp:TransportBinding>
(P026)
<sp:SignedSupportingTokens>
(P027)
<wsp:Policy>
(P028)
<sp:SamlToken sp:IncludeToken=”http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient”>
(P029)
<wsp:Policy>
(P030)
<sp:WssSamlV11Token10/>
(P031)
</wsp:Policy>
(P032)
</sp:SamlToken>
(P033)
</wsp:Policy>
(P034)
</sp:SignedSupportingTokens>
(P035)
</wsp:Policy>
Lines (P002)-(P025) contain a TransportBinding assertion
that indicates the message must be protected by a secure transport protocol
such as SSL or TLS.
Lines (P004)-(P012) contain a TransportToken assertion
indicating that the transport is secured by means of an HTTPS TransportToken,
requiring cryptographic operations to be performed based on the transport token
using the Basic256 algorithm suite (P015).
In addition, because this is SAML sender-vouches, a client
certificate is required (P008) as the basis of trust for the SAML Assertion and
for the content of the message [WSS10-SAML11-INTEROP
section 4.3.1].
The layout requirement in this case (P018)-(P022) is
automatically met (or may be considered moot) since there are no cryptographic tokens
required to be present in the WS-Security header.
A timestamp (P023) is required to be included in an
acceptable message.
Lines (P026)-(P034) contain a SignedSupportingTokens
assertion, which indicates that the referenced token is effectively “signed” by
the combination of usage of the client certificate for SSL authentication and
the cryptographic protection of SSL. However, the “signed” characteristic will
not be present after the message is delivered from the transport layer to the
recipient.
Lines (P028)-(P032) indicate the signed token is a SAML
Assertion (sender-vouches as described above in section 2.3) and on line (P030)
that it is a SAML 1.1 Assertion and that the WS-Security 1.0 SAML Profile [WSS10-SAML11-PROFILE] is being used.
This scenario is based on first WSS SAML Profile InterOp [WSS10-SAML11-INTEROP “Scenario #2 -
Sender-Vouches: Unsigned: SSL” section 4.4.4]
Here is the example request from that scenario:
(M001) <?xml
version="1.0" encoding="utf-8" ?>
(M002) <soap:Envelope
(M003) xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/
(M004) xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
(M005) xmlns:xsd=http://www.w3.org/2001/XMLSchema
(M006) xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401
(M007) -wss-wssecurity-secext-1.0.xsd"
(M008) xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss
(M009) -wssecurity-utility-1.0.xsd">
(M010) <soap:Header>
(M011) <wsse:Security
soap:mustUnderstand="1">
(M012) <wsu:Timestamp>
(M013) <wsu:Created>2003-03-18T19:53:13Z</wsu:Created>
(M014) </wsu:Timestamp>
(M015) <saml:Assertion
(M016) xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
(M017) MajorVersion="1"
MinorVersion="1"
(M018) AssertionID="2sxJu9g/vvLG9sAN9bKp/8q0NKU="
(M019) Issuer=www.opensaml.org
(M020) IssueInstant="2002-06-19T16:58:33.173Z">
(M021) <saml:Conditions
(M022) NotBefore="2002-06-19T16:53:33.173Z"
(M023) NotOnOrAfter="2002-06-19T17:08:33.173Z"/>
(M024) <saml:AuthenticationStatement
(M025) AuthenticationMethod=
(M026) "urn:oasis:names:tc:SAML:1.0:am:password"
(M027) AuthenticationInstant="2002-06-19T16:57:30.000Z">
(M028) <saml:Subject>
(M029) <saml:NameIdentifier
(M030) NameQualifier=www.example.com
(M031) Format="">
(M032) uid=joe,ou=people,ou=saml-demo,o=example.com
(M033) </saml:NameIdentifier>
(M034) <saml:SubjectConfirmation>
(M035) <saml:ConfirmationMethod>
(M036) urn:oasis:names:tc:SAML:1.0:cm:sender-vouches
(M037) </saml:ConfirmationMethod>
(M038) </saml:SubjectConfirmation>
(M039) </saml:Subject>
(M040) </saml:AuthenticationStatement>
(M041) </saml:Assertion>
(M042) </wsse:Security>
(M043) </soap:Header>
(M044) <soap:Body>
(M045) <Ping
xmlns="http://xmlsoap.org/Ping">
(M046) <text>EchoString</text>
(M047) </Ping>
(M048) </soap:Body>
(M049) </soap:Envelope>
Lines (M011)-(M042) contain the WS-Security 1.0 header
required by the WssSamlV11Token10 assertion (P030).
Lines (M012)-(M014) contain the wsu:Timestamp required by
IncludeTimestamp assertion (P023).
Lines (M015)-(M041) contain the SAML 1.1 Assertion required
by the WssSamlV11Token10 assertion (P030).
Note that the additional requirements identified in the
policy above are met by the SSL transport capabilities and do not appear in any
form in the SOAP message (M001)-(M049).
Initiator adds a SAML assertion (hk) to the SOAP Security
Header. Because the TransportBinding requires a Client Certificate AND the SAML
token is in an EndorsingSupportingTokens element, the Initiator may be
considered to be authorized by the issuer of the hk SAML assertion to bind
message content to the Subject of the assertion. If the Client Certificate
matches the certificate identified in the hk assertion, the Initiator may be regarded
as executing SAML hk responsibility of binding the Requestor, who would be the
Subject of the hk assertion, to the content of the message.
In this scenario, the IssuingAuthority is the issuer(signer)
of the hk SAML Assertion. The Requestor is the Subject of the Assertion and the
Initiator is authorized by the Authority to bind the Assertion to the message
using the ClientCertificate identified in the SAML Assertion, which should also
be used to sign the timestamp of the message with a separate Signature included
in the WS-Security header.
(P001)
<wsp:Policy xmlns:wsp="..." xmlns:wsu="..."
xmlns:sp="..."
(P002)
wsu:Id="Wss10SamlHkV11Tran_policy">>
(P003)
<sp:TransportBinding>
(P004)
<wsp:Policy>
(P005)
<sp:TransportToken>
(P006)
<wsp:Policy>
(P007)
<sp:HttpsToken>
(P008)
<wsp:Policy>
(P009)
<sp:RequireClientCertificate>
(P010)
</wsp:Policy>
(P011)
</sp:HttpsToken>
(P012)
</wsp:Policy>
(P013)
</sp:TransportToken>
(P014)
<sp:AlgorithmSuite>
(P015)
<wsp:Policy>
(P016)
<sp:Basic256 />
(P017)
</wsp:Policy>
(P018)
</sp:AlgorithmSuite>
(P019)
<sp:Layout>
(P020)
<wsp:Policy>
(P021)
<sp:Strict />
(P022)
</wsp:Policy>
(P023)
</sp:Layout>
(P024)
<sp:IncludeTimestamp />
(P025)
</wsp:Policy>
(P026)
</sp:TransportBinding>
(P027)
<sp:SignedEndorsingSupportingTokens>
(P028)
<wsp:Policy>
(P029)
<sp:SamlToken
sp:IncludeToken=”http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient”>
(P030)
<wsp:Policy>
(P031)
<sp:WssSamlV11Token10/>
(P032)
</wsp:Policy>
(P033)
</sp:SamlToken>
(P034)
</wsp:Policy>
(P035)
</sp:SignedEndorsingSupportingTokens>
(P036)
<wsp:Policy>
Section 2.3.2.3 contains an example message that is similar
to one that could be used for the policy above, except the Signed Endorsing
Supporting Token there is a SAML Version 2.0 token, and a SAML Version 1.1
token would be required here.
This scenario is based on the first WSS SAML Profile InterOp
[WSS10-SAML11-INTEROP Scenario #3].
In this case, the SAML token is included as part of the
message signature and sent only to the Recipient. The message security is
provided using X.509 certificates with both requestor and service having
exchanged these credentials via some out of band mechanism, which provides the
basis of trust of each others’ certificates.
In this scenario the SAML Authority is the Initiator who
uses the message signature to both provide the integrity of the message and to
establish the Initiator as the SAML Authority based on the X509 certificate
used to sign the message and the SignedSupportingTokens SAML Assertion.
Effectively, the SAML Assertion is being “issued” as part of the message
construction process. The Requestor is the Subject of the SAML Assertion. The Initiator
knows that the Recipient is expecting it to be the SAML Authority by the fact
that the policy specifies that the message requires a SignedSupportingTokens
SamlToken.
(P001) <wsp:Policy
xmlns:wsp="..." xmlns:wsu="..." xmlns:sp="..."
(P002) wsu:Id="Wss10SamlSvV11Asymm_endpoint_policy">
(P003) <wsp:ExactlyOne>
(P004) <wsp:All>
(P005) <sp:AsymmetricBinding>
(P006) <wsp:Policy>
(P007) <sp:InitiatorToken>
(P008) <wsp:Policy>
(P009) <sp:X509Token
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
(P010) <wsp:Policy>
(P011) <sp:WssX509V3Token10/>
(P012) </wsp:Policy>
(P013) </sp:X509Token>
(P014) </wsp:Policy>
(P015) </sp:InitiatorToken>
(P016) <sp:RecipientToken>
(P017) <wsp:Policy>
(P018) <sp:X509Token
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never">
(P019) <wsp:Policy>
(P020) <sp:WssX509V3Token10/>
(P021) </wsp:Policy>
(P022) </sp:X509Token>
(P023) </wsp:Policy>
(P024) </sp:RecipientToken>
(P025) <sp:AlgorithmSuite>
(P026) <wsp:Policy>
(P027) <sp:Basic256/>
(P028) </wsp:Policy>
(P029) </sp:AlgorithmSuite>
(P030) <sp:Layout>
(P031) <wsp:Policy>
(P032) <sp:Strict/>
(P033) </wsp:Policy>
(P034) </sp:Layout>
(P035) <sp:IncludeTimestamp/>
(P036) <sp:OnlySignEntireHeadersAndBody/>
(P037) </wsp:Policy>
(P038)
