This document describes several WS-SecurityPolicy [WS-SECURITYPOLICY]
examples. An example typically consists of the security aspects of a high-level
Web Service use-case with several variable components. Many of the examples are based on existing
use cases that have been conducted during WS-Security Interops [WSS-INTEROPS]. In those examples a reference is
included to identify the specific use case in the specific interop document
that is being demonstrated.
In the policy examples below, the “wsp” prefix refers to the
elements defined in the WS-Policy namespace:
xmlns:wsp=”http://www.w3.org/ns/ws-policy/”
the “sp” prefix refers to elements defined in the
WS-SecurityPolicy (WS-SP) namespace:
xmlns:sp=“http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702”
the “t” prefix refers to elements defined in the WS-Trust namespace:
xmlns:t=”
http://docs.oasis-open.org/ws-sx/ws-trust/200512”
Where uses cases are based on
existing scenarios, those scenarios are referenced at the beginning of the use
case section. The explicit documents describing the scenarios are identified by
links in [Section 3.2].
This section (1.1.*) describes the logical “actors” that
participate in the examples. In addition, there is a discussion on general
concepts that describes how the logical actors typically relate to the physical
message exchanges that take place.
This section also provides a security reference model designed
to provide context for the examples in terms of a conceptual framework within
which the actors interact, which is intended to help readers understand the
trust relationships implicit in the message exchanges shown in the examples.
In these examples there are always three important
conceptual entities to recognize that exist on the initiating side of a
transaction, where the transaction is being requested by sending an electronic
message that contains the details of the what is being requested and by whom
(the “entities” become “actors” as the discussion moves from the conceptual to
the specific). These three entities are:
- The
entity requesting the transaction (for example, if the transaction
is about an application for a home mortgage loan, then the entity
requesting the transaction is the prospective homeowner who will be liable
to make the payments on the loan if it is approved).
- The
entity approving the transaction to be requested. This entity is
generally known as an “identity provider”, or an “authority”, and the
purpose of this approving entity is to guarantee to a recipient entity
that the requesting entity is making a legitimate request (continuing the
above example, the authorizing entity in this case would be the
organization that helps the prospective homeowner properly fill out the
application, possibly a loan officer at the bank, saying that the loan
application is approved for further processing).
- The
entity initiating the actual electonic transaction message (in the
above example, this entity is simply the technical software used to
securely transmit the mortgage application request to a recipient
entity that will handle the processing of the mortgage application).
WS-SecurityPolicy is primarily concerned with the technical
software used between the initiating entity and the recipient entity, whom are
respectively officially referred to as the Initiator and the Recipient in the
WS-SecurityPolicy 1.2 specification (WS-SP)
(see section 1.4 of that document).
Therefore, the purpose of this section is to give a larger
real world context to understanding the examples and how to relate the
technical details of WS-SecurityPolicy to the actual logical actors involved in
the transactions governed by the technology.
The reason for providing this context is to help interested
readers understand that while the technology may be securing the integrity and
confidentiality of the messages, there are additional questions about
transactions such as who is liable for any commitments resulting from the
transaction and how those commitments are technically bound within the message
exchanges.
The purpose here is not to provide unequivocable answers to
all questions regarding liability of transactions, but to give a sense of how
the structuring of a request message ties the participating entities to the
transaction. Depending on how the WS-SecurityPolicy technology is used, these
“ties” can be relatively stronger or weaker. Depending on the nature of the
transactions supported by a particular Web Application, the system managers of
the Web Services Application being protected using WS-SecurityPolicy
techniques, may be interested in a conceptual framework for understanding which
WS-SP techniques are more or less appropriate for their needs.
These introductory sections are intended to provide this
type of conceptual framework for understanding how the examples in this
document may be interpreted in the above context of the three entities on the
initiating side of the transaction. A complementary model is also provided for
the recipient side of the transaction, but since the recipient is generally
concerned with validating the request, which is primarily a back office
function, less emphasis is focused on the options in that environment except as
they might relate back to the initiator side of the transaction.
The following diagram shows the actors and the relationships
that may be typically involved in a network security scenario:
Figure
1.
The diagram is intended to show the possible interactions
that may occur between actors in any given scenario, although, in general,
depending on the policy specified by the recipient, only a subset of the
possible interactions will actually occur in a given scenario. Note that the
Issuing and Validating Authorities, may, in general be either a WS-Trust
Security Token Service (STS) or other authority.
First, a brief narrative will describe the diagram, then the
actors will be defined in more detail.
In a typical example interaction, a Requestor wants to issue
a Web Service request to a Web Service that is hosted by the “Recipient” web
site on behalf of a RelyingParty, who is actually the business entity
responsible for making the service available and with whom any business
arrangements with the Requestor are made. One may think of this as an end to
end interaction between a Requestor and a RelyingParty, with technical
resources being provided by the Initiator on the Requestor side and the
Recipient on the RelyingParty side.
Technically, what occurs is that the Requestor hands the
request to the Initiator, which in turn issues a query to the Recipient and is
returned the WSDL [WSDL] describing the Web Service, which
generally includes WS-SP policy Assertions [WS-POLICY, WS-POLICYATTACHMENT] that describe the security
policies supported by the Recipient for this Web Service (Note: it is not
necessary that the information in the Assertions be obtained this way. It may
also be stored locally based on out of band agreements between the Requestor
and RelyingParty). This interaction is shown by the upper pair of arrows
between the Initiator and the Recipient.
Upon receipt of the WS-SP policy assertions, the Initiator
then interacts with the Requestor and the Issuing Authority, as needed in order
to meet the requirements specified by the WS-SP. Generally, what is required
here is that credentials and tokens are obtained from the Requestor and Issuing
Authority and assembled as required in a new WS-Security request message that
is to be issued to the Recipient.
(For example, if a UsernameToken is required by the
Recipient, one possibility is that the Initiator will query the Requestor for
Username and Password and create the appropriate token to include in the
Request.
Other possibilities exist as well,
but WS-SP only governs what the final message must contain. How it gets
constructed and how the pieces are assembled are specific to the system
environment that is being used.
In general, the examples in this
document will explain the interactions that might occur to meet the policy
requirements, but the actual sequences and specifics will be determined by the
setup of the systems involved.)
Finally, after assembling the necessary tokens,
the Initiator (or Requestor/Initiator) may sign and encrypt the message as
required by the WS-SP policy and send it to the Recipient.
Similar to the Requestor side, on the Recipient
side, the details of how the Recipient processes the message and uses a
Validating Authority to validate the tokens and what basis the RelyingParty
uses to accept or reject the request is system specific. However, in a general
sense, the 3 actors identified on the Recipient side will be involved to accept
and process a request.
(For
example, the Recipient may decrypt an encrypted UsernameToken containing a
clear text password and username and pass it to the Validating Authority for
validation and authentication, then the Recipient may pass the Request to the
RelyingParty, which may in turn issue a request for authorization to the
Validating Authority.
These details are beyond the scope of WS-SP and
the examples in this document, however, knowing that this is the context in
which WS-SP operates can be useful to understanding the motivation and
usefulness of different examples.)
The following list is a reference to identify the
logical actors in Figure 1. (In general, these actors may physically be
implemented such that more than one actor is included in the physical entity,
such as a Security Token Service (STS) [WS-TRUST] that
implements both an IssuingAuthority and a ValidatingAuthority. Similarly, in a
scenario where a user is at a security-enabled work station, the work station
may combine a Requestor and Initiator in a single physical entity.)
- Requestor:
the person or entity requesting the service and who will be supplying
credentials issued by the IssuingAuthority and will be validated by a
ValidatingAuthority. The Requestor is the logical entity that supplies the
credentials that ultimately get passed to the Recipient that will be
trusted by the RelyingParty if they are validated by the
ValidatingAuthority. (Note: the logistics of supplying the trusted
credential is distinct from the logistics of packaging up the credentials
within a WS-Security header in a SOAP message and transmitting that
message to the Recipient. The latter logistics are covered by the
Initiator, described below. The Requestor and Initiator may be combined into
a single physical entity and this is a common occurrence, however they do
not have to be and it is also a common occurrence that they are separate
physical entities. The latter case is typified by the Requestor being a
user at a browser that may be promped for credentials by the Initiator on
a server using HTTP to challenge the Requestor for a username and
password.)
- IssuingAuthority:
a Security Token Service (STS), which is an organization or entity that
typically issues authentication credentials for Requestors. Examples
include X509 Certificate Authority, Saml Token Authority, Kerberos Token
Authority. (For user passwords, the IssuingAuthority may be thought of as
the entity the user contacts for password services, such as changing
password, setting reminder phrases, etc.)
- Initiator:
the system or entity that sends the message(s) to the Recipient requesting
use of the service on behalf of the Requestor. Typically, the Initiator
will first contact the Recipient on behalf of the Requestor and obtain the
WS-SP policy and determine what tokens from what kind of IssuingAuthority
(X509, SAML, Kerberos, etc) that the Requestor will require to access the
service and possibly assist the Requestor to obtain those credentials. In
addition, based on the WS-SP policy, the Initiator determines how to
format the WS-Security headers of the messages being sent and how to use
the security binding required by the policy.
- Recipient:
the system or entity or organization that provides a web service for use
and is the supplier of the WS-SP policy that is contained in each example
and is the recipient of messages sent by Initiators. The Recipient manages
all the processing of the request message. It may rely on the services of
a ValidatingAuthority to validate the credentials contained in the
message. When the Recipient has completed the WS-SP directed processing of
the message it will generally be delivered to the RelyingParty which
continues processing of the message based on the assurances that the
Recipient has established by verifying the message is in compliance with
the WS-SP policies that are attached to the service description.
- ValidatingAuthority:
the organization or entity that typically validates Requestor credentials
for Relying Parties, and, in general, maintains those credentials in an
ongoing reliable manner. Typically, the Recipient will request the
ValidatingAuthority to validate the credentials before delivering the
Request to the RelyingParty for further processing.
- RelyingParty:
the organization or entity that relies on the security tokens contained in
the messages sent by the Initiator as a basis for providing the service.
For this document, the RelyingParty may simply be considered to be the
entity that continues processing the message after the Recipient has
completed all the processing required by the WS-SP policies attached to
the service description.
Of these actors, the Requestor and Initiator can generally
being regarded as “client-side” or “requestor-side” actors. The Recipient and
RelyingParty (or combined “RelyingParty/Recipient”) can be regarded as
“server-side” actors.
Note 1: In addition to the above labelling of the actors, there
is also the notion of “Sender”. Generally, the “Sender” may be thought
of as a Requestor/Initiator that is independently collecting information from a
user (who could be modeled as a separate benign actor to the left of the
Requestor in the figure 1.1 from whom the Requestor gathers information that
would be included in the message) and is submitting requests on behalf of that
user. Generally, the trust of the Recipient is on the Sender, and it is up to
the Sender to do whatever is necessary for the Sender to trust the user.
Examples of this configuration will be described in the SAML Sender Vouches
sections later in this document.
Note 2: The person or entity actually making the request is the
"Requestor", however, there are 2 common use cases: 1. the Requestor
is a user at a browser and the request is intercepted by a web service that can
do WS-Security and this web service is the "Initiator" which actually
handles the message protection and passes the Requestor’s credentials
(typically collected via http(s) challenge by the Initiator to the Requestor
for username/password) to the Recipient. 2. the Requestor is at a web-service
client enabled workstation, where the Requestor person making the request is
also in charge of the web service client that is initiating the request, in
which case the combined entity may be referred to as a "Requestor/Initator".
Physical message exchanges are between the Initiator and
Recipient. For the purposes of this document the Initiator and Recipient may be
considered to be the physical systems that exchange the messages. The Initiator
and Recipient use the keys that are involved in the WS-SP security binding that
protects the messages.
As described in the previous section, the Requestor is the
logical entity that gathers the credentials to be used in the request and the
Initiator is the logical entity that inserts the credentials into the request
message and does all the rest of the message construction in accordance with
the WS-SP policy. The Requestor may generally be thought of as being either a
separate physical entity from the Initiator, or
as part of a combined physical entity with the Initiator. An example of
the latter combined case would be a user at a client workstation equipped with
signing and encryption capabilities, where the combined entity may be referred
to as a “Requestor/Initiator”.
Similarly, the IssuingAuthority should generally be thought
of as a separate physical entity from the Initiator. However, in some cases,
such as SAML sender-vouches, the IssuingAuthority and the Initiator may be the
same entity.
In some other cases, such as the case where user passwords
are involved, the ValidatingAuthority system entity may also comprise the
Recipient and the Relying Party, since passwords are typically checked locally
for validity.
The focus of WS-SP is the notion that policy assertions are
attached to the Initiator and/or Recipient, however, the concepts in those
policies generally require understanding specifically the relation of the
parties involved (i.e. Requestor/Initiator, RelyingParty/Recipient). This is
because the Requestor in general does not know in advance what policies each
Web Service provider requires and it is necessary for practical purposes to
have a front end Initiator resolve the policy and coordinate whatever actions
are required to exchange the Requestor tokens for the tokens required by the
service. This token exchange may be done using WS-Trust [WS-TRUST]
to prepare the necessary requests and process responses from an STS
IssuingAuthority. Examples of these WS-Trust token exchanges may be found in [WSSX-INTEROP].
Typically both the Requestor/Initiator and
Recipient/RelyingParty will have relations with the
IssuingAuthority/ValidatingAuthority and often establish contact with those
Authorities using WS-Trust for the purpose of obtaining and validating tokens
used in their Web Service interactions. The policies for using the Authority
may also be represented using WS-SP, but they are typically no different from
the policies shown in the examples in this document. The policies in this
document may be used for any kind of request, whether it be a request to a
service provider for general content or operations or a request to an Authority
for authentication tokens.
In each example the relations between these actors and how
the request message is prepared will be described, because, in general, the
policy requirements will imply these relationships. Generally, each of the 3
client side actors, the Requestor, the Initiator, and the IssuingAuthority will
contribute to the preparation of the request message, which is the primary
focus of this document. For validation of the message, the Recipient, the
RelyingParty, and the ValidatingAuthority are generally involved, but for this
document the focus is simply that the Recipient provides the WS-SP policy that
dictates the preparation of the request message.
The specifics of whom is trusted for X509 certificates
depends on the specific organization’s PKI (Public Key Infrastructure) setup.
For this document, we shall assume the Subject of the X509 certificate
identifies the actor, which may be the IssuingAuthority, or the Initiator, or
the Requestor, depending on the example. We shall also assume that the issuer
of the X509 certificates is a general Certificate Authority not directly
involved in any authorization of the web service transactions, but is relied on
for the validity of the X509 certificate in a manner out of scope of the
scenarios covered. In addition, this document does not explicitly address the
case of X509 certificates issued by the IssuingAuthority actor. Such use cases
are generally implicitly covered if one assumes that such relations are
automatically covered by the specifics of the organization PKI setups.
However, the IssuingAuthority may issue tokens, such as SAML
holder-of-key that contain X509 certificates. In these cases, the basis of
trust is that the X509 Certificate of the IssuingAuthority was used to protect
the X509 certificate of the Requestor which is contained in the signed SAML
holder-of-key token. I.e. any “chaining” of tokens is done by referencing those
tokens within signed XML structures and not by issuing actual X509 certificates
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”,
“SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in
this document are to be interpreted as described in [RFC2119].
1.3 Normative References
[RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, http://www.ietf.org/rfc/rfc2119.txt,
IETF RFC 2119, March 1997.
[WSS10-SOAPMSG]
OASIS Standard, “Web Services Security: SOAP Message Security 1.0 (WS-Security
2004)”, March 2004.
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf
[WSS11-SOAPMSG] OASIS Standard, “Web Services
Security: SOAP Message Security 1.1”, OASIS Standard incorporating Approved
Errata, 01 November 2006.
http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-errata-os-SOAPMessageSecurity.pdf
[WSS10-USERNAME] OASIS Standard, “Web
Services Security: UsernameToken Profile 1.0”, March 2004.
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0.pdf
[WSS11-USERNAME] OASIS Standard, “Web
Services Security: UsernameToken Profile 1.1”, February 2006.
http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-UsernameTokenProfile.pdf
[WSS10-X509-PROFILE] OASIS Standard, “Web Services Security: X.509
Certificate Token Profile 1.0”, March 2004.
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0.pdf
[WSS11-X509-PROFILE] OASIS Standard, “Web Services Security: X.509
Certificate Token Profile 1.1”, OASIS Standard incorporating Approved
Errata, 01 November 2006.
http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-errata-os-x509TokenProfile.pdf
[WSS10-SAML11-PROFILE] OASIS Standard, “Web Services Security: SAML
Token Profile 1.0”, December 2004.
http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0.pdf
[WSS11-SAML1120-PROFILE] OASIS Standard, “Web Services Security: SAML
Token Profile 1.1”, OASIS Standard Incorporating Approved Errata, 1 November 2006.
http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-errata-os-SAMLTokenProfile.pdf
[WSS11-LIBERTY-SAML20-PROFILE]
http://www.projectliberty.org/liberty/content/download/894/6258/file/liberty-idwsf-security-mechanisms-saml-profile-v2.0.pdf
[WSS-TC-ALL-TOKEN-PROFILES] OASIS WS-Security TC links to all other WSS
1.0 and WSS 1.1 token profiles
http://www.oasis-open.org/specs/index.php#wssv1.0
http://www.oasis-open.org/specs/index.php#wssv1.1
and other documents (interops) in the TC repository:
http://www.oasis-open.org/committees/documents.php?wg_abbrev=wss
[WS-SECURITYPOLICY] OASIS Standard, “WS-SecurityPolicy 1.2”, July
2007.
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.doc
[WS-SECURECONVERSATION] OASIS
Standard, “WS-SecureConversation 1.3”, March 2007. http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/ws-secureconversation-1.3-os.doc
[WS-TRUST] OASIS
Standard, “WS-Trust 1.3”, March 2007.
http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.doc
[WS-POLICY] http://www.w3.org/TR/ws-policy
[WS-POLICYATTACHMENT] http://www.w3.org/TR/ws-policy-attach
[WSDL] http://www.w3.org/TR/wsdl
[SSL] http://www.ietf.org/rfc/rfc2246.txt
[SAML11-CORE] OASIS Standard, “Assertions and Protocol for the OASIS Security
Assertion Markup Language (SAML) V1.1”, September 2003.
http://www.oasis-open.org/committees/download.php/3406/oasis-sstc-saml-core-1.1.pdf
[SAML20-CORE] OASIS Standard, “Assertions and Protocols for the OASIS Security
Assertion Markup Language (SAML) V2.0”, March 2005.
http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf
[XML-DSIG] http://www.w3.org/TR/xmldsig-core/
[XML-ENCR] http://www.w3.org/TR/xmlenc-core/
WSS10-INTEROP-01: OASIS Working Draft 06, “Web Services
Security: Interop 1 Scenarios”, Jun 2003.
http://www.oasis-open.org/committees/download.php/11374/wss-interop1-draft-06-merged-changes.pdf
WSS10-INTEROP-02: OASIS
Working Draft 06, “Web Services Security: Interop 2 Scenarios”, Oct 2003.
http://www.oasis-open.org/committees/download.php/11375/wss-interop2-draft-06-merged.doc
WSS11-INTEROP-01:
OASIS Working Draft 02, “Web Services
Security 1.1: Interop Scenario”, June 2005. http://www.oasis-open.org/committees/download.php/12997/wss-11-interop-draft-01.doc
WSS10-KERBEROS-INTEROP: OASIS Working Draft 02, “Web Services
Security: Kerberos Token Profile Interop Scenarios”, Jan 2005.
http://www.oasis-open.org/committees/download.php/11720/wss-kerberos-interop.doc
WSS10-SAML11-INTEROP: OASIS Working Draft 12, “Web Services
Security: SAML Interop 1 Scenarios”, July 2004.
http://www.oasis-open.org/committees/download.php/7702/wss-saml-interop1-draft-12.doc
WSS11-SAML1120-INTEROP: OASIS Working Draft 4, “Web Services
Security: SAML 2.0 Interop Scenarios”,
January 2005.
http://www.oasis-open.org/committees/download.php/16556/wss-saml2-interop-draft-v4.doc
WSSX-PRE-INTEROP: OASIS
Contribution Version 1.0d, “WS-SecureConversation
and WS-Trust Interop Scenarios”, September 29, 2004.
http://docs.oasis-open.org/ws-sx/security-policy/examples/ws-sp-usecases-examples.html
WSSX-WSTR-WSSC-INTEROP: OASIS White Paper Version ED-10,
“WS-SX Interop Scenarios - Phase 2 Scenarios for demonstration of WS-SX TC
specifications”, October 31, 2006. http://www.oasis-open.org/committees/download.php/20954/ws-sx-interop-ed-10.doc
WS-SECURE-INTEROP: OASIS White Paper Version ED-01,
“Examples of Secure Web Service Message Exchange”, July 11, 2008.
http://www.oasis-open.org/committees/download.php/28803/ws-sx-secure-message-examples.doc
WSI-SCM-SAMPLEAPPL:
http://java.sun.com/webservices/docs/1.4/wsi-sampleapp/index.html
(login required)
2.1 UsernameToken
UsernameToken authentication scenarios that use simple
username password token for authentication. There are several sub-cases.
In this model a UsernameToken is placed within a WS-Security
header in the SOAP Header [WSS10-USERNAME, WSS11-USERNAME]. No other security measure is used.
Because no security binding is used, there is no explicit
distinction between the Requestor, who is identified in the UsernameToken and
the Initiator, who physically sends the message. They may be one and the same
or distinct parties. The lack of a security binding indicates that any direct
URL access method (ex. HTTP) may be used to access the service.
This scenario is based on the first
WS-Security Interop Scenarios Document [WSS10-INTEROP-01
Scenario 1 – section 3.4.4]
(http://www.oasis-open.org/committees/download.php/11374/wss-interop1-draft-06-merged-changes.pdf).
This policy says that Requestor/Initiator
must send a password in a UsernameToken in a WS-Security header to the Recipient
(who as the Authority will validate the password). The password is required
because that is the default requirement for the Web Services Security Username
Token Profile 1.x [WSS10-USERNAME, WSS11-USERNAME].
This setup is only recommended where
confidentiality of the password is not an issue, such as a pre-production test
scenario with dummy passwords, which might be used to establish that the
Initiator can read the policy and prepare the message correctly, and that
connectivity and login to the service can be performed.
(P001) <wsp:Policy>
(P002) <sp:SupportingTokens>
(P003) <wsp:Policy>
(P004) <sp:UsernameToken
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient"
(P005) </wsp:Policy>
(P006) </sp:SupportingTokens>
(P007) </wsp:Policy>
An example of a message that conforms to the
above stated policy is as follows.
(M001)
<?xml version="1.0" encoding="utf-8" ?>
(M002)
<soap:Envelope xmlns:soap="...">
(M003)
<soap:Header>
(M004)
<wsse:Security
soap:mustUnderstand=“1” xmlns:wsse="...">
(M005)
<wsse:UsernameToken>
(M006)
<wsse:Username>Chris</wsse:Username>
(M007)
<wsse:Password
Type=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText”>sirhC</wsse:Password>
(M008)
<wsse:Nonce
EncodingType="...#Base64Binary"
(M009)
>pN...=</wsse:Nonce>
(M010)
<wsu:Created>2007-03-28T18:42:03Z</wsu:Created>
(M011)
</wsse:UsernameToken>
(M012)
</wsse:Security>
(M013)
</soap:Header>
(M014)
<soap:Body>
(M015)
<Ping xmlns="http://xmlsoap.org/Ping">
(M016)
<text>EchoString</text>
(M017)
</Ping>
(M018)
</soap:Body>
(M019) </soap:Envelope>
The UsernameToken element starting on line
(M005) satisfies the UsernameToken assertion on line (P004). By default, a
Password element is included in the UsernameToken on line (M007) holding a
plain text password.
Lines (M008-M010) contain an optional Nonce element and Created timestamp,
which, while optional, are recommended to improve security of requests against
replay and other attacks [WSS10‑USERNAME].
All WS-Security compliant implementations should support the UsernameToken with
cleartext password with or without the Nonce and Created elements.
This policy is the same as 2.1.1.1 except no password is to
be placed in the UsernameToken. There are no credentials to further establish
the identity of the Requestor and no security binding that the Initiator is
required to use. This is a possible production scenario where all the service
provider wants is a UsernameToken to associate with the request. There is no
explicit Authority implied in this scenario, except possibly that the username
extracted from the UsernameToken would be evaluated by a server-side
“Authority” that maintained a list of valid username values.
(P001)
<wsp:Policy xmlns:wsp="..." xmlns:sp="...">
(P002)
<sp:SupportingTokens>
(P003)
<wsp:Policy>
(P004)
<sp:UsernameToken
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
(P005)
<wsp:Policy>
(P006)
<sp:NoPassword/>
(P007)
</wsp:Policy>
(P008)
</sp:UsernameToken>
(P009)
</wsp:Policy>
(P010)
</sp:SupportingTokens>
(P011)
</wsp:Policy>
Lines (P002) – (P010) contain the SupportingToken assertion
which includes a UsernameToken
indicating that a UsernameToken must be included in the security header.
Line (P006) requires that the wsse:Password element must not
be present in the UsernameToken.
An example of an input message that conforms to the above
stated policy is as follows:
(M001)
<?xml version="1.0" encoding="utf-8" ?>
(M002)
<soap:Envelope xmlns:soap="...">
(M003)
<soap:Header>
(M004)
<wsse:Security
soap:mustUnderstand="1"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
(M005)
<wsse:UsernameToken>
(M006)
<wsse:Username>Chris</wsse:Username>
(M007)
</wsse:UsernameToken>
(M008)
</wsse:Security>
(M009)
</soap:Header>
(M010)
<soap:Body>
(M011)
<Ping
xmlns="http://xmlsoap.org/Ping">
(M012)
<text>EchoString</text>
(M013)
</Ping>
(M014)
</soap:Body>
(M015)
</soap:Envelope>
Lines (M005) – (M007) hold the unsecured UsernameToken which
only contains the name of user (M006), but no password.
This scenario is
similar to 2.1.1.1, except it is more secure, because the Requestor password is
protected by combining it with a nonce and timestamp, and then hashing the
combination. Therefore, this may be considered as a potential production
scenario where passwords may be safely used. It may be assumed that the
password must be validated by a server-side ValidatingAuthority and so must
meet whatever requirements the specific Authority has established.
(P001) <wsp:Policy
xmlns:wsp="..." xmlns:sp="...">
(P002) <sp:SupportingTokens>
(P003) <wsp:Policy>
(P004) <sp:UsernameToken
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
(P005) <wsp:Policy>
(P006) <sp:HashPassword/>
(P007) </wsp:Policy>
(P008) </sp:UsernameToken>
(P009) </wsp:Policy>
(P010) </sp:SupportingTokens>
(P011) </wsp:Policy>
An example of a
message that conforms to the above stated policy is as follows.
(M001)
<?xml version="1.0" encoding="utf-8" ?>
(M002)
<soap:Envelope xmlns:soap="..." xmlns:wsu=”...”>
(M003)
<soap:Header>
(M004)
<wsse:Security
soap:mustUnderstand=“1”
xmlns:wsse="...">
(M005)
<wsse:UsernameToken
wsu:Id="uuid-7cee5976-0111-e9c1-e34b-af1e85fa3866">
(M006)
<wsse:Username>Chris</wsse:Username>
(M007) <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-usernametoken-profile-1.0#PasswordDigest"
>weYI3nXd8LjMNVksCKFV8t3rgHh3Rw==</wsse:Password>
(M008) <wsse:Nonce>WScqanjCEAC4mQoBE07sAQ==</wsse:Nonce>
(M009) <wsu:Created>2007-05-01T01:15:30Z</wsu:Created>
(M010)
</wsse:UsernameToken>
(M011)
</wsse:Security>
(M012)
</soap:Header>
(M013)
<soap:Body
wsu:Id="uuid-7cee4264-0111-e0cb-8329-af1e85fa3866">
(M014)
<Ping
xmlns="http://xmlsoap.org/Ping">
(M015)
<text>EchoString</text>
(M016)
</Ping>
(M017)
</soap:Body>
(M018) </soap:Envelope>
This message is
very similar to the one in section 2.1.1.1. A UsernameToken starts on line
(M005) to satisfy the UserNameToken assertion. However, in this example the
Password element on line (M007) is of type PasswordDigest to satisfy the
HashPassword assertion on line (P006). The Nonce (M008) and Created timestamp
(M009) are also included as dictated by the HashPassword assertion. The Nonce
and timestamp values are included in the password digest on line (M007).
Both server authentication and mutual (client AND server)
authentication SSL [SSL] are supported via use of the
sp:TransportBinding policy assertion. (For mutual authentication, a
RequireClientCertificate assertion may be inserted within the HttpsToken
assertion. The ClientCertificate may be regarded as a credential token for
authentication of the Initiator, which in the absence of any additional token
requirements would generally imply the Initiator is also the Requestor. The
Authority would be the issuer of the client certificate.)
<wsp:Policy
xmlns:wsp="..." xmlns:sp="...">
<sp:TransportBinding>
<wsp:Policy>
<sp:TransportToken>
<wsp:Policy>
<sp:HttpsToken />
</wsp:Policy>
</sp:TransportToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256 />
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:Layout>
<wsp:Policy>
<sp:Strict />
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimestamp />
</wsp:Policy>
</sp:TransportBinding>
</wsp:Policy>
Additional tokens
can be included as supporting tokens. Each of the UsernameTokens described in
section 2.1.1 may be used in this scenario and any clear text information or
password will be protected by SSL. So, for example, including a user name token
over server authentication SSL we have:
(P001) <wsp:Policy
xmlns:wsp="..." xmlns:sp="...">
(P002) <sp:TransportBinding>
(P003) <wsp:Policy>
(P004) <sp:TransportToken>
(P005) <wsp:Policy>
(P006) <sp:HttpsToken/>
(P007) </wsp:Policy>
(P008) </sp:TransportToken>
(P009) <sp:AlgorithmSuite>
(P010) <wsp:Policy>
(P011) <sp:Basic256/>
(P012) </wsp:Policy>
(P013) </sp:AlgorithmSuite>
(P014) <sp:Layout>
(P015) <wsp:Policy>
(P016) <sp:Strict/>
(P017) </wsp:Policy>
(P018) </sp:Layout>
(P019) <sp:IncludeTimestamp/>
(P020) </wsp:Policy>
(P021) </sp:TransportBinding>
(P022) <sp:SupportingTokens>
(P023) <wsp:Policy>
(P024) <sp:UsernameToken/>
(P025) </wsp:Policy>
(P026) </sp:SupportingTokens>
(P027) </wsp:Policy>
Lines (P002) –
(P021) contain the TransportBinding assertion which indicates that the message
must be protected by a secure transport protocol like SSL or TLS.
Lines (P004) –
(P008) hold the TransportToken assertion, indicating that the transport is
secured by means of an HTTPS Transport Token, requiring to perform
cryptographic operations based on the transport token using the Basic256
algorithm suite (P011).
In addition, the
Layout assertion in lines (P014) – (P018) require that the order of the
elements in the SOAP message security header must conform to rules defined by WSSECURITYPOLICY
that follow the general principle of 'declare before use'.
Line (P019)
indicates that the wsu:Timestamp element must be present in the SOAP message
security header.
Lines (P022) –
(P026) Lines contain the SupportingToken assertion which includes a
UsernameToken indicating that a UsernameToken
must be included in the security header.
An example of an
input message prior to the transport encryption that conforms to the above
stated policy is as follows:
(M001) <?xml
version="1.0" encoding="utf-8" ?>
(M002) <soap:Envelope
xmlns:soap="..." xmlns:wsu="...">
(M003) <soap:Header>
(M004) <wsse:Security
soap:mustUnderstand="1"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-
wss-wssecurity-secext-1.0.xsd">
(M005) <wsu:Timestamp
wsu:Id="uuid-8066364f-0111-f371-47bf-ba986d2d7dc4">
(M006) <wsu:Created>2001-09-13T08:42:00Z</wsu:Created>
(M007) </wsu:Timestamp>
(M008) <wsse:UsernameToken
wsu:Id="uuid-8066368d-0111-e744-f37b-ba986d2d7dc4">
(M009) <wsse:Username>Chris</wsse:Username>
(M010) <wsse:Password
Type=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText”>sirhC</wsse:Password>
(M011) </wsse:UsernameToken>
(M012) </wsse:Security>
(M013) </soap:Header>
(M014) <soap:Body
wsu:Id="uuid-8066363f-0111-ffdc-de48-ba986d2d7dc4">
(M015) <Ping
xmlns="http://xmlsoap.org/Ping">
(M016) <text>EchoString</text>
(M017) </Ping>
(M018) </soap:Body>
(M019) </soap:Envelope>
Lines (M005) –
(M007) hold Timestamp element according to the IncludeTimestamp assertion.
Lines (M008) –
(M011) hold the UsernameToken which contains the name (M009) and password
(M010) of the user sending this message.
This scenario is
based on WS-I SCM Security Architecture Technical requirements for securing the
SCM Sample Application, March 2006 [WSI-SCM-SAMPLEAPPL – GetCatalogRequest,
SubmitOrderRequest].
This use case
corresponds to the situation where both parties have X.509v3 certificates (and
public-private key pairs). The Initiator includes a user name token that may
stand for the Requestor on-behalf-of which the Initiator is acting. The
UsernameToken is included as a SupportingToken; this is also encrypted. The
Authority for this request is generally the Subject of the Initiator’s trusted
X.509 Certificate.
We model this by
using the asymmetric security binding [WSSP] with a UsernameToken SupportingToken.
The message level
policies in this section and subsequent sections cover a different scope of the
web service definition than the security binding level policy and so appear as
separate policies and are attached at WSDL Message Policy Subject. These are
shown below as input and output policies.
Thus, we need a set of coordinated policies one with endpoint subject
and two with message subjects to achieve this use case.
The policy is as
follows:
(P001) <wsp:Policy
wsu:Id="wss10_up_cert_policy" >
(P002) <wsp:ExactlyOne>
(P003) <wsp:All>
(P004) <sp:AsymmetricBinding>
(P005) <wsp:Policy>
(P006) <sp:InitiatorToken>
(P007) <wsp:Policy>
(P008) <sp:X509Token
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
(P009) <wsp:Policy>
(P010) <sp:WssX509V3Token10/>
(P011) </wsp:Policy>
(P012) </sp:X509Token>
(P013) </wsp:Policy>
(P014) </sp:InitiatorToken>
(P015) <sp:RecipientToken>
(P016) <wsp:Policy>
(P017) <sp:X509Token
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never">
(P018) <wsp:Policy>
(P019) <sp:WssX509V3Token10/>
(P020) </wsp:Policy>
(P021) </sp:X509Token>
(P022) </wsp:Policy>
(P023) </sp:RecipientToken>
(P024) <sp:AlgorithmSuite>
(P025) <wsp:Policy>
(P026) <sp:Basic256/>
(P027) </wsp:Policy>
(P028) </sp:AlgorithmSuite>
(P029) <sp:Layout>
(P030) <wsp:Policy>
(P031) <sp:Strict/>
(P032) </wsp:Policy>
(P033) </sp:Layout>
(P034) <sp:IncludeTimestamp/>
(P035) <sp:OnlySignEntireHeadersAndBody/>
(P036) </wsp:Policy>
(P037) </sp:AsymmetricBinding>
(P038) <sp:Wss10>
(P039) <wsp:Policy>
(P040) <sp:MustSupportRefKeyIdentifier/>
(P041) </wsp:Policy>
(P042) </sp:Wss10>
(P043) <sp:SignedEncryptedSupportingTokens>
(P044) <wsp:Policy>
(P045) <sp:UsernameToken
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
(P046) <wsp:Policy>
(P047) <sp:WssUsernameToken10/>
(P048) </wsp:Policy>
(P049) </sp:UsernameToken>
(P050) </wsp:Policy>
(P051) </sp:SignedEncryptedSupportingTokens>
(P052) </wsp:All>
(P053) </wsp:ExactlyOne>
</wsp:Policy>
(P054) <wsp:Policy
wsu:Id="WSS10UsernameForCertificates_input_policy">
(P055) <wsp:ExactlyOne>
(P056) <wsp:All>
(P057) <sp:SignedParts>
(P058) <sp:Body/>
(P059) </sp:SignedParts>
(P060) <sp:EncryptedParts>
(P061) <sp:Body/>
(P062) </sp:EncryptedParts>
(P063) </wsp:All>
(P064) </wsp:ExactlyOne>
(P065) </wsp:Policy>
(P066) <wsp:Policy
wsu:Id="WSS10UsernameForCertificate_output_policy">
(P067) <wsp:ExactlyOne>
(P068) <wsp:All>
(P069) <sp:SignedParts>
(P070) <sp:Body/>
(P071) </sp:SignedParts>
(P072) <sp:EncryptedParts>
(P073) <sp:Body/>
(P074) </sp:EncryptedParts>
(P075) </wsp:All>
(P076) </wsp:ExactlyOne>
(P077) </wsp:Policy>
Lines (P004) –
(P037) contain the AsymmetricBinding assertion which indicates that the initiator’s
token must be used for the message signature and the recipient’s token must be
used for message encryption.
Lines (P006) –
(P014) contain the InitiatorToken assertion. Within that assertion lines (P008)
– (P012) indicate that the initiator token must be an X.509 token that must be
included with all messages sent to the recipient. Line (P010) dictates the
X.509 token must be an X.509v3 security token as described in the WS-Security
1.0 X.509 Token Profile.
Lines (P015) –
(P023) contain the RecipientToken assertion. Within that assertion lines (P017)
– (P021) dictate the recipient token must also be an X.509 token as described
in the WS-Security 1.0 X.509 Token Profile, however as stated on line (P017) it
must not be included in any message. Instead, according to the
MustSupportKeyRefIdentitier assertion on line (P040) a KeyIdentifier must be
used to identify the token in any messages where the token is used.
Line (P034)
requires the inclusion of a timestamp.
Lines (P043) –
(P051) contain a SignedEncryptedSupportingTokens assertion which identifies the
inclusion of an additional token which must be included in the message
signature and encrypted. Lines (P045) – (P049) indicate that the supporting
token must be a UsernameToken and must be included in all messages to the
recipient. Line (P047) dictates the UsernameToken must conform to the
WS-Security 1.0 UsernameToken Profile.
Lines (P055) –
(P066) contain a policy that is attached to the input message. Lines (P058) –
(P060) require that the body of the input message must be signed. Lines (P061)
– (P063) require the body of the input message must be encrypted.
Lines (P067) –
(P078) contain a policy that is attached to the output message. Lines (P070) –
(P072) require that the body of the output message must be signed. Lines (P073)
– (P075) require the body of the output message must be encrypted.
An example of an
input message that conforms to the above stated policy is as follows.
(M001) <?xml
version="1.0" encoding="utf-8" ?>
(M002) <soap:Envelope
xmlns:soap="..." xmlns:xenc="..."
xmlns:ds="...">
(M003) <soap:Header>
(M004) <wsse:Security soap:mustUnderstand=“1” xmlns:wsse="..."
xmlns:wsu="...">
(M005) <xenc:ReferenceList>
(M006) <xenc:DataReference
URI="#encUT"/>
(M007) <xenc:DataReference
URI=”#encBody”/>
(M008) </xenc:ReferenceList>
(M009) <wsu:Timestamp
wsu:Id="T0">
(M010) <wsu:Created>2001-09-13T08:42:00Z</wsu:Created>
(M011) </wsu:Timestamp>
(M012) <wsse:BinarySecurityToken wsu:Id="binaryToken"
ValueType="…#X509v3" EncodingType="…#Base64Binary">
(M013) MIIEZzCCA9CgAwIBAgIQEmtJZc0…
(M014) </wsse:BinarySecurityToken>
(M015) <xenc:EncryptedData
wsu:Id="encUT">
(M016) <ds:KeyInfo>
(M017) <wsse:SecurityTokenReference>
(M018) <wsse:KeyIdentifier
EncodingType="...#Base64Binary" ValueType="...#X509SubjectKeyIdentifier">
(M019) MIGfMa0GCSq…
(M020) </wsse:KeyIdentifier>
(M021) </wsse:SecurityTokenReference>
(M022) </ds:KeyInfo>
(M023) <xenc:CipherData>
(M024) <xenc:CipherValue>...</xenc:CipherValue>
(M025) </xenc:CipherData>
(M026) </xenc:EncryptedData>
(M027) <ds:Signature>
(M028) <ds:SignedInfo>…
(M029) <ds:Reference
URI="#T0">…</ds:Reference>
(M030) <ds:Reference
URI="#usernameToken">…</ds:Reference>
(M031) <ds:Reference
URI="#body">…</ds:Reference>
(M032) </ds:SignedInfo>
(M033) <ds:SignatureValue>HFLP…</ds:SignatureValue>
(M034) <ds:KeyInfo>
(M035) <wsse:SecurityTokenReference>
(M036) <wsse:Reference
URI="#binaryToken"/>
(M037) </wsse:SecurityTokenReference>
(M038) </ds:KeyInfo>
(M039) </ds:Signature>
(M040) </wsse:Security>
(M041) </soap:Header>
(M042) <soap:Body wsu:Id="body">
(M043) <xenc:EncryptedData
wsu:Id="encBody">
(M044) <ds:KeyInfo>
(M045) <wsse:SecurityTokenReference>
(M046) <wsse:KeyIdentifier
EncodingType="...#Base64Binary" ValueType="...#X509SubjectKeyIdentifier">
(M047) MIGfMa0GCSq…
(M048) </wsse:KeyIdentifier>
(M049) </wsse:SecurityTokenReference>
(M050) </ds:KeyInfo>
(M051) <xenc:CipherData>
(M052) <xenc:CipherValue>...</xenc:CipherValue>
(M053) </xenc:CipherData>
(M054) </xenc:EncryptedData>
(M055) </soap:Body>
(M056) </soap:Envelope>
Line (M006) is an
encryption data reference that references the encrypted UsernameToken on lines
(M015) – (M024) which was required to be included by the
SignedEncryptedSupportingTokens assertion. Lines (M018) – (M020) hold a
KeyIdentifier of the recipient’s token used to encrypt the UsernameToken as
required by the AsymmetricBinding assertion. Because the RecipientToken
assertion disallowed the token from being inserted into the message, a
KeyIdentifier is used instead of a reference to an included token.
Line (M007) is an
encryption data reference that references the encrypted body of the message on
lines (M043) – (M054). The encryption was required by the EncryptedParts
assertion of the input message policy. It also uses the recipient token as
identified by the KeyIdentifier.
Lines (M009) –
(M011) contain a timestamp for the message as required by the IncludeTimestamp
assertion.
Lines (M012) –
(M014) contain the BinarySecurityToken holding the X.509v3 certificate of the
initiator as required by the InitiatorToken assertion.
Lines (M027) –
(M039) contain the message signature.
Line (M029)
indicates the message timestamp is included in the signature as required by the
IncludeTimestamp assertion definition.
Line (M030)
indicates the supporting UsernameToken is included in the signature as required
by the SignedEncryptedSupportingTokens assertion. Because the token was
encrypted its content prior to encryption is included below to better
illustrate the reference.
(M057) <wsse:UsernameToken
wsu:Id="usernameToken">
(M058) <wsse:Username>Chris</wsse:Username>
(M059) <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">sirhC</wsse:Password>
(M060) </wsse:UsernameToken>
Line (M031)
indicates the message body is included in the signature as required by the
SignedParts assertion of the input message policy.
Note that the
initiator’s BinarySecurityToken is not included in the message signature as it
was not required by policy.
Line (M036)
references the initiator’s BinarySecurityToken included in the message for
identifying the key used for signing as dictated by the AsymmetricBinding
assertion.
This scenario is based on the first WS-Security Interop
Scenarios Document [WSS10-INTEROP-01 Scenario 2 – section 4.4.4]
(http://www.oasis-open.org/committees/download.php/11374/wss-interop1-draft-06-merged-changes.pdf).
This policy says that Requestor/Initiator must send a
password in an encrypted UsernameToken in a WS-Security header to the Recipient
(who as the Authority will validate the password). The password is required
because that is the default requirement for the Web Services Security Username
Token Profile 1.x [WSS10-USERNAME, WSS11-USERNAME].
This setup is only recommended when the sender cannot
provide the “message signature” and it is recommended that the receiver employs
some security mechanisms external to the message to prevent the spoofing
attacks.
The policy is as follows:
(P001) <wsp:Policy
wsu:Id="wss10_encrypted_unt_policy" >
(P002) <sp:AsymmetricBinding>
(P003) <wsp:Policy>
(P004) <sp:InitiatorEncryptionToken>
(P005) <wsp:Policy>
(P006) <sp:X509Token
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never">
(P007) <wsp:Policy>
(P008) <sp:WssX509V3Token10/>
(P009) </wsp:Policy>
(P010) </sp:X509Token>
(P011) </wsp:Policy>
(P012) </sp:InitiatorEncryptionToken>
(P013) <sp:RecipientSignatureToken>
(P014) <wsp:Policy>
(P015) <sp:X509Token
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never">
(P016) <wsp:Policy>
(P017) <sp:WssX509V3Token10/>
(P018) </wsp:Policy>
(P019) </sp:X509Token>
(P020) </wsp:Policy>
(P021) </sp:RecipientSignatureToken>
(P022) <sp:AlgorithmSuite>
(P023) <wsp:Policy>
(P024) <sp:Basic256/>
(P025) </wsp:Policy>
(P026) </sp:AlgorithmSuite>
(P027) <sp:Layout>
(P028) <wsp:Policy>
(P029) <sp:Lax/>
(P030) </wsp:Policy>
(P031) </sp:Layout>
(P032) <sp:IncludeTimestamp/>
(P033) <sp:OnlySignEntireHeadersAndBody/>
(P034) </wsp:Policy>
(P035) </sp:AsymmetricBinding>
(P036) <sp:Wss10>
(P037) <wsp:Policy>
(P038) <sp:MustSupportRefKeyIdentifier/>
(P039) <sp:MustSupportRefIssuerSerial/>
(P040) </wsp:Policy>
(P041) </sp:Wss10>
(P042) <sp:EncryptedSupportingTokens>
(P043) <wsp:Policy>
(P044) <sp:UsernameToken
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
(P045) <wsp:Policy>
(P046) <sp:HashPassword/>
(P047) <sp:WssUsernameToken10/>
(P048) </wsp:Policy>
(P049) </sp:UsernameToken>
(P050) </wsp:Policy>
(P051) </sp:EncryptedSupportingTokens>
(P052) </wsp:Policy>
(P053) <wsp:Policy wsu:Id="WSS10UsernameForCertificates_input_policy">
(P054) <wsp:ExactlyOne>
(P055) <wsp:All>
(P056) <sp:EncryptedParts>
(P057) <sp:Body/>
(P058) </sp:EncryptedParts>
(P059) </wsp:All>
(P060) </wsp:ExactlyOne>
(P061) </wsp:Policy>
(P062) <wsp:Policy
wsu:Id="WSS10UsernameForCertificate_output_policy">
(P063) <wsp:ExactlyOne>
(P064) <wsp:All>
(P065) <sp:SignedParts>
(P066) <sp:Body/>
(P067) </sp:SignedParts>
(P068) </wsp:All>
(P069) </wsp:ExactlyOne>
(P070) </wsp:Policy>
Lines (P002) – (P035) contain the AsymmetricBinding
assertion which indicates that the recipient’s token must be used for both
message signature and encryption.
Lines (P004) – (P012) contain the InitiatorEncryptionToken
assertion. Within that assertion lines (P006) – (P010) indicate that the
initiator token must be an X.509 token. Line (P008) dictates the X.509 token
must be an X.509v3 security token as described in the WS-Security 1.0 X.509
Token Profile, however as stated on line (P006) it must not be included in any
message.
Lines (P013) – (P021) contain the RecipientSignatureToken
assertion. Within that assertion lines (P015) – (P019) dictate the recipient
token must also be an X.509 token as described in the WS-Security 1.0 X.509
Token Profile for message signature, however as stated on line (P017) it must
not be included in any message.
Line (P032) requires the inclusion of a timestamp.
Line (P035) OnlySignEntireHeadersAndBody
assertion will only apply to the response message, as there is no signature
token defined for the Initiator.
Lines (P036) – (P041) contain some WS-Security 1.0 related
interoperability requirements, specifically support for key identifier, and
issuer serial number.
Lines (P042) – (P051) contain an EncryptedSupportingTokens
assertion which identifies the inclusion of an additional token which must be
included in the message and encrypted. Lines (P044) – (P049) indicate that the
supporting token must be a UsernameToken and must be included in all messages
to the recipient. Line (P046) dictates the UsernameToken must be hash into
digest format, instead of clear text password. Line (P047) dictates the
UsernameToken must conform to the WS-Security 1.0 UsernameToken Profile.
Lines (P053) – (P061) contain a policy that is attached to
the input message. Lines (P056) – (P058) require the body of the input message
must be encrypted.
Lines (P062) – (P070) contain a policy that is attached to
the output message. Lines (P065) – (P068) require the body of the output
message must be signed.
An example of a request message that conforms to the above
stated policy is as follows.
(M001) <?xml version="1.0"
encoding="utf-8" ?>
(M002)
<soapenv:Envelope
xmlns:soapenv="..."
xmlns:xenc="..." . . . >
(M003)
<soapenv:Header>
(M004)
<wsse:Security
xmlns:wsse="..." xmlns:wsu="..." xmlns:ds="..."
soapenv:mustUnderstand="1"
>
(M005)
<xenc:EncryptedKey>
(M006)
<xenc:EncryptionMethod
Algorithm=". . .#rsa-oaep-mgf1p">
(M007)
<ds:DigestMethod
Algorithm=". . .#sha1" />
(M008)
</xenc:EncryptionMethod>
(M009)
<ds:KeyInfo>
(M010)
<wsse:SecurityTokenReference >
(M011)
<wsse:KeyIdentifier
EncodingType="...#Base64Binary"
(M012)
ValueType="...#X509SubjectKeyIdentifier">CuJ.
. .=</wsse:KeyIdentifier>
(M013)
</wsse:SecurityTokenReference>
(M014)
</ds:KeyInfo>
(M015)
<xenc:CipherData>
(M016)
<xenc:CipherValue>dbj...=</xenc:CipherValue>
(M017)
</xenc:CipherData>
(M018)
<xenc:ReferenceList>
(M019)
<xenc:DataReference
URI="#encBody"/>
(M020)
<xenc:DataReference
URI="#encUnt"/>
(M021)
</xenc:ReferenceList>
(M022)
</xenc:EncryptedKey>
(M023)
<xenc:EncryptedData
Id="encUnt" Type="...#Element"
MimeType="text/xml" Encoding="UTF-8" >
(M024)
<xenc:EncryptionMethod
Algorithm="...#aes256-cbc"/>
(M025)
<xenc:CipherData>
(M026)
<xenc:CipherValue>KZf...=</xenc:CipherValue>
(M027)
</xenc:CipherData>
(M028)
</xenc:EncryptedData>
(M029)
<wsu:Timestamp >
(M030)
<wsu:Created>2007-03-28T18:42:03Z</wsu:Created>
(M031)
</wsu:Timestamp>
(M032)
</wsse:Security>
(M033)
</soapenv:Header>
(M034)
<soapenv:Body >
(M035)
<xenc:EncryptedData
Id="encBody" Type="...#Content"
MimeType="text/xml" Encoding="UTF-8" >
(M036)
<xenc:EncryptionMethod
Algorithm="...#aes256-cbc"/>
(M037)
<xenc:CipherData>
(M038)
<xenc:CipherValue>a/9...B</xenc:CipherValue>
(M039)
</xenc:CipherData>
(M040)
</xenc:EncryptedData>
(M041)
</soapenv:Body>
(M042)
</soapenv:Envelope>
Line (M020) is an encryption data reference that references
the encrypted UsernameToken on lines (M023) – (M028) which was required to be
included by the EncryptedSupportingTokens assertion. Lines (M009) – (M014) hold
a KeyIdentifier of the recipient’s token used to encrypt the UsernameToken as
required by the AsymmetricBinding assertion. Because the InitiatorEncryptionAssertion
disallowed the token from being inserted into the message, a KeyIdentifier is
used instead of a reference to an included token.
Line (M019) is an encryption data reference that references
the encrypted body of the message on lines (M035) – (M040). The encryption was
required by the EncryptedParts assertion of the input message policy. It also
uses the recipient token as identified by the KeyIdentifier.
Lines (M029) – (M031) contain a timestamp for the message as
required by the IncludeTimestamp assertion.
Because the username token was encrypted its content prior
to encryption is included below to better illustrate the reference.
(M043)
<wsse:UsernameToken wsu:Id="usernameToken">
(M044)
<wsse:Username>Chris</wsse:Username>
(M045)
<wsse:Password
Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">oY...=</wsse:Password>
(M046)
<wsse:Nonce EncodingType="...#Base64Binary">pN...=</wsse:Nonce>
(M047)
<wsu:Created>2007-03-28T18:42:03Z</wsu:Created>
(M048)
</wsse:UsernameToken>
Line (M046) contains the Nonce element and Line (M047)
contains a timestamp. It is recommended that these two elements should also be
included in the PasswordText case for better security [WSS10‑USERNAME].
This scenario is based on the “Examples of Secure Web Service
Message Exchange Document” [WS‑SECURE-INTEROP].
The use case here
is the following: the Initiator generates a symmetric key; the symmetric key is
encrypted using the Recipient’s certificate and placed in an encrypted key
element. The UsernameToken identifying the Requestor and message body are
signed using the symmetric key. The body and UsernameToken are also encrypted.
The Authority for this request is generally the Subject of the Initiator’s X509
certificate.
We can use the
symmetric security binding [WSSP] with X509token as the protection token to
illustrate this case. If derived keys are to be used, then the derived keys
property of X509Token should be set.
The policy is as
follows:
(P001) <wsp:Policy
wsu:Id="WSS11UsernameWithCertificates_policy">
(P002) <wsp:ExactlyOne>
(P003) <wsp:All>
(P004) <sp:SymmetricBinding>
(P005) <wsp:Policy>
(P006) <sp:ProtectionToken>
(P007) <wsp:Policy>
(P008) <sp:X509Token
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never”>
(P009) <wsp:Policy>
(P010) <sp:RequireThumbprintReference/>
(P011) <sp:WssX509V3Token11/>
(P012) </wsp:Policy>
(P013) </sp:X509Token>
(P014) </wsp:Policy>
(P015) </sp:ProtectionToken>
(P016) <sp:AlgorithmSuite>
(P017) <wsp:Policy>
(P018) <sp:Basic256/>
(P019) </wsp:Policy>
(P020) </sp:AlgorithmSuite>
(P021) <sp:Layout>
(P022) <wsp:Policy>
(P023) <sp:Strict/>
(P024) </wsp:Policy>
(P025) </sp:Layout>
(P026) <sp:IncludeTimestamp/>
(P027) <sp:OnlySignEntireHeadersAndBody/>
(P028) </wsp:Policy>
(P029) </sp:SymmetricBinding>
(P030) <sp:SignedEncryptedSupportingTokens>
(P031) <wsp:Policy>
(P032) <sp:UsernameToken
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
(P033) <wsp:Policy>
(P034) <sp:WssUsernameToken11/>
(P035) </wsp:Policy>
(P036) </sp:UsernameToken>
(P037) </wsp:Policy>
(P038) </sp:SignedEncryptedSupportingTokens>
(P039) <sp:Wss11>
(P040) <wsp:Policy>
(P041) <sp:MustSupportRefKeyIdentifier/>
(P042) <sp:MustSupportRefIssuerSerial/>
(P043) <sp:MustSupportRefThumbprint/>
(P044) <sp:MustSupportRefEncryptedKey/>
(P045) </wsp:Policy>
(P046) </sp:Wss11>
(P047) </wsp:All>
(P048) </wsp:ExactlyOne>
(P049) </wsp:Policy>
(P050) <wsp:Policy
wsu:Id="UsernameForCertificates_input_policy">
(P051) <wsp:ExactlyOne>
(P052) <wsp:All>
(P053) <sp:SignedParts>
(P054) <sp:Body/>
(P055) </sp:SignedParts>
(P056) <sp:EncryptedParts>
(P057) <sp:Body/>
(P058) </sp:EncryptedParts>
(P059) </wsp:All>
(P060) </wsp:ExactlyOne>
(P061) </wsp:Policy>
(P062) <wsp:Policy
wsu:Id="UsernameForCertificate_output_policy">
(P063) <wsp:ExactlyOne>
(P064) <wsp:All>
(P065) <sp:SignedParts>
(P066) <sp:Body/>
(P067) </sp:SignedParts>
(P068) <sp:EncryptedParts>
(P069) <sp:Body/>
(P070) </sp:EncryptedParts>
(P071) </wsp:All>
(P072) </wsp:ExactlyOne>
(P073) </wsp:Policy>
Lines (P004) –
(P297) contain a SymmetricBinding assertion which indicates the use of one
token to both sign and encrypt a message.
Lines (P006) –
(P015) contain the ProtectionToken assertion. Within that assertion lines
(P008) – (P012) indicate that the protection token must be an X.509 token that
must never be included in any messages in the message exchange. Line (P010)
dictates the X.509 token must be an X.509v3 security token as described in the
WS-Security 1.1 X.509 Token Profile. Line (P011) dicates a thumbprint reference
must be used to identify the token in any message.
Line (P026)
requires the inclusion of a timestamp.
Lines (P030) –
(P038) contain a SignedEncryptedSupportingTokens assertion which identifies the
inclusion of an additional token which must be included in the message
signature and encrypted. Lines (P032) – (P036) indicate that the supporting
token must be a UsernameToken and must be included in all messages to the
recipient. Line (P034) dictates the UsernameToken must conform to the
WS-Security 1.1 UsernameToken Profile.
Lines (P040) –
(P046) contain some WS-Security 1.1 related interoperability requirements,
specifically support for key identifier, issuer serial number, thumbprint, and
encrypted key references.
Lines (P050) –
(P061) contain a policy that is attached to the input message. Lines (P053) –
(P055) require that the body of the input message must be signed. Lines (P056)
– (P058) require the body of the input message must be encrypted.
Lines (P062) –
(P073) contain a policy that is attached to the output message. Lines (P065) –
(P067) require that the body of the output message must be signed. Lines (P068)
– (P070) require the body of the output message must be encrypted.
An example of an
input message that conforms to the above stated policy is as follows.
(M001) <?xml
version="1.0" encoding="utf-8" ?>
(M002) <soap:Envelope
xmlns:soap="..." xmlns:xenc="..."
xmlns:ds="...">
(M003) <soap:Header>
(M004) <wsse:Security soap:mustUnderstand=“1” xmlns:wsse="..."
xmlns:wsu="...">
(M005) <xenc:EncryptedKey wsu:Id=”EK”>
(M006)
<xenc:EncryptionMethod
Algorithm=”http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p”/>
(M007)
<ds:KeyInfo>
(M008)
<wsse:SecurityTokenReference>
(M009)
<wsse:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#ThumbPrintSHA1">
(M010) LKiQ/CmFrJDJqCLFcjlhIsmZ/+0=
(M011) </wsse:KeyIdentifier>
(M012) </wsse:SecurityTokenReference>
(M013)
</ds:KeyInfo>
(M014) </xenc:EncryptedKey>
(M015) <xenc:ReferenceList>
(M016) <xenc:DataReference
URI=”#encUT”/>
(M017) <xenc:DataReference
URI=”#encBody”/>
(M018) </xenc:ReferenceList>
(M019) <wsu:Timestamp
wsu:Id="T0">
(M020) <wsu:Created>2001-09-13T08:42:00Z</wsu:Created>
(M021) </wsu:Timestamp>
(M022) <xenc:EncryptedData
wsu:Id="encUT">
(M023)
<xenc:EncryptionMethod
Algorithm=”http://www.w3.org/2001/04/xmlenc#aes256-cbc”/>
(M024) <ds:KeyInfo>
(M025) <wsse:SecurityTokenReference>
(M026) <wsse:Reference URI=”#EK”/>
(M027) </wsse:SecurityTokenReference>
(M028) </ds:KeyInfo>
(M029) <xenc:CipherData>
(M030) <xenc:CipherValue>...</xenc:CipherValue>
(M031) </xenc:CipherData>
(M032) </xenc:EncryptedData>
(M033) <ds:Signature>
(M034) <ds:SignedInfo>…
(M035) <ds:Reference
URI="#T0">…</ds:Reference>
(M036) <ds:Reference
URI="#usernameToken">…</ds:Reference>
(M037) <ds:Reference
URI="#body">…</ds:Reference>
(M038) </ds:SignedInfo>
(M039) <ds:SignatureValue>HFLP…</ds:SignatureValue>
(M040) <ds:KeyInfo>
(M041) <wsse:SecurityTokenReference>
(M042) <wsse:Reference URI=”#EK”/>
(M043) </wsse:SecurityTokenReference>
(M044) </ds:KeyInfo>
(M045) </ds:Signature>
(M046) </wsse:Security>
(M047) </soap:Header>
(M048) <soap:Body wsu:Id="body">
(M049) <xenc:EncryptedData
wsu:Id="encBody">
(M050) <xenc:EncryptionMethod Algorithm=”http://www.w3.org/2001/04/xmlenc#aes256-cbc”/>
(M051) <ds:KeyInfo>
(M052) <wsse:SecurityTokenReference>
(M053) <wsse:Reference
URI=”#EK”/>
(M054) </wsse:SecurityTokenReference>
(M055) </ds:KeyInfo>
(M056) <xenc:CipherData>
(M057) <xenc:CipherValue>...</xenc:CipherValue>
(M058) </xenc:CipherData>
(M059) </xenc:EncryptedData>
(M060) </soap:Body>
(M061) </soap:Envelope>
Lines (M005) –
(M014) contain the encrypted symmetric key as required by the use of the SymmetricBinding
assertion staring on line (P004) with an X509Token ProtectionToken assertion.
Line (M006) references the KwRsaOaep Asymmetric Key Wrap algorithm dictated by
the Basic 256 Algorithm Suite assertion on line (P018). Lines (M009) – (M011)
hold a KeyIdentifier of the protection token used to encrypt the symmetric key
as required by the SymmetricBinding assertion. Because the ProtectionToken
assertion disallowed the token from being inserted into the message and instead
required a thumbprint reference, a thumbprint reference is included to identify
the token.
Line (M016) is an
encryption data reference that references the encrypted supporting
UsernameToken on lines (M022) – (M032). The encryption was required by the
SignedEncryptedSupportingTokens assertion on line (P038). Line (M023)
references the Aes256 Encryption algorithm dictated by the Basic 256 Algorithm
Suite assertion on line (P018). The encrypted symmetric key is used to encrypt
the UsernameToken as referenced on line (M026).
Line (M017) is an
encryption data reference that references the encrypted body of the message on
lines (M049) – (M059). The encryption was required by the EncryptedParts
assertion of the input message policy. The encrypted symmetric key is used to
encrypt the UsernameToken as referenced on line (M053).
Lines (M019) –
(M021) contain a timestamp for the message as required by the IncludeTimestamp
assertion.
Lines (M033) –
(M045) contain the message signature.
Line (M035)
indicates the message timestamp is included in the signature as required by the
IncludeTimestamp assertion definition.
Line (M036)
indicates the supporting UsernameToken is included in the signature as required
by the SignedSupportingTokens assertion. Because the token was encrypted its
content prior to encryption is included below to better illustrate the
reference.
(M062)
<wsse:UsernameToken wsu:Id="usernameToken">
(M063)
<wsse:Username>Chris</wsse:Username>
(M064)
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText
">sirhC</wsse:Password>
(M065)
</wsse:UsernameToken>
Line (M037)
indicates the message body is included in the signature as required by the
SignedParts assertion of the input message policy.
Line (M042)
references the encrypted symmetric key for signing as dictated by the
SymmetricBinding assertion.
This use-case corresponds to the situation
where both parties have X.509v3 certificates (and public-private key pairs).
The requestor identifies itself to the service. The message exchange is
integrity protected and encrypted.
This modeled by use of an asymmetric
security binding assertion.
The message level policies in this and
subsequent sections cover a different scope of the web service definition than
the security binding level policy and so appear as separate policies and are
attached at WSDL Message Policy Subject. These are shown below as input and
output policies. Thus, we need a set of
coordinated policies one with endpoint subject and two with message subjects to
achieve this use case.
The policies are as follows:
(P001) <wsp:Policy
wsu:Id="wss10_anonymous_with_cert_policy" >
(P002) <wsp:ExactlyOne>
(P003) <wsp:All>
(P004) <sp:AsymmetricBinding>
(P005) <wsp:Policy>
(P006) <sp:InitiatorToken>
(P007) <wsp:Policy>
(P008) <sp:X509Token
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
(P009) <wsp:Policy>
(P010) <sp:WssX509V3Token10/>
(P011) </wsp:Policy>
(P012) </sp:X509Token>
(P013) </wsp:Policy>
(P014) </sp:InitiatorToken>
(P015) <sp:RecipientToken>
(P016) <wsp:Policy>
(P017) <sp:X509Token
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never">
(P018) <wsp:Policy>
(P019) <sp:WssX509V3Token10/>
(P020) </wsp:Policy>
(P021) </sp:X509Token>
(P022) </wsp:Policy>
(P023) </sp:RecipientToken>
(P024) <sp:AlgorithmSuite>
(P025) <wsp:Policy>
(P026) <sp:Basic256/>
(P027) </wsp:Policy>
(P028) </sp:AlgorithmSuite>
(P029) <sp:Layout>
(P030) <wsp:Policy>
(P031) <sp:Strict/>
(P032) </wsp:Policy>
(P033) </sp:Layout>
(P034) <sp:IncludeTimestamp/>
(P035) <sp:OnlySignEntireHeadersAndBody/>
(P036) </wsp:Policy>
(P037) </sp:AsymmetricBinding>
(P038) <sp:Wss10>
(P039) <wsp:Policy>
(P040) <sp:MustSupportRefKeyIdentifier/>
(P041) </wsp:Policy>
(P042) </sp:Wss10>
(P043) </wsp:All>
(P044) </wsp:ExactlyOne>
(P045) </wsp:Policy>
(P046) <wsp:Policy
wsu:Id="WSS10Anonymous_with_Certificates_input_policy">
(P047) <wsp:ExactlyOne>
(P048) <wsp:All>
(P049) <sp:SignedParts>
(P050) <sp:Body/>
(P051) </sp:SignedParts>
(P052) <sp:EncryptedParts>
(P053) <sp:Body/>
(P054) </sp:EncryptedParts>
(P055) </wsp:All>
(P056) </wsp:ExactlyOne>
(P057) </wsp:Policy>
(P058) <wsp:Policy
wsu:Id="WSS10anonymous_with_certs_output_policy">
(P059) <wsp:ExactlyOne>
(P060) <wsp:All>
(P061) <sp:SignedParts>
(P062) <sp:Body/>
(P063) </sp:SignedParts>
(P064) <sp:EncryptedParts>
(P065) <sp:Body/>
(P066) </sp:EncryptedParts>
(P067) </wsp:All>
(P068) </wsp:ExactlyOne>
(P069) </wsp:Policy>
Lines (P004) – (P037) contain the
AsymmetricBinding assertion which indicates that the initiator’s token must be
used for the message signature and the recipient’s token must be used for
message encryption.
Lines (P006) – (P014) contain the
InitiatorToken assertion. Within that assertion lines (P008) – (P012) indicate
that the initiator token must be an X.509 token that must be included with all
messages sent to the recipient. Line (P010) dictates the X.509 token must be an
X.509v3 security token as described in the WS-Security 1.0 X.509 Token Profile.
Lines (P015) – (P023) contain the
RecipientToken assertion. Within that assertion lines (P017) – (P021) dictate
the recipient token must also be an X.509 token as described in the WS-Security
1.0 X.509 Token Profile, however as stated on line (P017) it must not be
included in any message. Instead, according to the MustSupportKeyRefIdentitier
assertion on line (P040) a KeyIdentifier must be used to identify the token in
any messages where the token is used.
Line (P034) requires the inclusion of a
timestamp.
Lines (P046) – (P057) contain a policy that
is attached to the input message. Lines (P049) – (P051) require that the body
of the input message must be signed. Lines (P052) – (P054) require the body of
the input message must be encrypted.
Lines (P058) – (P069) contain a policy that
is attached to the output message. Lines (P061) – (P063) require that the body
of the output message must be signed. Lines (P064) – (P066) require the body of
the output message must be encrypted.
An example of an input message that conforms
to the above stated policy is as follows.
(M001) <?xml
version="1.0" encoding="utf-8" ?>
(M002) <soap:Envelope
xmlns:soap="..." xmlns:xenc="..."
xmlns:ds="...">
(M003) <soap:Header>
(M004) <wsse:Security soap:mustUnderstand=“1”
xmlns:wsse="..." xmlns:wsu="...">
(M005) <xenc:EncryptedKey >
(M006) <xenc:EncryptionMethod
Algorithm="...#rsa-oaep-mgf1p">
(M007) <ds:DigestMethod Algorithm="...#sha1"/>
(M008) </xenc:EncryptionMethod>
(M009) <ds:KeyInfo>
(M010) <wsse:SecurityTokenReference >
(M011) <wsse:KeyIdentifier
EncodingType="...#Base64Binary" ValueType="...#X509SubjectKeyIdentifier">
(M012) MIGfMa0GCSq…
(M013) </wsse:KeyIdentifier>
(M014) </ds:KeyInfo>
(M015) <xenc:CipherData>
(M016) <xenc:CipherValue>Hyx...=</xenc:CipherValue>
(M017) </xenc:CipherData>
(M018) <xenc:ReferenceList>
(M019) <xenc:DataReference
URI="#encBody"/>
(M020) </xenc:ReferenceList>
(M021) </xenc:EncryptedKey>
(M022) <wsu:Timestamp
wsu:Id="T0">
(M023) <wsu:Created>2001-09-13T08:42:00Z</wsu:Created>
(M024) </wsu:Timestamp>
(M025) <wsse:BinarySecurityToken wsu:Id="binaryToken"
ValueType="…#X509v3" EncodingType="…#Base64Binary">
(M026) MIIEZzCCA9CgAwIBAgIQEmtJZc0…
(M027) </wsse:BinarySecurityToken>
(M028) <ds:Signature>
(M029) <ds:SignedInfo>…
(M030) <ds:Reference
URI="#T0">…</ds:Reference>
(M031) <ds:Reference
URI="#body">…</ds:Reference>
(M032) </ds:SignedInfo>
(M033) <ds:SignatureValue>HFLP…</ds:SignatureValue>
(M034) <ds:KeyInfo>
(M035) <wsse:SecurityTokenReference>
(M036) <wsse:Reference
URI="#binaryToken"/>
(M037) </wsse:SecurityTokenReference>
(M038) </ds:KeyInfo>
(M039) </ds:Signature>
(M040) </wsse:Security>
(M041) </soap:Header>
(M042) <soap:Body wsu:Id="body">
(M043) <xenc:EncryptedData
wsu:Id="encBody">
(M044) <xenc:CipherData>
(M045) <xenc:CipherValue>...</xenc:CipherValue>
(M046) </xenc:CipherData>
(M047) </xenc:EncryptedData>
(M048) </soap:Body>
(M049) </soap:Envelope>
Line (M019) is an encryption data reference
that references the encrypted body of the message on lines (M043) – (M047). The
encryption was required by the EncryptedParts assertion of the input message
policy. Lines (M011) – (M013) hold a KeyIdentifier of the recipient’s token used
to encrypt the body as required by the AsymmetricBinding assertion. Because the
RecipientToken assertion disallowed the token from being inserted into the
message, a KeyIdentifier is used instead of a reference to an included token.
Lines (M022) – (M024) contain a timestamp
for the message as required by the IncludeTimestamp assertion.
Lines (M025) – (M027) contain the
BinarySecurityToken holding the X.509v3 certificate of the initiator as
required by the InitiatorToken assertion.
Lines (M028) – (M039) contain the message
signature.
Line (M030) indicates the message timestamp
is included in the signature as required by the IncludeTimestamp assertion
definition.
Line (M031) indicates the message body is
included in the signature as required by the SignedParts assertion of the input
message policy.
Note that the initiator’s
BinarySecurityToken is not included in the message signature as it was not
required by policy.
Lines (M035) – (M037) references the
initiator’s BinarySecurityToken included in the message for identifying the key
used for signing as dictated by the AsymmetricBinding assertion.
This scenario is
based on WSS Interop, Scenario 3, Web Services Security: Interop 1,
Draft 06, Editor, Hal Lockhart, BEA Systems
This use case
corresponds to the situation where both parties have X.509v3 certificates (and
public-private key pairs). The requestor wishes to identify itself to the
service using its X.509 credential (strong authentication). The message
exchange needs to be integrity protected and encrypted as well. The difference
from previous use case is that the X509 token inserted by the client is
included in the message signature (see <ProtectTokens />).
The policy is as
follows:
(P001) <wsp:Policy
wsu:Id="wss10_anonymous_with_cert_policy" >
(P002) <wsp:ExactlyOne>
(P003) <wsp:All>
(P004) <sp:AsymmetricBinding>
(P005) <wsp:Policy>
(P006) <sp:InitiatorToken>
(P007) <wsp:Policy>
(P008) <sp:X509Token
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
(P009) <wsp:Policy>
(P010) <sp:WssX509V3Token10/>
(P011) </wsp:Policy>
(P012) </sp:X509Token>
(P013) </wsp:Policy>
(P014) </sp:InitiatorToken>
(P015) <sp:RecipientToken>
(P016) <wsp:Policy>
(P017) <sp:X509Token
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never">
(P018) <wsp:Policy>
(P019) <sp:WssX509V3Token10/>
(P020) </wsp:Policy>
(P021) </sp:X509Token>
(P022) </wsp:Policy>
(P023) </sp:RecipientToken>
(P024) <sp:AlgorithmSuite>
(P025) <wsp:Policy>
(P026) <sp:Basic256/>
(P027) </wsp:Policy>
(P028) </sp:AlgorithmSuite>
(P029) <sp:Layout>
(P030) <wsp:Policy>
(P031) <sp:Strict/>
(P032) </wsp:Policy>
(P033) </sp:Layout>
(P034) <sp:IncludeTimestamp/>
(P035) <sp:ProtectTokens />
(P036) <sp:OnlySignEntireHeadersAndBody/>
(P037) </wsp:Policy>
(P038) </sp:AsymmetricBinding>
(P039) <sp:Wss10>
(P040) <wsp:Policy>
(P041) <sp:MustSupportRefKeyIdentifier/>
(P042) </wsp:Policy>
(P043) </sp:Wss10>
(P044) </wsp:All>
(P045) </wsp:ExactlyOne>
(P046) </wsp:Policy>
(P047) <wsp:Policy wsu:Id="WSS10Anonymous
with Certificates_input_policy">
(P048) <wsp:ExactlyOne>
(P049) <wsp:All>
(P050) <sp:SignedParts>
(P051) <sp:Body/>
(P052) </sp:SignedParts>
(P053) <sp:EncryptedParts>
(P054) <sp:Body/>
(P055) </sp:EncryptedParts>
(P056) </wsp:All>
(P057) </wsp:ExactlyOne>
(P058) </wsp:Policy>
(P059) <wsp:Policy
wsu:Id="WSS10anonymous with certs_output_policy">
(P060) <wsp:ExactlyOne>
(P061) <wsp:All>
(P062) <sp:SignedParts>
(P063) <sp:Body/>
(P064) </sp:SignedParts>
(P065) <sp:EncryptedParts>
(P066) <sp:Body/>
(P067) </sp:EncryptedParts>
(P068) </wsp:All>
(P069) </wsp:ExactlyOne>
(P070) </wsp:Policy>
Lines (P004) –
(P038) contain the AsymmetricBinding assertion which indicates that the
initiator’s token must be used for the message signature and the recipient’s
token must be used for message encryption.
Lines (P006) –
(P014) contain the InitiatorToken assertion. Within that assertion lines (P008)
– (P012) indicate that the initiator token must be an X.509 token that must be
included with all messages sent to the recipient. Line (P010) dictates the
X.509 token must be an X.509v3 security token as described in the WS-Security
1.0 X.509 Token Profile.
Lines (P015) –
(P023) contain the RecipientToken assertion. Within that assertion lines (P017)
– (P021) dictate the recipient token must also be an X.509 token as described
in the WS-Security 1.0 X.509 Token Profile, however as stated on line (P017) it
must not be included in any message. Instead, according to the
MustSupportKeyRefIdentitier assertion on line (P040) a KeyIdentifier must be
used to identify the token in any messages where the token is used.
Line (P034)
requires the inclusion of a timestamp.
Line (P035)
requires token protection (ProtectTokens) which dictates that the signature
must cover the token used to generate that signature.
Lines (P047) –
(P058) contain a policy that is attached to the input message. Lines (P050) –
(P052) require that the body of the input message must be signed. Lines (P053)
– (P055) require the body of the input message must be encrypted.
Lines (P059) –
(P070) contain a policy that is attached to the output message. Lines (P062) –
(P064) require that the body of the output message must be signed. Lines (P064)
– (P066) require the body of the output message must be encrypted.
An example of an
input message that conforms to the above stated policy is as follows.
(M001) <?xml
version="1.0" encoding="utf-8" ?>
(M002) <soapenv:Envelope xmlns:soapenv="..."
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:wsu="..." xmlns:xenc="..." ...>
(M003) <soapenv:Header>
(M004) <wsse:Security
xmlns:wsse="..." xmlns:ds="..."
soapenv:mustUnderstand="1">
(M005) <xenc:EncryptedKey >
(M006) <xenc:EncryptionMethod
Algorithm="...#rsa-oaep-mgf1p">
(M007) <ds:DigestMethod
Algorithm="...#sha1"/>
(M008) </xenc:EncryptionMethod>
(M009) <ds:KeyInfo>
(M010) <wsse:SecurityTokenReference >
(M011) <wsse:KeyIdentifier
EncodingType="...#Base64Binary"
ValueType="...#X509SubjectKeyIdentifier">CuJd...=</wsse:KeyIdentifier>
(M012) </wsse:SecurityTokenReference>
(M013) </ds:KeyInfo>
(M014) <xenc:CipherData>
(M015) <xenc:CipherValue>Hyx...=</xenc:CipherValue>
(M016) </xenc:CipherData>
(M017) <xenc:ReferenceList>
(M018) <xenc:DataReference
URI="#encBody"/>
(M019) </xenc:ReferenceList>
(M020) </xenc:EncryptedKey>
(M021) <wsu:Timestamp
wsu:Id="Timestamp" >
(M022) <wsu:Created>2007-03-26T16:53:39Z</wsu:Created>
(M023) </wsu:Timestamp>
(M024) <wsse:BinarySecurityToken
wsu:Id="bst" ValueType="...#X509v3"
EncodingType="...#Base64Binary">MIID...=</wsse:BinarySecurityToken>
(M025) <ds:Signature>
(M026) <ds:SignedInfo>
(M027) <ds:CanonicalizationMethod
Algorithm=".../xml-exc-c14n#"/>
(M028) <ds:SignatureMethod
Algorithm="...#rsa-sha1"/>
(M029) <ds:Reference
URI="#Timestamp">
(M030) <ds:Transforms>...
</ds:Transforms>
(M031) <ds:DigestMethod Algorithm="...#sha1"/>
(M032) <ds:DigestValue>+g0I...=</ds:DigestValue>
(M033) </ds:Reference>
(M034) <ds:Reference
URI="#Body">...</ds:Reference>
(M035) <ds:Reference
URI="#bst">..</ds:Reference>
(M036) </ds:SignedInfo>
(M037) <ds:SignatureValue>RRT...=</ds:SignatureValue>
(M038) <ds:KeyInfo>
(M039) <wsse:SecurityTokenReference >
(M040) <wsse:KeyIdentifier
EncodingType="...#Base64Binary"
ValueType="...#X509SubjectKeyIdentifier">Xeg5...=</wsse:KeyIdentifier>
(M041) </wsse:SecurityTokenReference>
(M042) </ds:KeyInfo>
(M043) </ds:Signature>
(M044) </wsse:Security>
(M045) </soapenv:Header>
(M046) <soapenv:Body wsu:Id="Body" >
(M047) <xenc:EncryptedData
Id="encBody" Type="...#Content"
(M048) MimeType="text/xml"
Encoding="UTF-8" >
(M049) <xenc:EncryptionMethod
Algorithm="...#aes256-cbc"/>
(M050) <xenc:CipherData>
(M051) <xenc:CipherValue>W84fn...1</xenc:CipherValue>
(M052) </xenc:CipherData>
(M053) </xenc:EncryptedData>
(M054) </soapenv:Body>
(M055) </soapenv:Envelope>
Line (M018) is an
encryption data reference that references the encrypted body of the message on
lines (M047) – (M048). The encryption was required by the EncryptedParts
assertion of the input message policy. Lines (M009) – (M013) hold a
KeyIdentifier of the recipient’s token used to encrypt the body as required by
the AsymmetricBinding assertion. Because the RecipientToken assertion
disallowed the token from being inserted into the message, a KeyIdentifier is
used instead of a reference to an included token.
Lines (M021) –
(M023) contain a timestamp for the message as required by the IncludeTimestamp
assertion.
Line (M024)
contains the BinarySecurityToken holding the X.509v3 certificate of the
initiator as required by the InitiatorToken assertion.
Lines (M025) –
(M043) contain the message signature.
Line (M029)
indicates the message timestamp is included in the signature as required by the
IncludeTimestamp assertion definition.
Line (M034)
indicates the message body is included in the signature as required by the
SignedParts assertion of the input message policy.
Line (M035)
indicates the BinarySecurityToken on Line (M024) is included in the signature
as required by the ProtectTokens
assertion of the AsymmetricBinding assertion policy.
Note that the
recipient’s token is not explicitly included in the security header, as it is
required not to be by policy (P017). Instead a KeyIdentifier, line (M011) is
used to identify the recipient’s that should be used to decrypt the
EncryptedData.
Lines (M039) –
(M041) reference the initiator’s BinarySecurityToken on line (M034), which is
included in the message to contain the key used for verifying as dictated by
the AsymmetricBinding assertion.
This scenario is
based on WSS Interop, Scenario 4, Web Services Security: Interop 2.
A common variation
on the previous example is where X.509 Certificates are still used for
authentication, but a mutually agreed upon symmetric key is used for
encryption.
In this use case
the policy is the same except that the InitiatorToken and RecipientToken are
now each just SignatureTokens.
A second variation
in this use case is that the mutually agreed upon symmetric encryption key is
characterized as an “IssuedToken” with a mutually agreed upon URI used to
identify the out of band (not included in the message) token, which is included
in a SupportingTokens element.
The policy is as
follows:
(P001) <wsp:Policy
wsu:Id="wss10_anonymous_with_cert_policy" >
(P002) <wsp:ExactlyOne>
(P003) <wsp:All>
(P004) <sp:AsymmetricBinding>
(P005) <wsp:Policy>
(P006) <sp:InitiatorSignatureToken>
(P007) <wsp:Policy>
(P008) <sp:X509Token
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
(P009) <wsp:Policy>
(P010) <sp:WssX509V3Token10/>
(P011) </wsp:Policy>
(P012) </sp:X509Token>
(P013) </wsp:Policy>
(P014) </sp:InitiatorSignatureToken>
(P015) <sp:RecipientSignatureToken>
(P016) <wsp:Policy>
(P017) <sp:X509Token
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never">
(P018) <wsp:Policy>
(P019) <sp:WssX509V3Token10/>
(P020) </wsp:Policy>
(P021) </sp:X509Token>
(P022) </wsp:Policy>
(P023) </sp:RecipientSignatureToken>
(P024) <sp:AlgorithmSuite>
(P025) <wsp:Policy>
(P026) <sp:Basic256/>
(P027) </wsp:Policy>
(P028) </sp:AlgorithmSuite>
(P029) <sp:Layout>
(P030) <wsp:Policy>
(P031) <sp:Strict/>
(P032) </wsp:Policy>
(P033) </sp:Layout>
(P034) <sp:IncludeTimestamp/>
(P035) <sp:ProtectTokens />
(P036) <sp:OnlySignEntireHeadersAndBody/>
(P037) </wsp:Policy>
(P038) </sp:AsymmetricBinding>
(P039) <sp:SupportingTokens>
(P040) <wsp:Policy>
(P041) <sp:IssuedToken>
(P042) <sp:Issuer>SomeMutuallyAgreedURI</sp:Issuer>
(P043) <sp:RequireExternalReference/>
(P044) </sp:IssuedToken>
(P045) <sp:EncryptedParts>
(P046) <sp:Body/>
(P047) </sp:EncryptedParts>
(P048) </wsp:Policy>
(P049) </sp:SupportingTokens>
(P050) <sp:Wss10>
(P051) <wsp:Policy>
(P052) <sp:MustSupportRefKeyIdentifier/>
(P053) </wsp:Policy>
(P054) </sp:Wss10>
(P055) </wsp:All>
(P056) </wsp:ExactlyOne>
(P057) </wsp:Policy>
(P058) <wsp:Policy wsu:Id="WSS10Anonymous
with Certificates_input_policy">
(P059) <wsp:ExactlyOne>
(P060) <wsp:All>
(P061) <sp:SignedParts>
(P062) <sp:Body/>
(P063) </sp:SignedParts>
(P064) <sp:EncryptedParts>
(P065) <sp:Body/>
(P066) </sp:EncryptedParts>
(P067) </wsp:All>
(P068) </wsp:ExactlyOne>
(P069) </wsp:Policy>
(P070) <wsp:Policy
wsu:Id="WSS10anonymous with certs_output_policy">
(P071) <wsp:ExactlyOne>
(P072) <wsp:All>
(P073) <sp:SignedParts>
(P074) <sp:Body/>
(P075) </sp:SignedParts>
(P076) <sp:EncryptedParts>
(P077) <sp:Body/>
(P078) </sp:EncryptedParts>
(P079) </wsp:All>
(P080) </wsp:ExactlyOne>
(P081) </wsp:Policy>
Lines (P004) –
(P038) contain the AsymmetricBindingAssertion which indicates that the
initiator’s token must be used for the message signature and the recipient’s
token must be used for message encryption.
Lines (P006) –
(P014) contain the InitiatorSignatureToken assertion. Within that assertion
lines (P008) – (P012) indicate that the initiator token must be an X.509 token
that must be included with all messages sent to the recipient. Line (P010)
dictates the X.509 token must be an X.509v3 security token as described in the
WS-Security 1.0 X.509 Token Profile. By specifying that this is an
InitiatorSignatureToken, it will only be used to sign the message and not used
for encryption.
Lines (P015) –
(P023) contain the RecipientSignatureToken assertion. Within that assertion
lines (P017) – (P021) dictate the recipient token must also be an X.509 token
as described in the WS-Security 1.0 X.509 Token Profile, however as stated on
line (P017) it must not be included in any message. Instead, according to the
MustSupportKeyRefIdentitier assertion on line (P040) a KeyIdentifier must be
used to identify the token in any messages where the token is used. By
specifying that this is an RecipientSignatureToken, it will only be used to
sign the response and not used for encryption.
Line (P034)
requires the inclusion of a timestamp.
Line (P035)
requires token protection (ProtectTokens) which dictates that the signature
must cover the token or token reference associated with the generation of that
signature.
Lines (P039) –
(P049) contain a SupportingTokens assertion that contains an IssuedToken (P041)
– (P044), which contains an Issuer element (P042) that identifies an explicit
URI (“SomeMutuallyAgreedURI”) that must be used to indicate what token will be
used. (Since the content of the IssuedToken element is specific to the Issuer,
any mechanism can be used to identify the key, and in this case the simplest
method of identifying the issuer with the explicit key has been chosen only to
illustrate one possible method, but not to recommend as opposed to any other
method.) Line (P043), RequireExternalReference indicates that the IssuedToken
requires a token that is referenced external to the message. Lines (P045) –
(P047) indicate that the token is to be used for encrypting parts of the
message, explicitly, line (P046), the Body of the message.
Lines (P058) –
(P069) contain a policy that is attached to the input message. Lines (P061) –
(P063) require that the body of the input message must be signed. Lines (P064)
– (P066) require the body of the input message must be encrypted.
Lines (P070) –
(P081) contain a policy that is attached to the output message. Lines (P073) –
(P075) require that the body of the output message must be signed. Lines (P076)
– (P078) require the body of the output message must be encrypted.
The following
example message is derived from the WSS Interop2 document.
(M001)
<?xml version="1.0"
encoding="utf-8" ?>
(M002)
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
(M003)
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
(M004)
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
(M005)
<soap:Header>
(M006)
<wsse:Security
soap:mustUnderstand="1"
(M007)
xmlns:wsse="http://schemas.xmlsoap.org/ws/2003/06/secext">
(M008)
<xenc:ReferenceList xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
(M009)
<xenc:DataReference
URI="#enc" />
(M010)
</xenc:ReferenceList>
(M011)
<wsu:Timestamp
xmlns:wsu="http://schemas.xmlsoap.org/ws/2003/06/utility"
(M012)
wsu:Id="timestamp">
(M013)
<wsu:Created>2003-03-18T19:53:13Z</wsu:Created>
(M014)
</wsu:Timestamp>
(M015)
<wsse:BinarySecurityToken
ValueType="wsse:X509v3"
(M016)
EncodingType="wsse:Base64Binary"
(M017)
xmlns:wsu="http://schemas.xmlsoap.org/ws/2003/06/utility"
(M018)
wsu:Id="myCert">MII...hk</wsse:BinarySecurityToken>
(M019)
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
(M020)
<SignedInfo>
(M021)
<CanonicalizationMethod
(M022)
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"
/>
(M023)
<SignatureMethod
(M024) Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
(M025)
<Reference
URI="#body">
(M026)
<Transforms>
(M027)
<Transform
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
(M028)
</Transforms>
(M029)
<DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
(M030)
<DigestValue>QTV...dw=</DigestValue>
(M031)
</Reference>
(M032)
<Reference URI="#myCert">
(M033)
<Transforms>
(M034)
<Transform
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
(M035)
</Transforms>
(M036)
<DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
(M037)
<DigestValue>XYZ...ab=</DigestValue>
(M038)
</Reference>
(M039)
<Reference URI="#timestamp">
(M040)
<Transforms>
(M041)
<Transform
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
(M042)
</Transforms>
(M043)
<DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
(M044)
<DigestValue>XYZ...ab=</DigestValue>
(M045)
</Reference>
(M046)
</SignedInfo>
(M047)
<SignatureValue>H+x0...gUw=</SignatureValue>
(M048)
<KeyInfo>
(M049)
<wsse:SecurityTokenReference>
(M050)
<wsse:Reference
URI="#myCert" />
(M051)
</wsse:SecurityTokenReference>
(M052)
</KeyInfo>
(M053)
</Signature>
(M054)
</wsse:Security>
(M055)
</soap:Header>
(M056)
<soap:Body wsu:Id="body"
(M057)
xmlns:wsu="http://schemas.xmlsoap.org/ws/2003/06/utility">
(M058)
<xenc:EncryptedData Id="enc"
(M059)
Type="http://www.w3.org/2001/04/xmlenc#Content"
(M060)
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
(M061)
<xenc:EncryptionMethod
(M062)
Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"
/>
(M063)
<xenc:KeyInfo>
(M064)
<xenc:KeyName>SomeMutuallyAgreedURI</xenc:Keyname>
(M065)
</xenc:KeyInfo>
(M066)
<xenc:CipherData>
(M067)
<xenc:CipherValue>AYb...Y8=</xenc:CipherValue>
(M068)
</xenc:CipherData>
(M069)
</xenc:EncryptedData>
(M070)
</soap:Body>
(M071)
</soap:Envelope>
In the above
example, the main point of attention is line (M064), where the KeyName of the
EncryptedData element is “SomeMutuallyAgreedURI”. As indicated above the specific
techniques used to identify and apply this token are totally within agreed upon
methods define by the mutual parties.
Lines (M005) –
(M055) contain the SOAP Header element, which contains the WS-Security header
(M006) – (M054).
The ReferenceList
(M008) – (M010) contains an internal reference (M009), “enc”, identifying the
EncryptedData element Id, line (M058). This EncryptedData (M058) – (M069)
inside the SOAP Body, (M056) – (M070), was required to be encrypted by the
policy (P058) – (P069) as described above.
The Timestamp
(M011) – (M014) is required by the policy line (P034).
The
BinarySecurityToken (M015) – (M018) contains the actual certificate used to
sign the request as required by the policy, (P008),
IncludeToken/AlwaysToRecipient.
The Signature (M019)
– (M053) contains a SignedInfo (M020) – (M046) that identifies the “#body”
(M025) the “#myCert” (M032), and the “#timestamp” (M039) as the elements
covered by the signature. The Reference (M032) – (M038) with URI=”#myCert” that
covers the BinarySecurityToken (M015) – (M018) was required by ProtectTokens in
the policy (P035).
The KeyInfo (M048)
– (M052) uses a SecurityTokenReference to point to the “myCert”
BinarySecurityToken.
The EncryptedData
(M058) – (M069) was described above, where it was pointed out that line (M064)
contains the external reference (“SomeMutuallyAgreedURI”) to the mutually
shared symmetric key used for encryption.
This scenario is
based on the the “Examples of Secure Web Service Message Exchange
Document” [WS‑SECURE-INTEROP]
(see also sec 2.1.4)
In this use case
the Request is signed using DerivedKeyToken1(K), then encrypted using a
DerivedKeyToken2(K) where K is ephemeral key protected for the server's
certificate. Response is signed using DKT3(K), (if needed) encrypted using
DKT4(K). The requestor does not wish to identify himself; the message exchange
is protected using derived symmetric keys. As a simpler, but less secure,
alternative, ephemeral key K (instead of derived keys) could be used for
message protection by simply omitting the sp:RequireDerivedKeys assertion.
The policy is as
follows:
(P001) <wsp:Policy
wsu:Id="WSS11_AnonymousForX509SignEncrypt_Policy">
(P002) <wsp:ExactlyOne>
(P003) <wsp:All>
(P004) <sp:SymmetricBinding>
(P005) <wsp:Policy>
(P006) <sp:ProtectionToken>
(P007) <wsp:Policy>
(P008) <sp:X509Token
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never">
(P009) <wsp:Policy>
(P010) <sp:RequireDerivedKeys/>
(P011) <sp:RequireThumbprintReference/>
(P012) <sp:WssX509V3Token11/>
(P013) </wsp:Policy>
(P014) </sp:X509Token>
(P015) </wsp:Policy>
(P016) </sp:ProtectionToken>
(P017) <sp:AlgorithmSuite>
(P018) <wsp:Policy>
(P019) <sp:Basic256/>
(P020) </wsp:Policy>
(P021) </sp:AlgorithmSuite>
(P022) <sp:Layout>
(P023) <wsp:Policy>
(P024) <sp:Strict/>
(P025) </wsp:Policy>
(P026) </sp:Layout>
(P027) <sp:IncludeTimestamp/>
(P028) <sp:OnlySignEntireHeadersAndBody/>
(P029) </wsp:Policy>
(P030) </sp:SymmetricBinding>
(P031) <sp:Wss11>
(P032) <wsp:Policy>
(P033) <sp:MustSupportRefKeyIdentifier/>
(P034) <sp:MustSupportRefIssuerSerial/>
(P035) <sp:MustSupportRefThumbprint/>
(P036) <sp:MustSupportRefEncryptedKey/>
(P037) <sp:RequireSignatureConfirmation/>
(P038) </wsp:Policy>
(P039) </sp:Wss11>
(P040) </wsp:All>
(P041) </wsp:ExactlyOne>
(P042) </wsp:Policy>
(P043) <wsp:Policy wsu:Id="
WSS11_AnonymousForX509SignEncrypt_input_policy">
(P044) <wsp:ExactlyOne>
(P045) <wsp:All>
(P046) <sp:SignedParts>
(P047) <sp:Body/>
(P048) </sp:SignedParts>
(P049) <sp:EncryptedParts>
(P050) <sp:Body/>
(P051) </sp:EncryptedParts>
(P052) </wsp:All>
(P053) </wsp:ExactlyOne>
(P054) </wsp:Policy>
(P055) <wsp:Policy wsu:Id="
WSS11_AnonymousForX509SignEncrypt_output_policy">
(P056) <wsp:ExactlyOne>
(P057) <wsp:All>
(P058) <sp:SignedParts>
(P059) <sp:Body/>
(P060) </sp:SignedParts>
(P061) <sp:EncryptedParts>
(P062) <sp:Body/>
(P063) </sp:EncryptedParts>
(P064) </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)
</sp:AsymmetricBinding>
(P039)
<sp:Wss10>
(P040)
<wsp:Policy>
(P041)
<sp:MustSupportRefKeyIdentifier/>
(P042)
</wsp:Policy>
(P043)
</sp:Wss10>
(P044)
<sp:SignedSupportingTokens>
(P045)
<wsp:Policy>
(P046)
<sp:SamlToken
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
(P047)
<wsp:Policy>
(P048)
<sp:WssSamlV11Token10/>
(P049)
</wsp:Policy>
(P050)
</sp:SamlToken>
(P051)
</wsp:Policy>
(P052)
</sp:SignedSupportingTokens>
(P053)
</wsp:All>
(P054)
</wsp:ExactlyOne>
(P055)
</wsp:Policy>
(P056)
(P057)
<wsp:Policy
wsu:Id="Wss10SamlSvV11Asymm_input_policy">
(P058)
<wsp:ExactlyOne>
(P059)
<wsp:All>
(P060)
<sp:SignedParts>
(P061)
<sp:Body/>
(P062)
</sp:SignedParts>
(P063)
<sp:EncryptedParts
wsp:Optional="true">
(P064)
<sp:Body/>
(P065)
</sp:EncryptedParts>
(P066)
</wsp:All>
(P067)
</wsp:ExactlyOne>
(P068)
</wsp:Policy>
(P069)
<wsp:Policy
wsu:Id="Wss10SamlSvV11Asymm_output_policy">
(P070)
<wsp:ExactlyOne>
(P071)
<wsp:All>
(P072)
<sp:SignedParts>
(P073)
<sp:Body/>
(P074)
</sp:SignedParts>
(P075)
<sp:EncryptedParts>
(P076)
<sp:Body/>
(P077)
</sp:EncryptedParts>
(P078)
</wsp:All>
(P079)
</wsp:ExactlyOne>
(P080)
</wsp:Policy>
Line (P004) is a wsp:All element whose scope carries down to
line (P053), which means all 3 of the contained assertions: (P005)-(P038)
AsymmetricBinding, (P039)-(P043) WSS10, and (P044)-(P052)
SignedSupportingTokens must be complied with by message exchanges to a Web
Service covered by this policy.
Lines (P005)-(P038) contain an AsymmetricBinding assertion
which indicates that the Initiator’s token must be used for the message
signature and that the recipient’s token must be used for message encryption.
Lines (P007)-(P015) contain the InitiatorToken assertion.
Within the InitiatorToken assertion, lines (P009)‑(P013) indicate that
the Initiator’s token must be an X509Token that must always be included as part
of the request message (as opposed to an external reference). Line (P011)
indicates that the X509 token must be an X.509 V3 signature-verification
certificate and used in the manner described in [WSS10-X509-PROFILE].
Lines (P016)-(P023) contain the RecipientToken assertion.
Again, this an X.509 V3 certificate (P020) that must be used as described in
[WSS10-X509-PROFILE], however the token itself, must never be included in
messages in either direction (P018).
Instead (momentarily skipping slightly ahead), policy lines
(P039)-(P043), the WSS10 assertion, indicate that the Recipient’s token must be
referenced by a KeyIdentifier element, which is described in the WS-Security
1.0 core specification [WSS10‑SOAPMSG].
Lines (P025)-(P029) contain the AlgorithmSuite assertion,
which specifies the sp:Basic256 set of cryptographic components. The relevant
values for this example within the sp:Basic256 components are the asymmetric
signing algorithm, ds:rsa-sha1, and the digest algorithm, ds:sha1, where “ds:”
= “http://www.w3.org/2000/09/xmldsig# “ [XML-DSIG].
Lines (P030)-(P034) contain the sp:Layout assertion, which
is set to sp:Strict (P032), which governs the required relative layout of
various Timestamp, Signature and Token elements in the messages.
Line (P035) IncludeTimestamp means a Timestamp element must
be included in the WS-Security header block and signed by the message signature
for messages in both directions.
Line (P036) OnlySignEntireHeaderAndBody indicates that the
message signature must explicitly cover the SOAP:Body element (not children),
and if there are any signed elements in the SOAP:Header they must be direct
child elements of the SOAP:Header. However, the one exception where the latter
condition is not applied is that if the child of the SOAP:Header is a
WS-Security header (i.e. a wsse:Security element), then individual direct child
only elements of that Security element may also be signed.
Lines (P044)-(P052) contain a SignedSupportingTokens
assertion, which contains only one token (P046)‑(P050), a SamlToken,
which must always be sent to the Recipient (P046) and it must be a
SAML 1.1 Assertion token. Because the SamlToken is in a
“SignedSupportingTokens” element, it is
implicitly a SAML sender-vouches ConfirmationMethod token as described in
section 2.3 above.
Lines (P057)-(P068) contain a policy that applies only to
input messages from the Initiator to the Recipient.
Lines (P060)-(P062) specify that the SOAP:Body element of
the input message must be signed by the Initiator’s message signature.
Lines (P063)-(P065) specify that the SOAP:Body element of
the input message may optionally be encrypted (signified by
wsp:Optional=”true”) using the Recipient’s encryption token (in this case
(P020), it is an X.509 certificate).
Lines (P069)-(P080) contain a policy that applies only to
output messages from the Recipient to the Initiator.
Lines (P072)-(P074) specify that the SOAP:Body element of
the output message must be signed by the Recipient’s message signature.
Lines (P075)-(P077) specify that the SOAP:Body element of
the output message must be encrypted by the Initiator’s encryption token (in
this case (P012), it is also an X.509 certificate).
Here is an example request:
(M001) <?xml
version="1.0" encoding="utf-8" ?>
(M002) <S12:Envelope
(M003) xmlns:S12=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-
(M007) 200401-wss-wssecurity-secext-1.0.xsd"
(M008) xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-
(M009) 200401-wss-wssecurity-utility-1.0.xsd"
(M010) xmlns:ds=http://www.w3.org/2000/09/xmldsig#
(M011) xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">
(M012) <S12:Header>
(M013) <wsse:Security
S12:mustUnderstand="1">
(M014) <wsu:Timestamp
wsu:Id="timestamp">
(M015) <wsu:Created>2003-03-18T19:53:13Z</wsu:Created>
(M016) </wsu:Timestamp>
(M017) <saml:Assertion
(M018) AssertionID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc"
(M019) IssueInstant="2003-04-17T00:46:02Z"
(M020) Issuer=www.opensaml.org
(M021) MajorVersion="1"
(M022) MinorVersion="1">
(M023) <saml:Conditions
(M024) NotBefore="2002-06-19T16:53:33.173Z"
(M025) NotOnOrAfter="2002-06-19T17:08:33.173Z"/>
(M026) <saml:AttributeStatement>
(M027) <saml:Subject>
(M028) <saml:NameIdentifier
(M029) NameQualifier=www.example.com
(M030) Format="">
(M031) uid=joe,ou=people,ou=saml-demo,o=example.com
(M032) </saml:NameIdentifier>
(M033) <saml:SubjectConfirmation>
(M034) <saml:ConfirmationMethod>
(M035) urn:oasis:names:tc:SAML:1.0:cm:sender-vouches
(M036) </saml:ConfirmationMethod>
(M037) </saml:SubjectConfirmation>
(M038) </saml:Subject>
(M039) <saml:Attribute>
(M040) ...
(M041) </saml:Attribute>
(M042) ...
(M043) </saml:AttributeStatement>
(M044) </saml:Assertion>
(M045) <wsse:SecurityTokenReference
wsu:id="STR1">
(M046) <wsse:KeyIdentifier
wsu:id="..."
(M047) ValueType=”http://docs.oasis-open.org/wss/2004/XX/oasis-2004XXwss-saml-token-profile-1.0#SAMLAssertionID”>
(M048) _a75adf55-01d7-40cc-929f-dbd8372ebdfc
(M049) </wsse:KeyIdentifier>
(M050) </wsse:SecurityTokenReference>
(M051) <wsse:BinarySecurityToken
(M052) wsu:Id="attesterCert"
(M053) ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-
(M054) 200401-wss-x509-token-profile-1.0#X509v3"
(M055) EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-
(M056) 200401-wss-soap-message-security-1.0#Base64Binary">
(M057) MIIEZzCCA9CgAwIBAgIQEmtJZc0...
(M058) </wsse:BinarySecurityToken>
(M059) <ds:Signature>
(M060) <ds:SignedInfo>
(M061) <ds:CanonicalizationMethod
(M062) Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
(M063) <ds:SignatureMethod
(M064) Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
(M065) <ds:Reference URI="#STR1">
(M066) <ds:Transforms>
(M067) <ds:Transform
(M068) Algorithm="http://docs.oasis-open.org/wss/2004/01/oasis-
(M069) 200401-wss-soap-message-security-1.0#STR-Transform">
(M070) <wsse:TransformationParameters>
(M071) <ds:CanonicalizationMethod
(M072) Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
(M073) </wsse:TransformationParameters>
(M074) </ds:Transform>
(M075) </ds:Transforms>
(M076) <ds:DigestMethod
(M077) Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
(M078) <ds:DigestValue>...</ds:DigestValue>
(M079) </ds:Reference>
(M080) <ds:Reference
URI="#MsgBody">
(M081) <ds:DigestMethod
(M082) Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
(M083) <ds:DigestValue>...</ds:DigestValue>
(M084) </ds:Reference>
(M085) <ds:Reference
URI="#timestamp">
(M086) <ds:DigestMethod
(M087) Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
(M088) <ds:DigestValue>...</ds:DigestValue>
(M089) </ds:Reference>
(M090) </ds:SignedInfo>
(M091) <ds:SignatureValue>HJJWbvqW9E84vJVQk...</ds:SignatureValue>
(M092) <ds:KeyInfo>
(M093) <wsse:SecurityTokenReference
wsu:id="STR2">
(M094) <wsse:Reference
wsu:id="..." URI="#attesterCert"/>
(M095) </wsse:SecurityTokenReference>
(M096) </ds:KeyInfo>
(M097) </ds:Signature>
(M098) </wsse:Security>
(M099) </S12:Header>
(M0100) <S12:Body wsu:Id="MsgBody">
(M0101) <ReportRequest>
(M0102) <TickerSymbol>SUNW</TickerSymbol>
(M0103) </ReportRequest>
(M0104) </S12:Body>
(M0105) </S12:Envelope>
Note: For the instructional
purposes of this document, in order to be compliant with WS-SecurityPolicy,
this copy of the original message had to be modified from the original. In
particular, the modifications that are applied above are the inclusion of a
wsu:Id attribute in the Timestamp element start tag (M014) and the addition of
a ds:Reference element and URI attribute identifying that Timestamp element in
the message signature (M085)-(M089). (The original message in [WSS10-SAML11-INTEROP scenario #3] is not compliant
with WS-SecurityPolicy because the Timestamp that it contains is not covered by
the message signature in that document.)
Lines (M002)-(M0105) contain the SOAP:Envelope, i.e. the
whole SOAP message.
Lines (M012)-(M099) contain the SOAP:Header, which is the
header portion of the SOAP message.
Lines (M0100)-(M0104) contain the SOAP:Body, which is just
some dummy content for test purposes.
Lines (M013)-(M098) contain the wsse:Security header, which
is the primary focus of this example.
Lines (M014)-(M016) contain the wsu:Timestamp, which is
required by the policy (P035).
Lines (M017)-(M044) contain the SAML Assertion, which is the
sp:SamlToken required by the policy sp:SignedSupportingTokens (P046)‑(P050).
Lines (M021)-(M022) identify the SAML Assertion as being
Version 1.1 as required by the policy (P048).
Line (M035) identifies the SAML Assertion as having
ConfirmationMethod sender-vouches, which is the implicit requirement of the
sp:SamlToken being in the SignedSupportingTokens as described above in the
policy section covering (P044)-(P052).
Lines (M045)-(M050) contain a wsse:SecurityTokenReference
which contains a wsse:KeyIdentifier, which is used to reference the SAML
Assertion, as described in [WSS10-SAML11-PROFILE]
and required by the policy (P041).
Lines (M051)-(M058) contain the Initiator’s
wsse:BinarySecurityToken, which is required by the policy (P007)-(P015), and in
particular lines (M053)-(M054) identify the token as an X.509 V3 token as
required by the policy (P011). Line (M057) contains a truncated portion of the
Base64 representation of the actual certificate, which is included in the
message as required by the policy sp:IncludeToken (P009).
Lines (M059)-(M0102) contain the ds:Signature, which is the
sp: message signature as required by various parts of the Endpoint Policy
(P001)-(P055) and Input Message Policy (P057)‑(P068).
Lines (M060)-(M095) contain the ds:SignedInfo element which
describes the signing algorithm used (M064) and specific elements that are
signed (M065)-(M094) as required by the policies, which are described in detail
immediately following.
Lines (M061)-(M062) contain the ds:CanonicalizationMethod
Algorithm, which is specified as xml-exc-c14n#, which is the default value
required by the policy sp:AlgorithmSuite (P025)-(P029).
Line (M064) identifies the SignatureMethod Algorithm as
ds:rsa-sha1, which is the asymmetric key signing algorithm required by the
policy sp:AlgorithmSuite (P025)-(P029).
Lines (M065)-(M079) identify the SAML Assertion
(M017)-(M044) as an element that is signed, which is referenced through the URI
“#STR1” on line (M065), which references the SecurityTokenReference
(M045)-(M050), which in turn uses the identifier on line (M048) to reference
the actual SAML Assertion by its AssertionID attribute on line (M018). The SAML
Assertion is required to be signed because it is identified in the policy
within the SignedSupportingTokens element on line (P048).
Lines (M077)-(M078) contain the digest algorithm, which is
specified to be sha1, as required by the policy sp:Basic256 assertion (P027) in
the sp:AlgorithmSuite.
Lines (M080)-(M084) identify the SOAP:Body (M0100)-(M0104)
as an element that is signed, which is referenced through the URI “#MsgBody” on
line (M080). The SOAP Body is required to be signed by the input message policy
lines (P060)-(P062).
Lines (M085)-(M089) identify the wsu:Timestamp (M014)-(M016)
as an element that is signed, which is referenced throught the URI “#timestamp”
on line (M085). The wsu:Timestamp is required to be signed by the policy
sp:IncludeTimestamp assertion (P035). Note that the wsu:Timestamp occurs in the
wsse:Security header prior to the ds:Signature as required by the sp:Strict
layout policy (P032).
Finally, lines (M092)-(M096) contain the ds:KeyInfo element
that identifies the signing key associated with this ds:Signature element. The
actual signing key is referenced through the wsse:SecurityTokenReference
(M093)-(M095), with URI “#attesterCert”, which identifies the InitiatorToken
identified by the policy (P011) and contained in the wsse:BinarySecurityToken
element (M051)-(M058), which occurs in the wsse:Security header prior to this
ds:Signature element, as required by the sp:Strict layout policy assertion
(P032). (Note: this BinarySecurityToken would need to be included in the
signature, if the sp:AsymmetricBinding assertion in the endpoint policy
contained a sp:ProtectTokens assertion, but it does not, so it does not need to
be signed.)
This example is based on the first WSS SAML Profile InterOp
[WSS10-SAML11-INTEROP Scenario #4].
In this example the SAML token provides the key material for
message security, hence acts as the Initiator token, and therefore the
Requestor and Initiator may be considered to be the same entity. The SAML HK
Assertion contains a reference to the public key of the signer of the message
(the Initiator). The Initiator knows Recipient's public key, which it may use
to encrypt the request, but the Initiator does not share a direct trust
relation with the Recipient except indirectly throught the SAML Assertion
Issuer. The Recipient has a trust relation with the Authority that issues the
SAML HK Assertion The indirect trust relation between the Recipient and the
Initiator is established by the fact that the Initiator’s public key has been
signed by the Authority in the SAML HK Assertion. On the request the message
body is signed using Initiator’s private key referenced in the SAML HK
Assertion and it is optionally encrypted using Recipient’s server certificate.
On the response, the server signs the message using its private key and
encrypts the message using the key provided within SAML HK Assertion.
HK Note: there is a trust model aspect
to the WS-Security holder-of-key examples that implementors may want to be
aware of. The [SAML20-CORE] specification defines the
Subject of the SAML Assertion such that the “presenter” of the Assertion is the
entity that “attests” to the information in the Assertion. “The attesting
entity and the actual Subject may or may not be the same entity.” In
general, these two choices map to the actors in Figure 1
as follows: the “attesting” entity may be regarded as the Initiator. The
Subject entity, about whom the information in the Assertion applies, may be
regarded as the Requestor. In the case where the Subject and attestor are one
and the same, the Initiator and Requestor may be regarded as one and the same.
In this case the potential exists to use the Assertion for non-repudiation
purposes with respect to messages that the Requestor/Initiator signs. When the
Subject and attestor are separate entities, then holder-of-key is more similar
to sender-vouches where the Initiator/attestor is sending the message on behalf
of the Subject. The mechanisms for determining whether the Subject and attestor
may be verified to be the same entity are dependent on the arrangements among
the business entities and the structure of the associated application
scenarios.
(P001)
<wsp:Policy xmlns:wsp="..."
xmlns:wsu="..." xmlns:sp="..."
(P002)
wsu:Id="Wss10SamlHkV11Asymm_endpoint_policy">
(P003)
<wsp:ExactlyOne>
(P004)
<wsp:All>
(P005)
<sp:AsymmetricBinding>
(P006)
<wsp:Policy>
(P007)
<sp:InitiatorToken>
(P008)
<wsp:Policy>
(P009)
<sp:SamlToken
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
(P010)
<wsp:Policy>
(P011)
<wsp:WssSamlV11Token10/>
(P012)
</wsp:Policy>
(P013)
</sp:SamlToken>
(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)
</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)
(P048)
<wsp:Policy
wsu:Id="WSS10SamlHok_input_policy">
(P049)
<wsp:ExactlyOne>
(P050)
<wsp:All>
(P051)
<sp:SignedParts>
(P052)
<sp:Body/>
(P053)
</sp:SignedParts>
(P054)
<wsp:ExactlyOne>
(P055)
<wsp:All>
(P056)
<sp:EncryptedParts>
(P057)
<sp:Body/>
(P058)
</sp:EncryptedParts>
(P059)
</wsp:All>
(P060)
<wsp:All/>
(P061)
</wsp:ExactlyOne>
(P062)
</wsp:All>
(P063)
</wsp:ExactlyOne>
(P064)
</wsp:Policy>
(P065)
(P066)
<wsp:Policy
wsu:Id="WSS10SamlHok_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 (P001)-(P046) contain
the endpoint policy, and lines (P048)-(P064) and (P066)-(P077) contain the
message input and message output policies, respectively.
Lines (P005)-(P038) contain
the AsymmetricBinding assertion, which requires separate security tokens for
the Initiator and Recipient.
Lines (P007)-(P015) contain
the InitiatorToken, which is defined to be a SamlToken (P009)-(P013), which
must always be sent to the Recipient (P009). The SamlToken is further specified
by the WssSamlV11Token10 assertion (P011) that requires the token to be a
SAML 1.1 Assertion and the token must be used in accordance with the
WS-Security [WSS10-SAML11-PROFILE].
Furthermore, as described in section 2.3 above, because the SamlToken
assertion appears within an InitiatorToken assertion, the SAML Assertion must
use the holder-of-key ConfirmationMethod, whereby for the indicated WS-Security
profile, the SAML Assertion contains a reference to the Initiator’s X.509
signing certificate or equivalent.
Lines (P016)-(P024) contain
the RecipientToken assertion. Again, this an X.509 V3 certificate (P020) that
must be used as described in [WSS10-SAML11-PROFILE], however the token itself,
must never be included in messages in either direction (P018) (i.e not only
will the Recipient not send the token, but the Initiator must not send the
actual token, even when using it for encryption).
Lines (P025)-(P029) AlgorithmSuite and (P030)-(P034) Layout
are the same as described above in section 2.3.1.4.
Line (P035) IncludeTimestamp means a Timestamp element must
be included in the WS-Security header block and signed by the message signature
for messages in both directions.
Line (P036) OnlySignEntireHeaderAndBody indicates that the
message signature must explicitly cover the SOAP:Body element (not children),
and if there are any signed elements in the SOAP:Header they must be direct
child elements of the SOAP:Header. However, the one exception where the latter
condition is not applied is that if the child of the SOAP:Header is a
WS-Security header (i.e. a wsse:Security element), then individual direct child
only elements of that Security element may also be signed.
Lines (P039)-(P043) contain
the WSS10 assertion, which indicates that the Recipient’s token must be
referenced by a KeyIdentifier element (P041), the usage of which is described
in the WS-Security 1.0 core specification [WSS10‑SOAPMSG].
Lines (P048)-(P064) contain the message input policy that
applies only to messages from the Initiator to the Recipient.
Lines (P051)-(P053) specify that the SOAP:Body element of
the input message must be signed by the Initiator’s message signature.
Lines (P054)-(P061) specify that the SOAP:Body element of
the input message may optionally (signified by the empty policy alternative on
line (P060)) be encrypted using the Recipient’s encryption token (in this case
(P020), it is an X.509 certificate).
Note:
Because the input policy above (P048-P064) has the EncryptedParts assertion
(P056‑P058) contained in an <ExactlyOne> element (P054-P061), which also contains an empty
policy element (P060), either a message with an encrypted Body element or an
unencrypted Body element will be accepted.
Lines (P066)-(P077) contain a message output policy that
applies only to messages from the Recipient to the Initiator.
Lines (P069)-(P071) specify that the SOAP:Body element of
the output message must be signed by the Recipient’s message signature.
Lines (P072)-(P074) specify that the SOAP:Body element of
the output message must be encrypted by the Initiator’s encryption token (in
this case (P012), it is also an X.509 certificate).
The following example request
is taken from the [WSS10-SAML11-INTEROP]
document scenario #4:
(M001) <?xml
version="1.0" encoding="utf-8" ?>
(M002) <S12:Envelope
(M003) xmlns:S12=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) xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
(M011) <S12:Header>
(M012) <wsse:Security
S12:mustUnderstand="1">
(M013) <wsu:Timestamp
wsu:Id="timestamp">
(M014) <wsu:Created>2003-03-18T19:53:13Z</wsu:Created>
(M015) </wsu:Timestamp>
(M016) <saml:Assertion
(M017) AssertionID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc"
(M018) IssueInstant="2003-04-17T00:46:02Z"
(M019) Issuer=www.opensaml.org
(M020) MajorVersion="1"
(M021) MinorVersion="1"
(M022) xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">
(M023) <saml:Conditions
(M024) NotBefore="2002-06-19T16:53:33.173Z"
(M025) NotOnOrAfter="2002-06-19T17:08:33.173Z"/>
(M026) <saml:AttributeStatement>
(M027) <saml:Subject>
(M028) <saml:NameIdentifier
(M029) NameQualifier=www.example.com
(M030) Format="">
(M031) uid=joe,ou=people,ou=saml-demo,o=example.com
(M032) </saml:NameIdentifier>
(M033) <saml:SubjectConfirmation>
(M034) <saml:ConfirmationMethod>
(M035) urn:oasis:names:tc:SAML:1.0:cm:holder-of-key
(M036) </saml:ConfirmationMethod>
(M037) <ds:KeyInfo>
(M038) <ds:KeyValue>...</ds:KeyValue>
(M039) </ds:KeyInfo>
(M040) </saml:SubjectConfirmation>
(M041) </saml:Subject>
(M042) <saml:Attribute
(M043) AttributeName="MemberLevel"
(M044) AttributeNamespace=
(M045) "http://www.oasis-open.org/Catalyst2002/attributes">
(M046) <saml:AttributeValue>gold</saml:AttributeValue>
(M047) </saml:Attribute>
(M048) <saml:Attribute
(M049) AttributeName="E-mail"
(M050) AttributeNamespace="http://www.oasis-
(M051) open.org/Catalyst2002/attributes">
(M052) <saml:AttributeValue>joe@yahoo.com</saml:AttributeValue>
(M053) </saml:Attribute>
(M054) </saml:AttributeStatement>
(M055) <ds:Signature>...</ds:Signature>
(M056) </saml:Assertion>
(M057) <ds:Signature>
(M058) <ds:SignedInfo>
(M059) <ds:CanonicalizationMethod
(M060) Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
(M061) <ds:SignatureMethod
(M062) Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
(M063) <ds:Reference
URI="#MsgBody">
(M064) <ds:DigestMethod
(M065) Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
(M066) <ds:DigestValue>GyGsF0Pi4xPU...</ds:DigestValue>
(M067) </ds:Reference>
(M068) <ds:Reference
URI="#timestamp">
(M069) <ds:DigestMethod
(M070) Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
(M071) <ds:DigestValue>...</ds:DigestValue>
(M072) </ds:Reference>
(M073) </ds:SignedInfo>
(M074) <ds:SignatureValue>HJJWbvqW9E84vJVQk...</ds:SignatureValue>
(M075) <ds:KeyInfo>
(M076) <wsse:SecurityTokenReference
wsu:id="STR1">
(M077) <wsse:KeyIdentifier
wsu:id="..."
(M078) ValueType="http://docs.oasis-open.org/wss/2004/XX/oasis-
(M079) 2004XX-wss-saml-token-profile-1.0#SAMLAssertionID">
(M080) _a75adf55-01d7-40cc-929f-dbd8372ebdfc
(M081) </wsse:KeyIdentifier>
(M082) </wsse:SecurityTokenReference>
(M083) </ds:KeyInfo>
(M084) </ds:Signature>
(M085) </wsse:Security>
(M086) </S12:Header>
(M087) <S12:Body wsu:Id="MsgBody">
(M088) <ReportRequest>
(M089) <TickerSymbol>SUNW</TickerSymbol>
(M090) </ReportRequest>
(M091) </S12:Body>
(M092) </S12:Envelope>
Note: for the instructional
purposes of this document, it was necessary to make changes to the original
sample request to meet the requirements of WS-SecurityPolicy. The changes to
the message above include:
·
Line (M013): added wsu:Id=”timestamp” attribute to
sp:Timestamp element.
·
Lines (M068)-(M072): added a ds:Reference element to include
the Timestamp in the message signature required by the policy
sp:IncludeTimestamp assertion (P035).
Lines (M002)-(M092) contain
the SOAP Envelope, i.e. the whole SOAP message.
Lines (M011)-(M086) contain
the SOAP Header.
Lines (M087)-(M091) contain
the unencrypted SOAP Body, which is allowed to be unencrypted based on line
(P060) of the input message policy, which is the alternative choice to
encrypting based on lines (P055)‑(P059).
Lines (M012)-(M080) contain
the wsse:Security header entry, which is the only header entry in this SOAP
Header.
Lines (M013)-(M015) contain
the wsu:Timestamp which is required by the endpoint policy (P035).
Lines (M016)-(M056) contain
the SAML Assertion, which is required in the policy by the SamlToken
(P009)-(P013) contained in the InitiatorToken. The SAML Assertion is version
1.1 (M020)-(M021) as required by the sp:WssSamlV11Token10 assertion (P011). The
SAML Assertion is of type that uses the holder-of-key saml:ConfirmationMethod [SAML11-CORE] (M034)-(M036) as required by the fact that
the SamlToken is contained in the InitiatorToken assertion of the policy
(P009)-(P013), as explained in section 2.3 above.
Line (M055) contains the
ds:Signature of the Issuer of the SAML Assertion. While the details of this
signature are not shown, it is this signature that the Recipient must
ultimately trust in order to trust the rest of the message.
Lines (M057)-(M084) contain
the message signature in a ds:Signature element.
Lines (M058)-(M073) contain
the ds:SignedInfo element, which identifies the elements to be signed.
Lines (M063)-(M067) contains
a ds:Reference to the SOAP:Body, which is signed in the same manner as example
section 2.3.1.4 above.
Lines (M068)-(M072) contains
a ds:Reference to the URI “timestamp”, which again is signed in the same manner
as the wsu:Timestamp in section 2.3.1.4 above.
Lines (M075)-(M083) contain
the ds:KeyInfo element, which identifies the key that should be used to verify
this ds:Signature element. Lines (M076)-(M082) contain a
wsse:SecurityTokenReference, which contains a wsse:KeyIdentifier that
identifies the signing key as being contained in a token of wsse:ValueType
“…wss-saml-token-profile-1.0#SAMLAssertionID”, which means a SAML V1.1
Assertion [WSS10-SAML11-PROFILE]. Line (M080)
contains the saml:AssertionID of the SAML Assertion that contains the signing
key. This SAML Assertion is on lines (M016)-(M056) with the correct
saml:AssertionID on line (M017). Note that the fact that the referenced token
(the SAML Assertion) occurs in the wsse:Security header before this ds:KeyInfo
element that uses it in compliance with the sp:Strict layout policy (P032) and
the wsse:KeyIdentifier is an acceptable token reference mechanism as specified
in the policy sp:Wss10 assertion containing a sp:MustSupportRefKeyIdentifier
assertion (P041).
This section contains SamlToken examples that use
WS-Security 1.1 SOAP Message Security [WSS11] and the
WS-Security 1.1 SAML Profile [WSS11-SAML1120-PROFILE].
This
example is based on the Liberty Alliance Identity Web Services Framework
(ID-WSF 2.0) Security Mechanism for the SAML 2.0 Profile for WSS 1.1 [WSS11-LIBERTY-SAML20-PROFILE], which
itself is based on the [WSS11-SAML1120-PROFILE].
In this example, an AsymmetricBinding is used for message
protection provided by the Initiator, however, Recipient trust for the content
is based only on the SAML bearer token provided by the Requestor.
(P001) <wsp:Policy>
(P002) <sp:AsymmetricBinding>
(P003) <wsp:Policy>
(P004) <sp:InitiatorToken>
(P005) <wsp:Policy>
(P006) <sp:X509Token
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
(P007) <wsp:Policy>
(P008) <sp:WssX509V3Token10/>
(P009) </wsp:Policy>
(P010) </sp:X509Token>
(P011) </wsp:Policy>
(P012) </sp:InitiatorToken>
(P013) <sp:RecipientToken>
(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:RecipientToken>
(P022) <sp:AlgorithmSuite>
(P023) <wsp:Policy>
(P024) <sp:Basic256/>
(P025) </wsp:Policy>
(P026) </sp:AlgorithmSuite>
(P027) <sp:Layout>
(P028) <wsp:Policy>
(P029) <sp:Strict/>
(P030) </wsp:Policy>
(P031) </sp:Layout>
(P032) <sp:IncludeTimestamp/>
(P033) <sp:OnlySignEntireHeadersAndBody/>
(P034) </wsp:Policy>
(P035) </sp:AsymmetricBinding>
(P036) <sp:Wss11>
(P037) <wsp:Policy>
(P038) <sp:MustSupportRefKeyIdentifier/>
(P039) <sp:MustSupportRefIssuerSerial/>
(P040) <sp:MustSupportRefThumbprint/>
(P041) <sp:MustSupportRefEncryptedKey/>
(P042) </wsp:Policy>
(P043) </sp:Wss11>
(P044) <sp:SupportingTokens>
(P045) <wsp:Policy>
(P046) <sp:SamlToken
sp:IncludeToken=”http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient”>
(P047) <wsp:Policy>
(P048) <sp:WssSamlV20Token11/>
(P049) </wsp:Policy>
(P050) </sp:SamlToken>
(P051) </wsp:Policy>
(P052) </sp:SupportingTokens>
(P053) </wsp:Policy>
Lines (P001)-(P045) contain the endpoint policy, which
contains 3 assertions: an sp:AsymmetricBinding assertion, an sp:Wss11
assertion, and an sp:SupportingTokens assertion.
Lines (P002)-(P035) contain the sp:AsymmetricBinding
assertion, which is identical to the same assertion that is described in
section 2.1.3. Please refer to section 2.1.3 for details.
Lines (P036)-(P043) contain an sp:Wss11 assertion, which
contains a set of assertions that specify the token referencing techniques that
are required to be supported (P038)-(P041).
Lines (P044)-(P052) contain an sp:SupportingTokens
assertion, which contains an sp:SamlToken (P046)‑(P050), which specifies
that it must always be sent to the Recipient. The sp:SamlToken contains an
sp:WssSamlV20Token11 assertion (P048), which means that the SamlToken provided
must be a SAML Version 2.0 Assertion that is submitted in compliance with the [WSS11-SAML1120-PROFILE].
The fact that the sp:SamlToken is contained in an
sp:SupportingTokens element indicates to the Initiator that the SAML Assertion
must use the saml2:SubjectConfirmation@Method “bearer” as described above in
introductory section 2.3.
The following is an example request compliant with the above
policy:
(M001) <?xml
version="1.0" encoding="UTF-8"?>
(M002) <s:Envelope
xmlns:s=".../soap/envelope/" xmlns:sec="..."
(M003) xmlns:wsse="..."
xmlns:wsu="..." xmlns:wsa="...addressing"
(M004) xmlns:sb="...liberty:sb"
xmlns:pp="...liberty.id-sis-pp"
(M005) xmlns:ds="...xmldsig#"
xmlns:xenc="...xmlenc#">
(M006) <s:Header>
(M007) <!-- see Liberty SOAP Binding Spec for
reqd, optional hdrs -->
(M008) <wsa:MessageID
wsu:Id="mid">...</wsa:MessageID>
(M009) <wsa:To
wsu:Id="to">...</wsa:To>
(M010) <wsa:Action
wsu:Id="action">...</wsa:Action>
(M011) <wsse:Security
mustUnderstand="1">
(M012) <wsu:Timestamp
wsu:Id="ts">
(M013) <wsu:Created>2005-06-17T04:49:17Z</wsu:Created
>
(M014) </wsu:Timestamp>
(M015) <!-- this is the bearer token -->
(M016) <saml2:Assertion
xmlns:saml2="...SAML:2.0:assertion"
(M017) Version="2.0"
ID="sxJu9g/vvLG9sAN9bKp/8q0NKU="
(M018) IssueInstant="2005-04-01T16:58:33.173Z">
(M019) <saml2:Issuer>http://authority.example.com/</saml2:Issuer>
(M020) <!-- signature by the issuer over
the assertion -->
(M021) <ds:Signature>...</ds:Signature>
(M022) <saml2:Subject>
(M023) <saml2:EncryptedID>
(M024) <xenc:EncryptedData
(M025) >U2XTCNvRX7Bl1NK182nmY00TEk==</xenc:EncryptedData>
(M026) <xenc:EncryptedKey>...</xenc:EncryptedKey>
(M027) </saml2:EncryptedID>
(M028) <saml2:SubjectConfirmation
(M029) Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"/>
(M030) </saml2:Subject>
(M031) <!-- audience restriction on
assertion can limit scope of
(M032) which entity should consume the info in
the assertion. -->
(M033) <saml2:Conditions
NotBefore="2005-04-01T16:57:20Z"
(M034) NotOnOrAfter="2005-04-01T21:42:4
3Z">
(M035) <saml2:AudienceRestrictionCondition>
(M036) <saml2:Audience>http://wsp.example.com</saml2:Audience>
(M037) </saml2:AudienceRestrictionCondition>
(M038) </saml2:Conditions>
(M039) <!-- The AuthnStatement carries info
that describes authN
(M040) event of the Subject to an
Authentication Authority -->
(M041) <saml2:AuthnStatement
AuthnInstant="2005-04-01T16:57:30.000Z"
(M042) SessionIndex="6345789">
(M043) <saml2:AuthnContext>
(M044) <saml2:AuthnContextClassRef
(M045) >...:SAML:2.0:ac:classes:PasswordProtectedTransport
(M046) </saml2:AuthnContextClassRef>
(M047) </saml2:AuthnContext>
(M048) </saml2:AuthnStatement>
(M049) <!-- This AttributeStatement carries
an EncryptedAttribute.
(M050) Once this element decrypted with
supplied key an <Attribute>
(M051) element bearing endpoint reference can
be found, specifying
(M052) resources which invoker may access.
Details on element can be
(M053) found in discovery service
specification. -->
(M054) <saml2:AttributeStatement>
(M055) <saml2:EncryptedAttribute>
(M056) <xenc:EncryptedData
(M057) Type="http://www.w3.org/2001/04/xmlenc#Element"
>
(M058) mQEMAzRniWkAAAEH9RWir0eKDkyFAB7PoFazx3ftp0vWwbbzqXdgcX8
(M059) ... hg6nZ5c0I6L6Gn9A=HCQY
(M060) </xenc:EncryptedData>
(M061) <xenc:EncryptedKey> ...
</xenc:EncryptedKey>
(M062) </saml2:EncryptedAttribute>
(M063) </saml2:AttributeStatement>
(M064) </saml2:Assertion>
(M065) <!-- This SecurityTokenReference is
used to reference the SAML
(M066) Assertion from a ds:Reference -->
(M067) <wsse:SecurityTokenReference
xmlns:wsse="..." xmlns:wsu="..."
(M068) xmlns:wsse11="..."
wsu:Id="str1" wsse11:TokenType=
(M069) ".../wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0">
(M070) <wsse:KeyIdentifier ValueType=
(M071) ".../wss/oasis-wss-sam
l-token-profile-1.1#SAMLID"
(M072) >sxJu9g/vvLG9sAN9bKp/8q0NKU=</wsse:KeyIdentifier>
(M073) </wsse:SecurityTokenReference>
(M074) <ds:Signature>
(M075) <ds:SignedInfo>
(M076) <!-- in general include a
ds:Reference for each wsa:header
(M077) added according to SOAP binding, plus
timestamp, plus ref to
(M078) assertion to avoid token substitution
attacks, plus Body -->
(M079) <ds:Reference
URI="#to">...</ds:Reference>
(M080) <ds:Reference
URI="#action">...</ds:Reference>
(M081) <ds:Reference
URI="#mid">...</ds:Reference>
(M082) <ds:Reference
URI="#ts">...</ds:Reference>
(M083) <ds:Reference
URI="#Str1">
(M084) <ds:Transform
Algorithm="...#STR-Transform">
(M085) <wsse:TransformationParameters>
(M086) <ds:CanonicalizationMethod
Algorithm=
(M087) "http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
(M088) </wsse:TransformationParameters>
(M089) </ds:Transform>
(M090) </ds:Reference>
(M091) <ds:Reference
URI="#MsgBody">...</ds:Reference>
(M092) </ds:SignedInfo>
(M093) ...
(M094) </ds:Signature>
(M095) </wsse:Security>
(M096) </s:Header>
(M097) <s:Body wsu:Id="MsgBody">
(M098) <pp:Modify>
(M099) <!-- this is an ID-SIS-PP Modify
message -->
(M0100) </pp:Modify>
(M0101) </s:Body>
(M0102) </s:Envelope>
The sample message above was taken and cosmetically edited
from the [WSS11-LIBERTY-SAML20-PROFILE].
Lines (M002)-(M0102) contain the SOAP:Envelope, which
contains the SOAP:Header (M006)‑(M096) and the SOAP:Body (M097)-(M0101).
The SOAP Header contains some WS-Addressing (wsa:)
parameters (M008)-(M010) (not discussed here) and a wsse:Security header.
The wsse:Security header (M011)-(M095) contains a
wsu:Timestamp (M012)-(M014), a saml2:Assertion (M016)-(M064), a
wsse:SecurityTokenReference (M067)-(M073), and a ds:Signature (M074)-(M094).
The wsu:Timestamp (M012)-(M014) is required by the policy
sp:IncludeTimestamp assertion (P032).
The saml2:Assertion (M016)-(M064) is required by the policy
sp:WssSamlV20Token11 (P048). The saml2:Assertion is Version 2.0 (M017) and it
is signed by the IssuingAuthority (M021). This is the ds:Signature (M021) of
the IssuingAuthority, identified in the saml2:Issuer element (M019), that the
Recipient trusts with respect to recognizing the Requestor and determining
whether the request should be granted. In addition, this saml2:Assertion uses
the “bearer” saml2:SubjectConfirmation@Method, as required by the policy
sp:SamlToken in the sp:SupportingTokens element described above (P044)‑(P052).
Note: the saml2:Assertion contains a
saml2:EncryptedID (M023)-(M027), which contains the identity of the Requestor
and a saml2:EncryptedAttribute (M062), which contains information about the
Requestor. It is presumed that prior to issuing this request, that the
Requestor contacted the IssuingAuthority (directly or indirectly) and was
granted permission to access the web service that is now the target of this
request. As such, the IssuingAuthority has knowledge of this web service and
presumably the public certificate associated with that service and has used the
public key contained in that certificate to encrypt the aforementioned portions
of the saml2:Assertion, which can only be decrypted by the RelyingParty who
presumably has entrusted the private key of the service with the Recipient, in
order that the Recipient may decrypt the necessary data.
However, before the Recipient can evaluate these aspects of
the request, the requirements of the policy sp:AsymmetricBinding (P002)-(P035)
must be met in terms of proper “presentation” of the request as described
below.
Lines (M074)-(M094) contain the message signature
ds:Signature element, which contains a ds:SignedInfo that contains ds:Reference
elements that cover the wsa: headers (M079)-(M081), the wsu:Timestamp (M082)
(required by the policy sp:IncludeTimestamp assertion (P032), the
saml2:Assertion (M083)-(M090), and the SOAP:Body (M091).
The ds:Reference (M083)-(M090) covering the saml2:Assertion
warrants further examination.
The first point to note is that
to reference the saml2:Assertion the ds:Reference uses an STR-Transform (M084)
to reference a wsse:SecurityTokenReference (M067)-(M073), which is in
compliance with policy sp:Wss11 sp:MustSupportRefKeyIdentifier assertion
(P038).
The second point to note about
this ds:Reference is that is covering the saml2:Assertion even though the
policy references the sp:SamlToken in an sp:SupportingTokens element and not an
sp:SignedSupportingTokens element. The reason this is the case is that it is
the fact that an sp:SupportingTokens (P044)-(P052) element is used that tells the
Initiator that a SAML bearer Assertion is required. However, this only means
that the SamlToken is not “required” to be signed. It is the Initiator’s choice
whether to sign it or not, and it is generally good practice to do so in order
to prevent a token substitution attack.
This scenario is based on second WSS SAML Profile InterOp [WSS11-SAML1120-INTEROP Scenario #2].
Similar to 2.3.1.2 except SAML token is of version 2.0.
(P001) <wsp: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:WssSamlV20Token11/>
(P031) </wsp:Policy>
(P032) </sp:SamlToken>
(P033) </wsp:Policy>
(P034) </sp:SignedSupportingTokens>
(P035) </wsp:Policy>
Lines (P001)-(P035) contain the policy that requires all the
contained assertions to be complied with by the Initiator. In this case there
are 2 assertions: sp:TransportBinding (P002) and sp:SignedSupportingTokens
(P026).
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 requirements for the sp:Layout assertion (P018)-(P022)
should be automatically met (or may be considered moot) since there are no
cryptographic tokens required to be present in the WS-Security header.
(However, if a signature element was included to cover the wsse:Timestamp, then
the layout would need to be considered.)
A timestamp (P023) is required to be included in an
acceptable message.
Here is an example request:
(M001) <?xml
version="1.0" encoding="utf-8" ?>
(M002) <S11:Envelope
xmlns:S11="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) xmlns:wsu=".../oasis-200401-wsswssecurity-utility-1.0.xsd"
(M006) xmlns:wsse=".../oasis-200401-wss-wssecurity-secext-1.0.xsd"
(M007) xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
(M008) <S11:Header>
(M009) <wsse:Security
S11:mustUnderstand="1">
(M010) <wsu:Timestamp>
(M011) <wsu:Created>2005-03-18T19:53:13Z</wsu:Created>
(M012) </wsu:Timestamp>
(M013) <saml2:Assertion
ID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc"
(M014) IssueInstant="2005-04-17T00:46:02Z"
Version="2.0">
(M015) <saml2:Issuer>www.opensaml.org</saml2:Issuer>
(M016) <saml2:Conditions
NotBefore="2005-06-19T16:53:33.173Z"
(M017) NotOnOrAfter="2006-06-19T17:08:33.173Z"
/>
(M018) <saml2:Subject>
(M019) <saml2:NameID Format=
(M020) "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
(M021) >uid=joe,ou=people,ou=saml
demo,o=example.com</saml2:NameID>
(M022) <saml2:SubjectConfirmation Method=
(M023) "urn:oasis:names:tc:SAML:2.0:cm:sender-vouches"
/>
(M024) </saml2:Subject>
(M025) <saml2:AttributeStatement>
(M026) <saml2:Attribute>...</saml2:Attribute>
(M027) <saml2:Attribute>...</saml2:Attribute>
(M028) </saml2:AttributeStatement>
(M029) </saml2:Assertion>
(M030) </wsse:Security>
(M031) </S11:Header>
(M032) <S11:Body>
(M033) <Ping
xmlns="http://xmlsoap.org/Ping">
(M034) <text>EchoString</text>
(M035) </Ping>
(M036) </S11:Body>
(M037) </S11:Envelope>
Lines (M002)-(M037) contain the SOAP:Envelope, which
contains the SOAP:Header (M003)-(M031) and the SOAP:Body (M032)-(M036).
Lines (M009)-(M030) contain the wsse:Security header, which,
in conjunction with the client certificate (P008), is the primary basis
for trust in this example.
Lines (M010)-(M012) contain the wsu:Timestamp, which meets
the sp:IncludeTimestamp assertion policy requirement (P023).
Lines (M013)-(M029) contain the saml2:Assertion, which is
required to be Version 2.0 (M014) and to be
used within the [WSS11-SAML1120-PROFILE],
because of the policy sp:SamlToken assertion (P028)‑(P032), which
contains the sp:WssSamlV20Token11 (P030).
Lines (M022)-(M023) indicate that the SAML Assertion uses
the saml2:Method sender-vouches for the purposes of saml2:SubjectConfirmation,
which is required by the fact that the sp:SamlToken appears in an
sp:SignedSupportingTokens assertion (P026)-(P034) in conjunction with the
client certificate required by the sp:RequireClientCertificate asertion (P008)
within the sp:TransportBinding as described in section 2.3 above. In addition,
the Recipient should be able to correlate the saml2:Issuer (M015) as being
properly associated with the client certficate received from the HTTPS (SSL)
connection.
This scenario is based on second WSS SAML Profile InterOp [WSS11-SAML1120-INTEROP Scenario #5].
Similar to 2.3.1.3 except SAML token is of version 2.0.
Initiator adds a SAML Assertion (hk) to the SOAP Security
Header. In this policy the sp:TransportBinding requires a Client Certificate
AND the sp:SamlToken is in an sp:SignedEndorsingSupportingTokens element. A
SAML holder-of-key Assertion meets these requirements because it is “virtually
signed” by the message signature as a result of the SSL client certificate
authentication procedure as described in section 2.3. Furthermore, the SAML hk
Assertion in this case is a “virtually endorsing”, because the key identified
in the holder-of-key saml2:SubjectConfirmationData is also the client
certificate, which is virtually endorsing its own signature, under the
authority of the IssuingAuthority who has signed the SAML hk Assertion.
As a result, the Initiator may be considered to be
authorized by the saml2: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.
(Note: the same considerations described in
section 2.3.1.4 with respect to whether the Subject of the Assertion and the
Subject of the Client Certificate are the same entity determining whether the
Client Certificate is attesting for the Assertion Subject or whether the Client
Certificate is authenticating as the Assertion Subject apply here.)
In this scenario, the IssuingAuthority is the
saml2:Issuer(signer) of the hk SAML Assertion. The Requestor is the Subject of
the Assertion and the Initiator is authorized by the IssuingAuthority to bind
the Assertion to the message using the ClientCertificate identified in the SAML
Assertion, which may also be considered to be virtually signing the
wsu:Timestamp of the message. Optionally, a separate Signature may be used to
sign the wsu:Timestamp, which the Recipient would also be required to verify
was signed by the client certificate in this example.
(P001) <wsp: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:SignedEndorsingSupportingTokens>
(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:WssSamlV20Token11/>
(P031) </wsp:Policy>
(P032) </sp:SamlToken>
(P033) </wsp:Policy>
(P034) </sp:SignedEndorsingSupportingTokens>
(P035) </wsp:Policy>
Lines (P001)-(P035) contain the policy that requires all the
contained assertions to be complied with by the Initiator. In this case there
are 2 assertions: sp:TransportBinding (P002) and sp:EndorsingSupportingTokens
(P026).
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 holder-of-key, 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]. In the holder-of-key case, there will be an additional
certificate required in the trust chain, which is the certificate used to sign
the SAML hk Assertion, which will be contained or referenced in the Assertion.
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. (However, if a
signature element was included to cover the wsse:Timestamp, then the layout
would need to be considered.)
A timestamp (P023) is required to be included in an
acceptable message.
Lines (P026)-(P034) contain an
sp:SignedEndorsingSupportingTokens element, which means that the contained
supporting token (the SAML hk Assertion) references a key that will be
“signing” (endorsing) the message signature. The token itself may also be
considered to be “signed”, because it is contained in the message sent over the
SSL link. In the case of sp:TransportBinding, there may be no actual “message
signature”, however, when a client certificate is used, the service can be
assured that the connection was set up by the client and that the SSL link
guarantees the integrity of the data that is sent on the link by the client,
while it is on the link and when it is received from the link by using the key
referenced by the token. However, it does not guarantee the integrity after the
data is received (i.e. after it is received there is no way to tell whether any
changes have been made to it since it has been received). In any event, within
this context a Signed Endorsing Supporting Token can be used to tell the
Recipient that the Issuer of the token is making claims related to the holder
of the private key that is referenced by the token, which in this case would be
the private key associated with the client certificate used to set up the SSL
link, as described further below.
Lines (P028)-(P032) contain an sp:SamlToken, which must
always be sent to the Recipient.
Line (P030) specifies that the token is of type WssSamlV20Token11,
which means that the Endorsing Supporting Token must be a SAML Version 2.0
token and it must be sent using WS-Security 1.1 using the [WSS11‑SAML1120-PROFILE]. Note that
because the SamlToken is contained in an sp:EndorsingSupportingTokens element,
that it implicitly must be a holder-of-key token as described in section 2.3
above.
Here is an example request taken from the WSS SAML Profile
InterOp [WSS11-SAML1120-INTEROP
Scenario #5] containing only minor cosmetic modifications and corrections.
(M001) <?xml
version="1.0" encoding="utf-8" ?>
(M002) <S11:Envelope
(M003) xmlns:S11="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:wsu=".../oasis-200401-wss-wssecurity-utility-1.0.xsd"
(M007) xmlns:wsse=".../oasis-200401-wss-wssecurity-secext-1.0.xsd"
(M008) xmlns:wsse11=".../oasis-wss-wssecurity-secext-1.1.xsd"
(M009) xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
(M010) xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
(M011) <S11:Header>
(M012) <wsse:Security
S11:mustUnderstand="1">
(M013) <wsu:Timestamp>
(M014) <wsu:Created>2005-03-18T19:53:13Z</wsu:Created>
(M015) </wsu:Timestamp>
(M016) <saml2:Assertion
ID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc"
(M017) IssueInstant="2005-04-17T00:46:02Z"
Version="2.0">
(M018) <saml2:Issuer>www.opensaml.org</saml2:Issuer>
(M019) <ds:Signature
xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
(M020) <ds:SignedInfo>
(M021) <ds:CanonicalizationMethod
(M022) Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
(M023) <ds:SignatureMethod
(M024) Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
(M025) <ds:Reference
URI="#_a75adf55-01d7-40cc-929f-dbd8372ebdfc">
(M026) <ds:Transforms>
(M027) <ds:Transform Algorithm=
(M028) "http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
(M029) <ds:Transform Algorithm=
(M030) "http://www.w3.org/2001/10/xml-exc-c14n#">
(M031) <InclusiveNamespaces
(M032) PrefixList="#default saml
ds xs xsi"
(M033) xmlns="http://www.w3.org/2001/10/xml-exc-c14n#"/>
(M034) </ds:Transform>
(M035) </ds:Transforms>
(M036) <ds:DigestMethod Algorithm=
(M037) "http://www.w3.org/2000/09/xmldsig#sha1"/>
(M038) <ds:DigestValue
(M039) >Kclet6XcaOgOWXM4gty6/UNdviI=</ds:DigestValue>
(M040) </ds:Reference>
(M041) </ds:SignedInfo>
(M042) <ds:SignatureValue>
(M043) hq4zk+ZknjggCQgZm7ea8fI79gJEsRy3E8LHDpYXWQIgZpkJN9CMLG8ENR4Nrw+n
(M044) 7iyzixBvKXX8P53BTCT4VghPBWhFYSt9tHWu/AtJfOTh6qaAsNdeCyG86jmtp3TD
(M045) MwuL/cBUj2OtBZOQMFn7jQ9YB7klIz3RqVL+wNmeWI4=
(M046) </ds:SignatureValue>
(M047) <ds:KeyInfo>
(M048) <ds:X509Data>
(M049) <ds:X509Certificate>
(M050) MIICyjCCAjOgAwIBAgICAnUwDQYJKoZIhvcNAQEEBQAwgakxCzAJBgNVBAYTAlVT
(M051) ...
(M052) 8I3bsbmRAUg4UP9hH6ABVq4KQKMknxu1xQxLhpR1ylGPdiowMNTrEG8cCx3w/w==
(M053) </ds:X509Certificate>
(M054) </ds:X509Data>
(M055) </ds:KeyInfo>
(M056) </ds:Signature>
(M057) <saml2:Conditions
NotBefore="2005-06-19T16:53:33.173Z"
(M058) NotOnOrAfter="2006-06-19T17:08:33.173Z"
/>
(M059) <saml2:Subject>
(M060) <saml2:NameID
(M061) Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
(M062) >uid=joe,ou=people,ou=saml-demo,o=example.com</saml2:NameID>
(M063) <saml2:SubjectConfirmation
(M064) Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key"/>
(M065) <saml2:SubjectConfirmationData
(M066) xsi:type="saml2:KeyInfoConfirmationDataType">
(M067) <ds:KeyInfo>
(M068) <ds:X509Data>
(M069) <ds:X509IssuerName>
(M070) C=ZA, ST=Western Cape, L=Cape
Town,
(M071) O=Thawte Consulting cc,
(M072) OU=Certification Services
Division,
(M073) CN=Thawte Server
CA/Email=server-certs@thawte.com
(M074) </ds:X509IssuerName>
(M075) <X509SerialNumber>12345678</X509SerialNumber>
(M076) </ds:X509Data>
(M077) </ds:KeyInfo>
(M078) </saml2:SubjectConfirmationData>
(M079) </saml2:Subject>
(M080) <saml2:AttributeStatement>
(M081) <saml2:Attribute
Name="MemberLevel">
(M082) <saml2:AttributeValue>gold</saml2:AttributeValue>
(M083) </saml2:Attribute>
(M084) <saml2:Attribute
Name="E-mail">
(M085) <saml2:AttributeValue
(M086) >joe@yahoo.com</saml2:AttributeValue>
(M087) </saml2:Attribute>
(M088) </saml2:AttributeStatement>
(M089) </saml2:Assertion>
(M090) </wsse:Security>
(M091) </S11:Header>
(M092) <S11:Body wsu:Id="MsgBody">
(M093) <ReportRequest>
(M094) <TickerSymbol>SUNW</TickerSymbol>
(M095) </ReportRequest>
(M096) </S11:Body>
(M097) </S11:Envelope>
Lines (M002)-(M097) contain the SOAP:Envelope, which
contains the SOAP:Header (M011)‑(M091) and the SOAP:Body (M092)-(M096).
Lines (M012)-(M090) contain the wsse:Security header, which
contains a wsu:Timestamp (M013)‑(M015) and a saml2:Assertion
(M016)-(M089).
The wsu:Timestamp (M013)-(M015) may be considered to be
virtually signed by the client certificate as explained above and in section
2.3.
The saml2:Assertion was issued by an IssuingAuthority
identified in the saml2:Issuer element (M018).
The saml2:Issuer has used the private key of its enterprise
certificate to produce the ds:Signature element (M019)-(M056) that is an
enveloped-signature (M028) that covers its parent XML element, the
saml2:Assertion (M016)-(M089). The ds:KeyInfo (M047)-(M055) within this
ds:Signature contains an actual copy of the Issuer’s enterprise certificate,
that the Recipient can verify for authenticity to establish that this message
is in conformance with any agreement the RelyingParty may have with the
IssuingAuthority. The details of this verification are outside the scope of
this document, however they involve the structures and systems the RelyingParty
has in place recognize and verify certificates and signatures it receives that
are associated with business arrangements with the holders of the private keys
of those certificates.
The saml2:Subject of the saml2:Assertion is contained in
lines (M059)-(M079). Within the saml2:Subject is the saml2:NameID
(M060)-(M062), which contains the official name of the Subject of this
Assertion and this entity may be considered to the Requestor associated with
this request.
The saml2:SubjectConfirmation (M063)-(M064) has Method
“holder-of-key” which implies that there is a saml2:SubjectConfirmationData
element (M065)-(M078) which will contain information that identifies a signing
key that the Initiator will use to bind this saml2:Assertion to a message that
is associated with the Requestor. In this context, the Initiator is acting as
“attesting entity” with respect to the Subject as defined in [SAML20], which means that the Initiator is authorized by
the IssuingAuthority to present saml2:Assertions pertaining to saml2:Subjects
to Recipients/RelyingParties. In this example there is a ds:KeyInfo
(M067)-(M077) that identifies a specific certificate (ds:X509IssuerName
(M069)-(M074) and ds:SerialNumber (M075)) that the Initiator must prove
possession of the associated private key to verify this message. In this policy
that private key is the one associated with the client certificate that the
Initiator is required to use (P008).
The saml2:AttributeStatement (M080)-(M088) contains some
information about the Subject that is officially being provided in this
saml2:Assertion by the IssuingAuthority that may have some significance to the
Relying Party in terms of determining whether access is granted for this
request.
Here the message and SAML Assertion are signed using a key
derived from the ephemeral key K. The ephemeral key is encrypted using the
Recipient’s public key for the request input message and the same shared
ephemeral key, K, is encrypted using the Initiators public key for the response
output message.
Alternatively, derived keys can be used for each of signing
and encryption operations.
In this scenario the Authority is the Initiator who signs
the message with the generated key. In order to establish trust in the
generated key, the Initiator must sign the message signature with a second
signature using an X509 certificate, which is indicated as the
EndorsingSupportingToken. This X509 certificate establishes the Initiator as
the SAML Authority.
(Note: there are instructive similarities and differences
between this example and example 2.3.1.4, where the difference is that: here
the binding is symmetric and the WSS1.1 is used, whereas in 2.3.1.4 the binding
is asymmetric and WSS1.0 is used. One particular item is that in 2.3.1.4 an
EndorsingSupportingToken is not needed because in 2.3.1.4 the asymmetric
binding uses X.509 certificates, which may be inherently trusted as opposed to
the ephemeral key, K, used here.)
(P001) <wsp:Policy
wsu:Id="WSS11SamlWithCertificates_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:RequireDerivedKeys
wsp:Optional="true"/>
(P012) <sp:WssX509V3Token10/>
(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:SignedSupportingTokens>
(P032) <wsp:Policy>
(P033) <sp:SamlToken sp:IncludeToken=
"http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
(P034) <wsp:Policy>
(P035) <sp:WssSamlV11Token11/>
(P036) </wsp:Policy>
(P037) </sp:SamlToken>
(P038) </wsp:Policy>
(P039) </sp:SignedSupportingTokens>
(P040) <sp:EndorsingSupportingTokens>
(P041) <wsp:Policy>
(P042) <sp:X509Token
sp:IncludeToken=”AlwaysToRecipient">
(P043) <wsp:Policy>
(P044) <sp:WssX509V3Token11/>
(P045) </wsp:Policy>
(P046) </sp:X509Token>
(P047) </wsp:Policy>
(P048) </sp:EndorsingSupportingTokens>
(P049) <sp:Wss11>
(P050) <wsp:Policy>
(P051) <sp:MustSupportRefKeyIdentifier/>
(P052) <sp:MustSupportRefIssuerSerial/>
(P053) <sp:MustSupportRefThumbprint/>
(P054) <sp:MustSupportRefEncryptedKey/>
(P055) </wsp:Policy>
(P056) </sp:Wss11>
(P057) </wsp:All>
(P058) </wsp:ExactlyOne>
(P059) </wsp:Policy>
(P060)
(P061) <wsp:Policy
wsu:Id="SamlForCertificates_input_policy">
(P062) <wsp:ExactlyOne>
(P063) <wsp:All>
(P064) <sp:SignedParts>
(P065) <sp:Body/>
(P066) </sp:SignedParts>
(P067) <sp:EncryptedParts>
(P068) <sp:Body/>
(P069) </sp:EncryptedParts>
(P070) </wsp:All>
(P071) </wsp:ExactlyOne>
(P072) </wsp:Policy>
(P073)
(P074) <wsp:Policy
wsu:Id="SamlForCertificate_output_policy">
(P075) <wsp:ExactlyOne>
(P076) <wsp:All>
(P077) <sp:SignedParts>
(P078) <sp:Body/>
(P079) </sp:SignedParts>
(P080) <sp:EncryptedParts>
(P081) <sp:Body/>
(P082) </sp:EncryptedParts>
(P083) </wsp:All>
(P084) </wsp:ExactlyOne>
(P085) </wsp:Policy>
Lines (P001)-(P059) contain the policy that requires all the
contained assertions to be complied with by the Initiator. In this case there
are 4 assertions: sp:SymmetricBinding (P004)-(P030), sp:SignedSupportingTokens
(P031)-(P039), sp:EndorsingSupportingTokens (P040)-(P048), and sp:Wss11
(P049)-(P056).
The sp:SymmetricBinding assertion (P004) contains an
sp:ProtectionToken (P006)-(P016), which indicates that both the Initiator and
Recipient must use each other’s public key respectively associated with the
X509Token (P008)-(P014) associated with the respective message receiver to
encrypt the shared ephemeral symmetric key as explained at the beginning of
this section. The messages may either be encrypted and signed using keys
derived from the ephemeral key as indicated by the sp:RequireDerivedKeys
assertion (P011) or the encryption and signing can be done using the ephemeral
key itself without deriving keys, because the RequireDerivedKey assertion is an
optional requirement as indicated by the wsp:Optional attribute on line (P011).
The sp:SignedSupportingTokens assertion (P031) contains an
sp:SamlToken assertion (P033)-(P037), which indicates that a signed SAML
Assertion must always be included in the Initiator’s request to the Recipient
(AlwaysToRecipient (P033)). This SAML Assertion must be included in the
WS-Security header and referenced and signed as described in the WS-Security
1.1 Profile for SAML [WSS11-SAML1120-PROFILE]
as indicated by the sp:WssSamlV11Token11 assertion (P036), which indicates the
SAML 1.1 option in that profile (as opposed to the SAML 2.0 option, which would
have been indicated by sp:WssSamlV20Token11).
The sp:EndorsingSupportingToken assertion (P040) is needed
because there are no guarantees that the ephemeral key, K, is still being used
by the Initiator with whom the Recipient would have collaborated originally to
establish the ephemeral key as a shared secret. The purpose of the endorsing
token is to sign the signature made by the ephemeral key, using the Initiator’s
private key, which will explicitly guarantee the content of this particular
Initiator request. The endorsing token in this policy is an sp:X509Token
(P042)-(P046), which, in particular, is an sp:WssX509V3Token11, which must be
used in accordance with the WS-Security 1.1 Profile for X509 Tokens [WSS11-X509-PROFILE]. (Note: it may be the case
that this X509 certificate is the same X509 certificate referred to in the
ProtectionToken assertion (P012). However, it is important to keep in mind that
line (P012) only indicates that the Initiator’s token will be used by the
Recipient to protect the ephemeral key for the symmetric binding. Therefore,
the fact that the token is identified in line (P012) as an sp:X509V3Token10 is
not directly related to the fact that the same key may be used for the
additional purpose of explicitly signing the request message).
The sp:Wss11 assertion (P049-P056) indicates that
WS-Security 1.1 constructs are accepted. (Note also that eitherWssX509V3Token10
or WssX509V3Token11 may be used with the Wss11 since both WS-Security 1.0 and
WS-Security 1.1 Profiles are supported by WS-Security 1.1)
There are also 2 Policys, one each for the input message and
the output message, each of which contains an assertion indicating the message
SOAP Body must be signed (P064)-(P066) for the input message and (P077)-(P079)
for the output message, and each contains an assertion that the message SOAP
Body must be encrypted (P067)-(P069) for the input message and (P080)-(P082)
for the output message.
The following is a sample request that is compliant with
this policy.
(M001) <?xml
version="1.0" encoding="utf-8" ?>
(M002) <S12:Envelope
(M003) xmlns:S12="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-wss-wssecurity-secext-1.0.xsd"
(M007) xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
(M008) xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
(M009) xmlns:xenc="..."
(M010) xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">
(M011) <S12:Header>
(M012) <wsse:Security
S12:mustUnderstand="1">
(M013) <wsu:Timestamp
wsu:Id="timestamp">
(M014) <wsu:Created>2003-03-18T19:53:13Z</wsu:Created>
(M015) </wsu:Timestamp>
(M016) <xenc:EncryptedKey Id="encKey"
>
(M017) <xenc:EncryptionMethod
Algorithm="...#rsa-oaep-mgf1p">
(M018) <ds:DigestMethod
Algorithm="...#sha1"/>
(M019) </xenc:EncryptionMethod>
(M020) <ds:KeyInfo >
(M021) <wsse:SecurityTokenReference >
(M022) <wsse:KeyIdentifier
EncodingType="...#Base64Binary"
ValueType="...#ThumbprintSHA1">c2...=</wsse:KeyIdentifier>
(M023) </wsse:SecurityTokenReference>
(M024) </ds:KeyInfo>
(M025) <xenc:CipherData>
(M026) <xenc:CipherValue>TE...=</xenc:CipherValue>
(M027) </xenc:CipherData>
(M028) </xenc:EncryptedKey>
(M029) <n1:ReferenceList
xmlns:n1=".../xmlenc#">
(M030) <n1:DataReference
URI="#encBody"/>
(M031) </n1:ReferenceList>
(M032) <saml:Assertion
(M033) AssertionID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc"
(M034) IssueInstant="2003-04-17T00:46:02Z"
(M035) Issuer="www.opensaml.org"
(M036) MajorVersion="1"
(M037) MinorVersion="1">
(M038) <saml:Conditions
(M039) NotBefore="2002-06-19T16:53:33.173Z"
(M040) NotOnOrAfter="2002-06-19T17:08:33.173Z"/>
(M041) <saml:AttributeStatement>
(M042) <saml:Subject>
(M043) <saml:NameIdentifier
(M044) NameQualifier="www.example.com"
(M045) Format="">
(M046) uid=joe,ou=people,ou=saml-demo,o=example.com
(M047) </saml:NameIdentifier>
(M048) <saml:SubjectConfirmation>
(M049) <saml:ConfirmationMethod>
(M050) urn:oasis:names:tc:SAML:1.0:cm:sender-vouches
(M051) </saml:ConfirmationMethod>
(M052) </saml:SubjectConfirmation>
(M053) </saml:Subject>
(M054) <saml:Attribute>
(M055) ...
(M056) </saml:Attribute>
(M057) ...
(M058) </saml:AttributeStatement>
(M059) </saml:Assertion>
(M060) <wsse:SecurityTokenReference
wsu:id="STR1">
(M061) <wsse:KeyIdentifier
wsu:id="..."
(M062) ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID">
(M063) _a75adf55-01d7-40cc-929f-dbd8372ebdfc
(M064) </wsse:KeyIdentifier>
(M065) </wsse:SecurityTokenReference>
(M066) <wsse:BinarySecurityToken
(M067) wsu:Id="attesterCert"
(M068) ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
(M069) EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">
(M070) MIIEZzCCA9CgAwIBAgIQEmtJZc0...
(M071) </wsse:BinarySecurityToken>
(M072) <ds:Signature
wsu:Id="message-signature">
(M073) <ds:SignedInfo>
(M074) <ds:CanonicalizationMethod
(M075) Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
(M076) <ds:SignatureMethod
(M077) Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
(M078) <ds:Reference URI="#STR1">
(M079) <ds:Transforms>
(M080) <ds:Transform
(M081) Algorithm="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#STR-Transform">
(M082) <wsse:TransformationParameters>
(M083) <ds:CanonicalizationMethod
(M084) Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
(M085) </wsse:TransformationParameters>
(M086) </ds:Transform>
(M087) </ds:Transforms>
(M088) <ds:DigestMethod
(M089) Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
(M090) <ds:DigestValue>...</ds:DigestValue>
(M091) </ds:Reference>
(M092) <ds:Reference
URI="#MsgBody">
(M093) <ds:DigestMethod
(M094) Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
(M095) <ds:DigestValue>...</ds:DigestValue>
(M096) </ds:Reference>
(M097) <ds:Reference
URI="#timestamp">
(M098) <ds:DigestMethod
(M099) Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
(M0100) <ds:DigestValue>...</ds:DigestValue>
(M0101) </ds:Reference>
(M0102) </ds:SignedInfo>
(M0103) <ds:SignatureValue>HJJWbvqW9E84vJVQk...</ds:SignatureValue>
(M0104) <ds:KeyInfo>
(M0105) <wsse:SecurityTokenReference
wsu:id="STR2">
(M0106) <wsse:Reference
URI="#enckey" ValueType="../EncryptedKey"/>
(M0107) </wsse:SecurityTokenReference>
(M0108) </ds:KeyInfo>
(M0109) </ds:Signature>
(M0110) <ds:Signature
wsu:Id="endorsing-signature">
(M0111) <ds:SignedInfo>
(M0112) ...
(M0113) <ds:Reference
URI="#message-signature">
(M0114) ...
(M0115) </ds:Reference>
(M0116) </ds:SignedInfo>
(M0117) <ds:SignatureValue>Bu
...=</ds:SignatureValue>
(M0118) <ds:KeyInfo>
(M0119) <wsse:SecurityTokenReference >
(M0120) <wsse:Reference
URI="#attesterCert" ValueType="...#X509v3"/>
(M0121) </wsse:SecurityTokenReference>
(M0122) </ds:KeyInfo>
(M0123) </ds:Signature>
(M0124) </wsse:Security>
(M0125) </S12:Header>
(M0126) <S12:Body wsu:Id="MsgBody">
(M0127) <xenc:EncryptedData Id="encBody"
Type="...#Content" MimeType="text/xml"
Encoding="UTF-8" >
(M0128) <xenc:EncryptionMethod Algorithm="http...#aes256-cbc"/>
(M0129) <ds:KeyInfo >
(M0130) <wsse:SecurityTokenReference>
(M0131) <wsse:Reference URI="#enckey"
ValueType=".../EncryptedKey"/>
(M0132) </wsse:SecurityTokenReference>
(M0133) </ds:KeyInfo>
(M0134) <xenc:CipherData>
(M0135) <xenc:CipherValue>70...=</xenc:CipherValue>
(M0136) </xenc:CipherData>
(M0137) </xenc:EncryptedData>
(M0138) </S12:Body>
(M0139) </S12:Envelope>
The message above contains a request compliant with the
policy described in (P001)-(P072), which includes the endpoint policy and the
input policy.
Lines (M016)-(M028) contain an xenc:EncryptedKey element
that contains an Initiator-generated symmetric signing and encryption key, K,
that can be used to decrypt the xenc:EncryptedData contained in the SOAP
S12:Body (M0126) as indicated by the wsse:SecurityTokenReference (M0130)-(M0132)
that uses a direct reference to the Id of the xenc:EncryptedKey, “encKey” on
lines (M0131) and (M016).
The xenc:EncryptedKey contains a dsig KeyInfo (M020)-(M024)
reference to the Thumbprint of the Recipient’s public X509 certificate (M022).
This complies with the policy (P068) that requires the sp:Body to of the input
message to be encrypted. It also complies with the policy (P013) to protect
using encryption based on X509 token and to refer to it by Thumbprint (P014).
Lines (M029)-(M031) contain an xenc:ReferenceList referring
to the xenc:EncryptedData in the S12:Body (M0127)-(M0137).
Lines (M032)-(M059) contain the saml:Assertion as a
SignedSupportingToken as required by the endpoint policy (P035). A
saml:Assertion used as a SignedSupportingToken uses the “sender-vouches”
ConfirmationMethod (M049)-(M051) as described in the introductory section 2.3.
Lines (M060)-(M065) contain a WS-Security
wsse:SecurityTokenReference that has a KeyIdentifier of ValueType
“…1.0#SAMLAssertionID”, which indicates a SAML 1.1 Assertion as described in
the WS-Security 1.1 [SAML1120_TOKEN_PROFILE].
Lines (M066)-(M071) contain a wsse:BinarySecurityToken that
contains the Initiator’s X509 certificate for use as an EndorsingSupportingToken
as required by line (P042) of the sp:EndorsingSupportingTokens assertion
(P040)-(P048).
Lines (M072)-(M0109) contain the message signature. The dsig
Signature covers the following:
Ř The
SAML Assertion using the ds:Reference (M078)-(M091), which uses the WS-Security
STR-Transform technique to refer to the SAML Assertion indirectly through the
wsse:SecurityTokenReference (M060) described above. This signature is required
by the sp:SignedSupportingTokens assertion (P031)-(P039).
Ř The
message sp:Body (M0126)-(M0138) using the ds:Reference (M092)-(M096) as
required by the input message policy (P065).
Ř The
message wsu:Timestamp (M013)-(M015) using the ds:Reference (M097)-(M0101) as
required by the endpoint policy (P027).
The key used to sign the message signature is referenced in
the dsig KeyInfo (M0104)-(M0108), which contains a SecurityTokenReference with
a direct URI reference to the xenc:EncryptedKey, “encKey”, which contains the
Initiator-generated signing and encryption key, K, as described above.
Lines (M0110)-(M0123) contain the endorsing signature. The
dsig endorsing Signature covers the following:
Ř The
message Signature (M072)-(M0109) using the ds:Reference (M0113)-(M0115), which
is a direct URI reference to the Id “message-signature” on line (M072).
This signature is required by the policy
EndorsingSupportingTokens assertion (P040)-(P048) to be an X509 certificate
(P044). The dsig KeyInfo (M0118)-(M0122) contains a WS-Security
SecurityTokenReference with a direct URI to the Initiator’s X509 certificate on
line (M066)-(M071) with Id = “attesterCert”.
Lines (M0127)-(M0137) contain the xenc:EncryptedData, which
contains the SOAP S12:Body message payload that is encrypted using the
encryption key, K, contained in the xenc:EncryptedKey CipherValue (M026), which
can only be decrypted using the Recipient’s X509 certificate referred to by
ThumbprintSHA1 on line (M022).
This scenario is based on WS-SX Interop Scenarios Phase 2
(October 31, 2006) [WSSX-WSTR-WSSC-INTEROP]
Scenario 5 (Client and STS: Mutual Certificate WSS1.1 (section 3.5 of
interop ref), Client and Service: Issued SAML 1.1 Token for Certificate WSS1.1
(section 4.3 of interop ref)).
In this scenario, the service specifies that the client must
obtain an IssuedToken from a designated Securtiy Token Service (STS), which
must be a SAML 1.1 Assertion. The Assertion contains an ephemeral key K2
in an EncryptedKey element encrypted using service’s certificate. The client
also obtains the same ephemeral key K2 from the RequestedProofToken returned by
the STS. The body of the message from the client to the service is signed using
DKT1(K2), encrypted using DKT2(K2), and endorsed using DKT3(K2), which are keys
the client derives from K2 using the algorithm specified in section 7 of [WS-SecureConversation]. The response from the
service is also signed using derived keys. In a simpler alternative, ephemeral
key K itself could be used for message protection.
Note: In this scenario, in terms of Figure 1 [Figure01],
the STS (Issuing Authority) is the Issuer of the SAML 1.1 holder-of-key
Assertion that contains the ephemeral symmetric key K2. The service (combined
Recipient/RelyingParty) can trust the client (combined Initiator/Requestor)
that uses the ephemeral symmetric key K2 obtained from the RequestedProofToken,
because the same key gets delivered to the service in the SAML 1.1
holder-of-key Assertion, which is signed by the trusted Authority.
This scenario is a 2-step sequence from a WS-SP perspective.
These 2 steps will be described at a high level first in order to explain the
context for the policies and messages that follow.
In step 1 the following takes place:
- the
client accesses the service’s WS‑SP policy (P001 -> P116 below),
and determines that it needs to use an IssuedToken from a Security Token
Service (STS), specified in the policy.
This IssuedToken will serve as the basis of trust by the service.
Effectively, the service only trusts the client because the client is able
to obtain the IssuedToken from the STS.
To complete step 1,
the client will then do the following:
- the
client will access the STS and process the STS policy (PSTS-001 ->
PSTS-098 below)
- based
on the STS policy, the client will send a request to the STS for an
IssuedToken (MSTS‑001 -> MSTS‑0231 below)
- the
STS will send a response to the client containing the IssuedToken, which
in this example is a SAML 1.1 holder-of-key Assertion (RSTS-001 ->
RSTS-0263 below)
In step 2 the following takes place:
·
because the client now has the IssuedToken it is
now able fulfill the requirements of the service’s WS-SP policy (P001-P116
below) that it accessed in step 1
·
based on the service’s policy the clients sends
a request to the service (M001-M0229 below)
·
the service will send a response to the client
containing the requested resource data (R001-R0153 below)
As an aid to understanding the security properties of the
policies and messages in this example, the following is a list of identifiers
used in the text descriptions to reference the cryptographic keys that are
called for in the policies and used in the messages in this example:
Ř X509T1:
Client’s (Requestor/Initiator) X509 certificate used for authentication to the
STS.
Ř X509T2:
STS’ (Issuing Authority) X509 certificate used to encrypt keys sent to STS,
used to authenticate STS to Service.
Ř X509T3:
Service’s (Recipient/RelyingParty/ValidatingAuthority) X509 certificate used to
encrypt keys sent to Service.
Ř K1:
Client-generated ephemeral symmetric key for crypto communication to the STS.
Ř K2:
Client-generated ephemeral symmetric key for crypto communication between the
Client and the Service.
Ř K3:
STS-generated proof key for use by Client to authenticate with Service via
saml:Assertion.
Ř DKT1(K2):
Client-generated derived key used for signing requests to the Service.
Ř DKT2(K2):
Client-generated derived key used for encrypting requests to the Service.
Ř DKT3(K3):
Client-generated derived key used for endorsing signed requests to the Service.
Ř DKT4(K2):
Service-generated derived key used for encrypting responses to the Client.
Ř DKT5(K2):
Service-generated derived key used for signing responses to the Client.
Here is the WS-SP Policy that the Service presents to a
Client:
(P001) <wsp:Policy
wsu:Id="Service5-Policy"
(P002)
(P003) xmlns:wsp="http://www.w3.org/ns/ws-policy"
(P004) xmlns:sp"..."
(P005)
(P006) xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
(P007) >
(P008) <wsp:ExactlyOne>
(P009) <wsp:All>
(P010) <sp:SymmetricBinding>
(P011) <wsp:Policy>
(P012) <sp:ProtectionToken>
(P013) <wsp:Policy>
(P014) <sp:X509Token IncludeToken=
(P015) "http://docs.oasis‑open.org/ws‑sx/ws‑securitypolicy/200702/IncludeToken/Never">
(P016) <wsp:Policy>
(P017) <sp:RequireDerivedKeys/>
(P018) <sp:RequireThumbprintReference/>
(P019) <sp:WssX509V3Token10/>
(P020) </wsp:Policy>
(P021) </sp:X509Token>
(P022) </wsp:Policy>
(P023) </sp:ProtectionToken>
(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:SymmetricBinding>
(P038) <sp:EndorsingSupportingTokens>
(P039) <wsp:Policy>
(P040) <sp:IssuedToken IncludeToken=
(P041) "http://docs.oasis‑open.org/ws‑sx/ws‑securitypolicy/200702/IncludeToken/AlwaysToRecipient">
(P042) <sp:Issuer>
(P043) <a:Address>http://example.com/STS</a:Address>
(P044) </sp:Issuer>
(P045) <sp:RequestSecurityTokenTemplate>
(P046) <t:TokenType
(P047) >http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1</t:TokenType>
(P048) <t:KeyType
(P049) >http://docs.oasis‑open.org/ws‑sx/ws‑trust/200512/SymmetricKey</t:KeyType>
(P050) <t:KeySize>256</t:KeySize>
(P051) <t:CanonicalizationAlgorithm
(P052) >http://www.w3.org/2001/10/xml-exc-c14n#</t:CanonicalizationAlgorithm>
(P053) <t:EncryptionAlgorithm
(P054) >http://www.w3.org/2001/04/xmlenc#aes256-cbc</t:EncryptionAlgorithm>
(P055) <t:EncryptWith
(P056) >http://www.w3.org/2001/04/xmlenc#aes256-cbc</t:EncryptWith>
(P057) <t:SignWith
(P058) >http://www.w3.org/2000/09/xmldsig#hmac-sha1</t:SignWith>
(P059) </sp:RequestSecurityTokenTemplate>
(P060) <wsp:Policy>
(P061) <sp:RequireDerivedKeys/>
(P062) <sp:RequireInternalReference/>
(P063) </wsp:Policy>
(P064) </sp:IssuedToken>
(P065) </wsp:Policy>
(P066) </sp:EndorsingSupportingTokens>
(P067) <sp:Wss11>
(P068) <wsp:Policy>
(P069) <sp:MustSupportRefKeyIdentifier/>
(P070) <sp:MustSupportRefIssuerSerial/>
(P071) <sp:MustSupportRefThumbprint/>
(P072) <sp:MustSupportRefEncryptedKey/>
(P073) <sp:RequireSignatureConfirmation/>
(P074) </wsp:Policy>
(P075) </sp:Wss11>
(P076) <sp:Trust13>
(P077) <wsp:Policy>
(P078) <sp:MustSupportIssuedTokens/>
(P079) <sp:RequireClientEntropy/>
(P080) <sp:RequireServerEntropy/>
(P081) </wsp:Policy>
(P082) </sp:Trust13>
(P083) </wsp:All>
(P084) </wsp:ExactlyOne>
(P085) </wsp:Policy>
(P086) <wsp:Policy
wsu:Id="InOut-Policy"
(P087)
(P088) xmlns:wsp="http://www.w3.org/ns/ws-policy"
(P089) xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
(P090)
(P091) xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
(P092) <wsp:ExactlyOne>
(P093) <wsp:All>
(P094) <sp:SignedParts>
(P095) <sp:Body/>
(P096) <sp:Header Name="To"
(P097) Namespace="http://www.w3.org/2005/08/addressing"/>
(P098) <sp:Header Name="From"
(P099) Namespace="http://www.w3.org/2005/08/addressing"/>
(P0100) <sp:Header Name="FaultTo"
(P0101) Namespace="http://www.w3.org/2005/08/addressing"/>
(P0102) <sp:Header Name="ReplyTo"
(P0103) Namespace="http://www.w3.org/2005/08/addressing"/>
(P0104) <sp:Header
Name="MessageID"
(P0105) Namespace="http://www.w3.org/2005/08/addressing"/>
(P0106) <sp:Header
Name="RelatesTo"
(P0107) Namespace="http://www.w3.org/2005/08/addressing"/>
(P0108) <sp:Header Name="Action"
(P0109) Namespace="http://www.w3.org/2005/08/addressing"/>
(P0110) </sp:SignedParts>
(P0111) <sp:EncryptedParts>
(P0112) <sp:Body/>
(P0113) </sp:EncryptedParts>
(P0114) </wsp:All>
(P0115) </wsp:ExactlyOne>
(P0116) </wsp:Policy>
When a Client encounters the above Service Policy, it
determines that it must obtain an IssuedToken from the designated Issuer. After
obtaining the IssuedToken, the client may send the request in accordance with
the rest of the policy. Details of the Service Policy follow. The STS Policy
its details follow after the Service Policy.
Lines (P001)-(P085) above contain the Service Endpoint
wsp:Policy, which contains a wsp:All assertion that requires all 4 of its
contained assertions to be complied with: sp:SymmetricBinding (P010)-(P037),
sp:EndorsingSupportingTokens (P038)-(P066), sp:Wss11 (P067)-(P075), and
sp:Trust13 (P076)-(P082).
Lines (P010)-(P037) contain the sp:SymmetricBinding
assertion that requires that derived keys (DKT1, DKT2, DKT3) be used to
protect the message (P017) and that the ephemeral key (K2) used to derive these
keys be encrypted using the service’s X509 certificate (X509T3) as specified by
the sp:X509Token assertion (P014)-(P021), which also indicates that the X509
token, itself should not be sent (P015), but that a Thumbprint reference (P018)
to it be sent. Finally, the sp:SymmetricBinding specifies that the sp:Basic256
sp:AlgorithmSuite be used (P024)-(P028), that sp:Strict sp:Layout be used
(P029)-(P033), that an sp:Timestamp be included (P034), and that only the
complete message Body and Headers be signed (P035), where the Headers part
means that only direct child elements of the WS-Security SOAP header element be
signed.
Lines (P038)-(P066) contain the sp:EndorsingSupportingTokens
assertion that an sp:IssuedToken (P040)-(P064) be used to sign the message
signature and that the IssuedToken must be included with the request
(P040)-(P041). Lines (P042)-(P044) specify the address of the
SecurityTokenService (STS) from which the IssuedToken must be obtained. Lines
(P045)-(P059) contain an sp:RequestSecurityTokenTemplate (P046)-(P058) which
contains explicit WS-Trust elements that the client should directly copy to a
t:SecondaryParameters element to include with the WS-Trust t:RequestSecurityToken to the STS to obtain
the sp:IssuedToken. Of particular interest here is that the t:TokenType
(P046)-(P047) requested is a SAML 1.1 Assertion, which will be used to contain
the ephemeral symmetric key (K2) (P048)-(P049). K2 will be used for communication
between the Client and the Service. K2 will be encrypted by the STS using the
Service’s X509 certificate (X509T3). The Client is also informed by the
IssuedToken assertion that the IssuedToken may only be referenced internally
within the message (P062) and that the ephemeral key (K2) associated with the
IssuedToken be used by the Client to derive the keys (DKT1(K2), DKT2(K2),
DKT3(K2)) used in the Client’s request to the Service.
Lines (P067)-(P075) contain the sp:Wss11 assertion
that indicates that WS-Security 1.1 will be used, which includes Wss11-only
features such as Thumbprint (P073), EncryptedKey (P074), and
SignatureConfirmation (P075).
Lines (P076)-(P082) contain the sp:Trust13 assertion
that indicates the Client should expect to use WS-Trust 1.3 (WSTRUST)
to obtain the IssuedToken from the STS.
Lines (P086)-(P0116) contain the operation input and
output policies that the client should use to determine what parts of the
messages are to be signed (P094)-(P0110) and encrypted (P0111)-(P0113).
Here is the WS-SP Policy that the STS presents to a Client:
(PSTS-001) <wsp:Policy
wsu:Id="STS5-Policy"
(PSTS-002)
(PSTS-003) xmlns:wsp="http://www.w3.org/ns/ws-policy"
(PSTS-004) xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
(PSTS-005)
(PSTS-006) xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
(PSTS-007) >
(PSTS-008) <wsp:ExactlyOne>
(PSTS-009) <wsp:All>
(PSTS-010) <sp:SymmetricBinding>
(PSTS-011) <wsp:Policy>
(PSTS-012) <sp:ProtectionToken>
(PSTS-013) <wsp:Policy>
(PSTS-014) <sp:X509Token IncludeToken=
(PSTS-015) "http://docs.oasis‑open.org/ws‑sx/ws‑securitypolicy/200702/IncludeToken/Never">
(PSTS-016) <wsp:Policy>
(PSTS-017) <sp:RequireThumbprintReference/>
(PSTS-018) <sp:WssX509V3Token10/>
(PSTS-019) </wsp:Policy>
(PSTS-020) </sp:X509Token>
(PSTS-021) </wsp:Policy>
(PSTS-022) </sp:ProtectionToken>
(PSTS-023) <sp:AlgorithmSuite>
(PSTS-024) <wsp:Policy>
(PSTS-025) <sp:Basic256/>
(PSTS-026) </wsp:Policy>
(PSTS-027) </sp:AlgorithmSuite>
(PSTS-028) <sp:Layout>
(PSTS-029) <wsp:Policy>
(PSTS-030) <sp:Strict/>
(PSTS-031) </wsp:Policy>
(PSTS-032) </sp:Layout>
(PSTS-033) <sp:IncludeTimestamp/>
(PSTS-034) <sp:OnlySignEntireHeadersAndBody/>
(PSTS-035) </wsp:Policy>
(PSTS-036) </sp:SymmetricBinding>
(PSTS-037) <sp:EndorsingSupportingTokens>
(PSTS-038) <wsp:Policy>
(PSTS-039) <sp:X509Token IncludeToken=
(PSTS-040) "http://docs.oasis‑open.org/ws‑sx/ws‑securitypolicy/200702/IncludeToken/AlwaysToRecipient">
(PSTS-041) <wsp:Policy>
(PSTS-042) <sp:RequireThumbprintReference/>
(PSTS-043) <sp:WssX509V3Token10/>
(PSTS-044) </wsp:Policy>
(PSTS-045) </sp:X509Token>
(PSTS-046) </wsp:Policy>
(PSTS-047) </sp:EndorsingSupportingTokens>
(PSTS-048) <sp:Wss11>
(PSTS-049) <wsp:Policy>
(PSTS-050) <sp:MustSupportRefKeyIdentifier/>
(PSTS-051) <sp:MustSupportRefIssuerSerial/>
(PSTS-052) <sp:MustSupportRefThumbprint/>
(PSTS-053) <sp:MustSupportRefEncryptedKey/>
(PSTS-054) <sp:RequireSignatureConfirmation/>
(PSTS-055) </wsp:Policy>
(PSTS-056) </sp:Wss11>
(PSTS-057) <sp:Trust13>
(PSTS-058) <wsp:Policy>
(PSTS-059) <sp:MustSupportIssuedTokens/>
(PSTS-060) <sp:RequireClientEntropy/>
(PSTS-061) <sp:RequireServerEntropy/>
(PSTS-062) </wsp:Policy>
(PSTS-063) </sp:Trust13>
(PSTS-064) </wsp:All>
(PSTS-065) </wsp:ExactlyOne>
(PSTS-066) </wsp:Policy>
(PSTS-067) <wsp:Policy
wsu:Id="InOut-Policy"
(PSTS-068)
(PSTS-069) xmlns:wsp="http://www.w3.org/ns/ws-policy"
(PSTS-070) xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
(PSTS-071)
(PSTS-072) xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
(PSTS-073) >
(PSTS-074) <wsp:ExactlyOne>
(PSTS-075) <wsp:All>
(PSTS-076) <sp:SignedParts>
(PSTS-077) <sp:Body/>
(PSTS-078) <sp:Header Name="To"
(PSTS-079) Namespace="http://www.w3.org/2005/08/addressing"/>
(PSTS-080) <sp:Header Name="From"
(PSTS-081) Namespace="http://www.w3.org/2005/08/addressing"/>
(PSTS-082) <sp:Header Name="FaultTo"
(PSTS-083) Namespace="http://www.w3.org/2005/08/addressing"/>
(PSTS-084) <sp:Header Name="ReplyTo"
(PSTS-085) Namespace="http://www.w3.org/2005/08/addressing"/>
(PSTS-086) <sp:Header
Name="MessageID"
(PSTS-087) Namespace="http://www.w3.org/2005/08/addressing"/>
(PSTS-088) <sp:Header
Name="RelatesTo"
(PSTS-089) Namespace="http://www.w3.org/2005/08/addressing"/>
(PSTS-090) <sp:Header Name="Action"
(PSTS-091) Namespace="http://www.w3.org/2005/08/addressing"/>
(PSTS-092) </sp:SignedParts>
(PSTS-093) <sp:EncryptedParts>
(PSTS-094) <sp:Body/>
(PSTS-095) </sp:EncryptedParts>
(PSTS-096) </wsp:All>
(PSTS-097) </wsp:ExactlyOne>
(PSTS-098) </wsp:Policy>
Above is the STS Policy that the Client will encounter when
obtaining the IssuedToken required by the Service Policy. This policy is quite
similar in detail to the Service Policy and therefore only the differences that
are noteworthy will be discussed in the details below.
Similar to the Service Policy, the STS endpoint Policy
contains 4 assertions to be complied with: sp:SymmetricBinding
(PSTS-010)-(PSTS-036), sp:EndorsingSupportingTokens (PSTS-037)-(PSTS-047),
sp:Wss11 (PSTS-048)-(PSTS-056), and sp:Trust13 (PSTS-057)-(PSTS-063).
Lines (PSTS-010)-(PSTS-036) contain the sp:SymmetricBinding
assertion, where the main difference from the previous policy is that here
the sp:ProtectionToken is an sp:X509Token that will be used to encrypt the
ephemeral client-generated key (K1) that will be used for Client-STS
communication. Derived keys will not be required in this communication.
Lines (PSTS-037)-(PSTS-047) contain the sp:EndorsingSupportingTokens
assertion, which in this case contains an sp:X509Token assertion (PSTS-039)-(PSTS-045)
that requires the Client to include (PSTS‑040) its X509 certificate,
which must be used to sign the message signature. The STS uses this mechanism
to authenticate the Client.
The sp:Wss11 assertion (PSTS-048)-(PSTS-056), sp:Trust13
assertion (PSTS-057)-(PSTS-063) and the operation input and output
policies (PSTS-067)-(PSTS-098) are the same as those described for the
Service policy above (P067)-(P0116).
Below are included sample messages that comply with the
above policies. The messages are presented in the same order that they would be
used in a real scenario and therefore the Client-STS request
(MSTS-001)-(MSTS-0231) and response (RSTS-001)-(RSTS-0263) are presented first,
which are then followed by the Client-Service request (M001-M229) and response
(R001)-(R153).
Here is an example Client request to the STS:
(MSTS-001) <s:Envelope
xmlns:s=http://schemas.xmlsoap.org/soap/envelope
(MSTS-002) xmlns:a=http://www.w3.org/2005/08/addressing
(MSTS-003) xmlns:e=http://www.w3.org/2001/04/xmlenc#
(MSTS-004) xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
(MSTS-005) xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" >
(MSTS-006) <s:Header>
(MSTS-007) <a:Action s:mustUnderstand="1"
u:Id="_3">
(MSTS-008) http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue
(MSTS-009) </a:Action>
(MSTS-010) <a:MessageID u:Id="_4">
(MSTS-011) urn:uuid:04d386bf-f850-459e-918b-ad80f3d1e088
(MSTS-012) </a:MessageID>
(MSTS-013) <a:ReplyTo u:Id="_5">
(MSTS-014) <a:Address>
(MSTS-015) http://www.w3.org/2005/08/addressing/anonymous
(MSTS-016) </a:Address>
(MSTS-017) </a:ReplyTo>
(MSTS-018) <a:To s:mustUnderstand="1" u:Id="_6">
(MSTS-019) http://server.example.com/STS/Scenarios5-6
(MSTS-020) </a:To>
(MSTS-021) <o:Security
s:mustUnderstand="1">
(MSTS-022) <u:Timestamp
(MSTS-023) u:Id="uuid-40f5bac7-f9af-4384-80db-cfab34263849-10">
(MSTS-024) <u:Created>2005-10-25T00:47:36.144Z</u:Created>
(MSTS-025) <u:Expires>2005-10-25T00:52:36.144Z</u:Expires>
(MSTS-026) </u:Timestamp>
(MSTS-027) <e:EncryptedKey
(MSTS-028) Id="uuid-40f5bac7-f9af-4384-80db-cfab34263849-9">
(MSTS-029) <e:EncryptionMethod Algorithm=
(MSTS-030) "http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"/>
(MSTS-031) <KeyInfo
xmlns="http://www.w3.org/2000/09/xmldsig#">
(MSTS-032) <o:SecurityTokenReference>
(MSTS-033) <o:KeyIdentifier ValueType=
(MSTS-034) "http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd#ThumbprintSHA1">
(MSTS-035) W+rgYBmLmVEG//scD7Vo8Kq5G7I=
(MSTS-036) </o:KeyIdentifier>
(MSTS-037) </o:SecurityTokenReference>
(MSTS-038) </KeyInfo>
(MSTS-039) <e:CipherData>
(MSTS-040) <e:CipherValue>
(MSTS-041) <!--base64 encoded cipher-->
(MSTS-042) </e:CipherValue>
(MSTS-043) </e:CipherData>
(MSTS-044) <e:ReferenceList>
(MSTS-045) <e:DataReference URI="#_2"/>
(MSTS-046) </e:ReferenceList>
(MSTS-047) </e:EncryptedKey>
(MSTS-048) <o:BinarySecurityToken
(MSTS-049)
u:Id="uuid-40f5bac7-f9af-4384-80db-cfab34263849-6"
(MSTS-050) ValueType=
(MSTS-051) "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
(MSTS-052) EncodingType=
(MSTS-053) "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">
(MSTS-054)
(MSTS-055) MIIDDDCCAfSgAwIBAgIQM6YEf7FVYx/tZyEXgVComTANBgkqhkiG9w0BAQUFADAwMQ4w
(MSTS-056) DAYDVQQKDAVPQVNJUzEeMBwGA1UEAwwVT0FTSVMgSW50ZXJvcCBUZXN0IENBMB4XDTA1
(MSTS-057) MDMxOTAwMDAwMFoXDTE4MDMxOTIzNTk1OVowQjEOMAwGA1UECgwFT0FTSVMxIDAeBgNV
(MSTS-058) BAsMF09BU0lTIEludGVyb3AgVGVzdCBDZXJ0MQ4wDAYDVQQDDAVBbGljZTCBnzANBgkq
(MSTS-059) hkiG9w0BAQEFAAOBjQAwgYkCgYEAoqi99By1VYo0aHrkKCNT4DkIgPL/SgahbeKdGhrb
(MSTS-060) u3K2XG7arfD9tqIBIKMfrX4Gp90NJa85AV1yiNsEyvq+mUnMpNcKnLXLOjkTmMCqDYbb
(MSTS-061) kehJlXPnaWLzve+mW0pJdPxtf3rbD4PS/cBQIvtpjmrDAU8VsZKT8DN5Kyz+EzsCAwEA
(MSTS-062) AaOBkzCBkDAJBgNVHRMEAjAAMDMGA1UdHwQsMCowKKImhiRodHRwOi8vaW50ZXJvcC5i
(MSTS-063) YnRlc3QubmV0L2NybC9jYS5jcmwwDgYDVR0PAQH/BAQDAgSwMB0GA1UdDgQWBBQK4l0T
(MSTS-064) UHZ1QV3V2QtlLNDm+PoxiDAfBgNVHSMEGDAWgBTAnSj8wes1oR3WqqqgHBpNwkkPDzAN
(MSTS-065) BgkqhkiG9w0BAQUFAAOCAQEABTqpOpvW+6yrLXyUlP2xJbEkohXHI5OWwKWleOb9hlkh
(MSTS-066) WntUalfcFOJAgUyH30TTpHldzx1+vK2LPzhoUFKYHE1IyQvokBN2JjFO64BqukCKnZhl
(MSTS-067) dLRPxGhfkTdxQgdf5rCK/wh3xVsZCNTfuMNmlAM6lOAg8QduDah3WFZpEA0s2nwQaCNQ
(MSTS-068) TNMjJC8tav1CBr6+E5FAmwPXP7pJxn9Fw9OXRyqbRA4v2y7YpbGkG2GI9UvOHw6SGvf4
(MSTS-069) FRSthMMO35YbpikGsLix3vAsXWWi4rwfVOYzQK0OFPNi9RMCUdSH06m9uLWckiCxjos0
(MSTS-070) FQODZE9l4ATGy9s9hNVwryOJTw==
(MSTS-071) </o:BinarySecurityToken>
(MSTS-072) <Signature Id="_0"
xmlns="http://www.w3.org/2000/09/xmldsig#">
(MSTS-073) <SignedInfo>
(MSTS-074) <CanonicalizationMethod
Algorithm=
(MSTS-075) "http://www.w3.org/2001/10/xml-exc-c14n#"/>
(MSTS-076) <SignatureMethod Algorithm=
(MSTS-077) "http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>
(MSTS-078) <Reference URI="#_1">
(MSTS-079) <Transforms>
(MSTS-080) <Transform Algorithm=
(MSTS-081) "http://www.w3.org/2001/10/xml-exc-c14n#"/>
(MSTS-082) </Transforms>
(MSTS-083) <DigestMethod Algorithm=
(MSTS-084) "http://www.w3.org/2000/09/xmldsig#sha1"/>
(MSTS-085) <DigestValue>VX1fCPwCzVsSc1hZf0BSbCgW2hM=</DigestValue>
(MSTS-086) </Reference>
(MSTS-087) <Reference URI="#_3">
(MSTS-088) <Transforms>
(MSTS-089) <Transform Algorithm=
(MSTS-090) "http://www.w3.org/2001/10/xml-exc-c14n#"/>
(MSTS-091) </Transforms>
(MSTS-092) <DigestMethod Algorithm=
(MSTS-093) "http://www.w3.org/2000/09/xmldsig#sha1"/>
(MSTS-094) <DigestValue>FwiFAUuqNDo9SDkk5A28Mg7Pa8Q=</DigestValue>
(MSTS-095) </Reference>
(MSTS-096) <Reference URI="#_4">
(MSTS-097) <Transforms>
(MSTS-098) <Transform Algorithm=
(MSTS-099) "http://www.w3.org/2001/10/xml-exc-c14n#"/>
(MSTS-0100) </Transforms>
(MSTS-0101) <DigestMethod Algorithm=
(MSTS-0102) "http://www.w3.org/2000/09/xmldsig#sha1"/>
(MSTS-0103) <DigestValue>oM59PsOTpmrDdOcwXYQzjVUl0xw=</DigestValue>
(MSTS-0104) </Reference>
(MSTS-0105) <Reference URI="#_5">
(MSTS-0106) <Transforms>
(MSTS-0107) <Transform Algorithm=
(MSTS-0108) "http://www.w3.org/2001/10/xml-exc-c14n#"/>
(MSTS-0109) </Transforms>
(MSTS-0110) <DigestMethod Algorithm=
(MSTS-0111) "http://www.w3.org/2000/09/xmldsig#sha1"/>
(MSTS-0112) <DigestValue>KIK3vklFN1QmMdQkplq2azfzrzg=</DigestValue>
(MSTS-0113) </Reference>
(MSTS-0114) <Reference URI="#_6">
(MSTS-0115) <Transforms>
(MSTS-0116) <Transform Algorithm=
(MSTS-0117) "http://www.w3.org/2001/10/xml-exc-c14n#"/>
(MSTS-0118) </Transforms>
(MSTS-0119) <DigestMethod Algorithm=
(MSTS-0120) "http://www.w3.org/2000/09/xmldsig#sha1"/>
(MSTS-0121) <DigestValue>RJEe3hrcyCD6PzFJo6fyut6biVg=</DigestValue>
(MSTS-0122) </Reference>
(MSTS-0123) <Reference
(MSTS-0124) URI="#uuid-40f5bac7-f9af-4384-80db-cfab34263849-10">
(MSTS-0125) <Transforms>
(MSTS-0126) <Transform Algorithm=
(MSTS-0127) "http://www.w3.org/2001/10/xml-exc-c14n#"/>
(MSTS-0128) </Transforms>
(MSTS-0129) <DigestMethod Algorithm=
(MSTS-0130) "http://www.w3.org/2000/09/xmldsig#sha1"/>
(MSTS-0131) <DigestValue>zQdN5XpejfqXn0WKo0m51ZYiasE=</DigestValue>
(MSTS-0132) </Reference>
(MSTS-0133) </SignedInfo>
(MSTS-0134) <SignatureValue
(MSTS-0135) >iHGJ+xV2VZTjMlRc7AQJrwLY/aM=</SignatureValue>
(MSTS-0136) <KeyInfo>
(MSTS-0137) <o:SecurityTokenReference>
(MSTS-0138) <o:Reference
(MSTS-0139) ValueType=
(MSTS-0140) "http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd#EncryptedKey"
(MSTS-0141) URI="#uuid-40f5bac7-f9af-4384-80db-cfab34263849-9"/>
(MSTS-0142) </o:SecurityTokenReference>
(MSTS-0143) </KeyInfo>
(MSTS-0144) </Signature>
(MSTS-0145) <Signature
xmlns="http://www.w3.org/2000/09/xmldsig#">
(MSTS-0146) <SignedInfo>
(MSTS-0147) <CanonicalizationMethod Algorithm=
(MSTS-0148) "http://www.w3.org/2001/10/xml-exc-c14n#"/>
(MSTS-0149) <SignatureMethod Algorithm=
(MSTS-0150) "http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
(MSTS-0151) <Reference URI="#_0">
(MSTS-0152) <Transforms>
(MSTS-0153) <Transform Algorithm=
(MSTS-0154) "http://www.w3.org/2001/10/xml-exc-c14n#"/>
(MSTS-0155) </Transforms>
(MSTS-0156) <DigestMethod Algorithm=
(MSTS-0157) "http://www.w3.org/2000/09/xmldsig#sha1"/>
(MSTS-0158) <DigestValue>UZKtShk8q6iu9WR5uQZp04iAitg=</DigestValue>
(MSTS-0159) </Reference>
(MSTS-0160) </SignedInfo>
(MSTS-0161) <SignatureValue>
(MSTS-0162)
Ovxdeg4KQcfQlT/hEBJz+Z8dQUAfChaWIcmG3xGLZYcc8tbmCtZFuQz9tnW35Lmst6vI
(MSTS-0163) RefuPA7ewRLYORAOjf92SxMbeVTlrIxQbIQNw0bs4SBSLfAo14=
(MSTS-0164) </SignatureValue>
(MSTS-0165) <KeyInfo>
(MSTS-0166) <o:SecurityTokenReference>
(MSTS-0167) <o:Reference
(MSTS-0168) ValueType=
(MSTS-0169) "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
(MSTS-0170) URI="#uuid-40f5bac7-f9af-4384-80db-cfab34263849-6"/>
(MSTS-0171) </o:SecurityTokenReference>
(MSTS-0172) </KeyInfo>
(MSTS-0173) </Signature>
(MSTS-0174) </o:Security>
(MSTS-0175) </s:Header>
(MSTS-0176) <s:Body u:Id="_1">
(MSTS-0177) <e:EncryptedData
(MSTS-0178)
Id="_2"
(MSTS-0179) Type="http://www.w3.org/2001/04/xmlenc#Content">
(MSTS-0180) <e:EncryptionMethod Algorithm=
(MSTS-0181) "http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
(MSTS-0182) <e:CipherData>
(MSTS-0183) <e:CipherValue>
(MSTS-0184) <!-- base64 encoded octets with
encrypted RST request-->
(MSTS-0185) <!-- Unencrypted form: -->
(MSTS-0186) <!—
(MSTS-0187) <t:RequestSecurityToken>
(MSTS-0188) <t:RequestType>
(MSTS-0189) http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue
(MSTS-0190) </t:RequestType>
(MSTS-0191) <wsp:AppliesTo
(MSTS-0192) xmlns:wsp="http://www.w3.org/ns/ws-policy">
(MSTS-0193) <a:EndpointReference
(MSTS-0194) xmlns:a="http://www.w3.org/2005/08/addressing">
(MSTS-0195) <a:Address
(MSTS-0196) >http://server.example.com/Scenarios5</a:Address>
(MSTS-0197) </a:EndpointReference>
(MSTS-0198) </wsp:AppliesTo>
(MSTS-0199) <t:Entropy>
(MSTS-0200) <t:BinarySecret
(MSTS-0201)
u:Id="uuid-4acf589c-0076-4a83-8b66-5f29341514b7-3"
(MSTS-0202) Type=
(MSTS-0203) "http://docs.oasis-open.org/ws-sx/ws-trust/200512/Nonce"
(MSTS-0204) >Uv38QLxDQM9gLoDZ6OwYDiFk094nmwu3Wmay7EdKmhw=</t:BinarySecret>
(MSTS-0205) </t:Entropy>
(MSTS-0206) <t:KeyType>
(MSTS-0207) http://docs.oasis‑open.org/ws‑sx/ws‑trust/200512/SymmetricKey
(MSTS-0208) </t:KeyType>
(MSTS-0209) <t:KeySize>256</t:KeySize>
(MSTS-0210) <t:ComputedKeyAlgorithm>
(MSTS-0211) http://docs.oasis-open.org/ws-sx/ws-trust/200512/CK/PSHA1
(MSTS-0212) </t:ComputedKeyAlgorithm>
(MSTS-0213) <t:SecondaryParameters>
(MSTS-0214) <t:TokenType
(MSTS-0215) >http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1</t:TokenType>
(MSTS-0216) <t:KeyType
(MSTS-0217) >http://docs.oasis‑open.org/ws‑sx/ws‑trust/200512/SymmetricKey</t:KeyType>
(MSTS-0218) <t:KeySize>256</t:KeySize>
(MSTS-0219) <t:CanonicalizationAlgorithm
(MSTS-0220) >http://www.w3.org/2001/10/xml‑exc‑c14n#</t:CanonicalizationAlgorithm>
(MSTS-0221) <t:EncryptionAlgorithm
>http://www.w3.org/2001/04/xmlenc#aes256-cbc</t:EncryptionAlgorithm>
(MSTS-0222) <t:EncryptWith
>http://www.w3.org/2001/04/xmlenc#aes256‑cbc</t:EncryptWith>
(MSTS-0223) <t:SignWith
>http://www.w3.org/2000/09/xmldsig#hmac‑sha1</t:SignWith>
(MSTS-0224) </t:SecondaryParameters>
(MSTS-0225) </t:RequestSecurityToken>
(MSTS-0226) -->
(MSTS-0227) </e:CipherValue>
(MSTS-0228) </e:CipherData>
(MSTS-0229) </e:EncryptedData>
(MSTS-0230) </s:Body>
(MSTS-0231) </s:Envelope>
The message above is a request by the Client to the STS in
compliance with the STS policy (PSTS-001)-(PSTS-098). Salient features of this
message appropriate to the compliance are described below.
Lines (MSTS-027)-(MSTS-047) contain the e:EncryptedKey
element, which contains the encrypted client-generated ephemeral key (K1)
(MSTS-039)-(MSTS-043). K1 is encrypted using the STS certificate (X509T2) which
is specified by its Thumbprint identifier in the WS-Security
o:SecurityTokenRefernece (MSTS-032)-(MSTS-037). The e:ReferenceList in the
e:EncryptedKey (MSTS-044)-(MSTS-046) indicates that the encryption key K1 is
used to directly encrypt the message Body which is referenced by the e:DataReference
URI=”#_2” (MSTS-045).
Lines (MSTS-048)-(MSTS-071) contain a WS-Security
o:BinarySecurityToken, which contains the Client’s public X509 certificate
(X509T1) that is required for Client authentication to the STS by the
sp:EndorsingToken in the STS policy (PSTS-037)-(PSTS-047).
Lines (MSTS-072)-(MSTS-0144) contain the WS-SP message
signature in an XML Digital Signature (dsig) element (namespace = …xmldsig
(MSTS-072)). The elements covered by the dsig Signature are identified in the
dsig Reference elements:
Ř dsig
Reference (MSTS-078) covers the s:Body (Id=”_1” (MSTS-0176))
Ř dsig
Reference (MSTS-087) covers the a:Action (Id=”_3” (MSTS-007))
Ř dsig
Reference (MSTS-096) covers the a:MessageID (Id=”_4” (MSTS-010))
Ř dsig
Reference (MSTS-0105) covers the a:ReplyTo (Id=”_5” (MSTS-013))
Ř dsig
Reference (MSTS-0114) covers the a:To (Id=”_6” (MSTS-018))
Ř dsig
Reference (MSTS-0123) covers the u:Timestamp (Id=”uuid … 3849-10” (MSTS-023))
all as required by the STS Input and Output Policy
sp:SignedParts (PSTS-076)-(PSTS-092), which covers the first 5 elements above
(note: if an element is not present that is identified in the policy (such as
FaultTo or RelatesTo) it obviously is not required to be signed, but if present
must be signed). The u:Timestamp is required to be signed by its presence in
the STS endpoint policy (PSTS-033).
Lines (MSTS-0136)-(MSTS-0143) of the WS-SP message
signature contain the dsig KeyInfo, which contains a WS-Security
o:SecurityTokenReference, which contains an o:Reference to the signing validation
key (i.e. the key which can be used to verify this dsig:Signature), which in
this case is contained in the e:EncryptedKey element (Id=”uuid … 3849-9”
(MSTS-027)) that was described above. Note: at this point to verify the
Signature, the STS will decrypt the e:EncryptedKey using the private key from
the STS certificate, X509T2, which will produce the client-generated ephemeral
signing and encryption key, K1, which, in turn, may be used to validate the
message signature. Note also: at this point the STS only knows whether the data
covered by the message signature is valid or not, but the STS does not yet know
the identity of the entity that actually sent the data. That is covered next:
Lines (MSTS-0145)-(MSTS-0173) contain the WS-SP endorsing
signature, also in an XML Digital Signature element. The endorsing
signature only covers one element, the message signature element, which is
identified by the dsig Reference element:
Ř dsig
Reference (MSTS-0151) covers the dsig Signature (Id=”_0” (MSTS-072))
as required by the STS endpoint policy
sp:EndorsingSupportingTokens (PSTS-037)-(PSTS-047).
Lines (MSTS-0165)-(MSTS-0174) of the WS-SP endorsing
signature contain the dsig KeyInfo, which contains a WS-Security
o:SecurityTokenReference, which contains an o:Reference to the signing
validation key, which in this case is in the o:BinarySecurityToken element
(Id=”uuid … 3849-6” (MSTS‑048)) that was also described above. Note: now
the STS finally has the credentials necessary to authenticate the Client. The
STS will generally have an identity database of trusted clients and their
associated X509 certificates. If a client successfully produces a signature
that can be validated by the associated certificate in the STS database, which
would have to match the certificate in the o:BinarySecurityToken element, then
the client is presumed to be authenticated to the level of security provided by
this mechanism (strong single factor authentication).
Lines (MSTS-0176)-(MSTS-0230) contain the SOAP message
s:Body element, which contains its payload in an e:EncryptedData element
(MSTS-0177)-(MSTS-0229). This e:EncryptedData element was identified above by
its Id=”_2” in the e:ReferenceList (MSTS-044) of the e:EncryptedKey that was
processed by the STS above to obtain the client ephemeral key (K1), with which
this e:EncryptedData can be decrypted. Generally, when the e:EncryptedKey is
processed, this e:EncryptedData would have been decrypted at that time and made
available for processing in the event of successful Client authentication as described
above. Because the contents of this payload are relevant to the rest of this
example, the contents of the payload will be briefly described.
Lines (MSTS-0187)-(MSTS-0225) contain the decrypted
contents of the SOAP message s:Body element, which contain a WS-Trust
t:RequestSecurityToken element. The t:RequestType (MSTS-0189) is “…Issue”,
which means this is a request to issue a security token, which is the main
service of the STS. The WS-Policy wsp:AppliesTo element (MSTS-0191)-(MSTS-0198)
contains the a:Address of the service, to which the Client is requesting
access, a service which the STS is presumably responsible for authenticating
and equipping validated clients to enable their access to. In this case the
service is identified by the URL http://server.example.com/Scenarios5, which
was part of the WS-SX Interop [WSSX-WSTR-WSSC-INTEROP].
Lines (MSTS-0199)-(MSTS-0205) contain the Client entropy
required by the Service policy (P079), which is entropy data provided by the
Client to aid in production of the ephemeral key, K2, that will be used for
Client-Service communication. Lines (MSTS-0206)-(MSTS-0212) contain additional
parameters used in the WS-Trust interface to the STS that will not be described
here.
Lines (MSTS-0213)-(MSTS-0224) contain the WS-Trust
t:SecondaryParameters, which contains the contents of the Service policy’s
RequestSecurityTokenTemplate (P045)-(P059), which the Service requires that the
Client pass to the STS as described above. The t:SecondaryParameters contains
the information the Service has requested about the SAML 1.1 IssuedToken that
the STS is being requested to create and deliver to the Client in order the
enable the Client to access the Service successfully.
Assuming everything above has executed successfully, the STS
will then issue the SAML 1.1 IssuedToken and return it to the Client in a
WS-Trust t:RequestSecurityTokenResponse that is described next.
Here is an example STS response to the above Client request:
(RSTS-001) <s:Envelope
xmlns:s=http://schemas.xmlsoap.org/soap/envelope
(RSTS-002) xmlns:a=http://www.w3.org/2005/08/addressing
(RSTS-003) xmlns:e=http://www.w3.org/2001/04/xmlenc#
(RSTS-004) xmlns:k="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd"
(RSTS-005) xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
(RSTS-006) xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" >
(RSTS-007) <s:Header>
(RSTS-008) <a:Action s:mustUnderstand="1"
u:Id="_4">
(RSTS-009) http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTRC/IssueFinal
(RSTS-010) </a:Action>
(RSTS-011) <a:RelatesTo u:Id="_5">
(RSTS-012) urn:uuid:04d386bf-f850-459e-918b-ad80f3d1e088
(RSTS-013) </a:RelatesTo>
(RSTS-014) <a:To s:mustUnderstand="1"
u:Id="_6">
(RSTS-015) http://www.w3.org/2005/08/addressing/anonymous
(RSTS-016) </a:To>
(RSTS-017) <o:Security s:mustUnderstand="1">
(RSTS-018) <u:Timestamp
(RSTS-019) u:Id="uuid-0c947d47-f527-410a-a674-753a9d7d97f7-18">
(RSTS-020) <u:Created>2005-10-25T00:47:38.718Z</u:Created>
(RSTS-021) <u:Expires>2005-10-25T00:52:38.718Z</u:Expires>
(RSTS-022) </u:Timestamp>
(RSTS-023) <e:ReferenceList>
(RSTS-024) <e:DataReference URI="#_3"/>
(RSTS-025) </e:ReferenceList>
(RSTS-026) <k:SignatureConfirmation u:Id="_0"
(RSTS-027) Value="iHGJ+xV2VZTjMlRc7AQJrwLY/aM="/>
(RSTS-028) <k:SignatureConfirmation u:Id="_1"
(RSTS-029)
Value=
(RSTS-030)
"Ovxdeg4KQcfQlT/hEBJz+Z8dQUAfChaWIcmG3xGLZYcc8tbmCtZFuQz9tnW35
(RSTS-031) Lmst6vRefuPA7ewRLYORAOjf92SxMbeVTlrIxQbIQNw0bs4SBSLfAo14="/>
(RSTS-032) <Signature
xmlns="http://www.w3.org/2000/09/xmldsig#">
(RSTS-033) <SignedInfo>
(RSTS-034) <CanonicalizationMethod Algorithm=
(RSTS-035) "http://www.w3.org/2001/10/xml-exc-c14n#"/>
(RSTS-036) <SignatureMethod Algorithm=
(RSTS-037) "http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>
(RSTS-038) <Reference URI="#_2">
(RSTS-039) <Transforms>
(RSTS-040) <Transform Algorithm=
(RSTS-041) "http://www.w3.org/2001/10/xml-exc-c14n#"/>
(RSTS-042) </Transforms>
(RSTS-043) <DigestMethod Algorithm=
(RSTS-044) "http://www.w3.org/2000/09/xmldsig#sha1"/>
(RSTS-045) <DigestValue>kKx5bpLLlyucgXQ6exv/PbjsFlA=</DigestValue>
(RSTS-046) </Reference>
(RSTS-047) <Reference URI="#_4">
(RSTS-048) <Transforms>
(RSTS-049) <Transform Algorithm=
(RSTS-050) "http://www.w3.org/2001/10/xml-exc-c14n#"/>
(RSTS-051) </Transforms>
(RSTS-052) <DigestMethod Algorithm=
(RSTS-053) "http://www.w3.org/2000/09/xmldsig#sha1"/>
(RSTS-054) <DigestValue>LB+VGn4fP2z45jg0Mdzyo8yTAwQ=</DigestValue>
(RSTS-055) </Reference>
(RSTS-056) <Reference URI="#_5">
(RSTS-057) <Transforms>
(RSTS-058) <Transform Algorithm=
(RSTS-059) "http://www.w3.org/2001/10/xml-exc-c14n#"/>
(RSTS-060) </Transforms>
(RSTS-061) <DigestMethod Algorithm=
(RSTS-062) "http://www.w3.org/2000/09/xmldsig#sha1"/>
(RSTS-063) <DigestValue>izHLxm6V4Lc3PSs9Y6VRv3I5RPw=</DigestValue>
(RSTS-064) </Reference>
(RSTS-065) <Reference URI="#_6">
(RSTS-066) <Transforms>
(RSTS-067) <Transform Algorithm=
(RSTS-068) "http://www.w3.org/2001/10/xml-exc-c14n#"/>
</Transforms>
(RSTS-069) <DigestMethod Algorithm=
(RSTS-070) "http://www.w3.org/2000/09/xmldsig#sha1"/>
(RSTS-071) <DigestValue>6LS4X08vC/GMGay2vwmD8fL7J2U=</DigestValue>
(RSTS-072) </Reference>
(RSTS-073) <Reference
(RSTS-074) URI="#uuid-0c947d47-f527-410a-a674-753a9d7d97f7-18">
(RSTS-075) <Transforms>
(RSTS-076) <Transform Algorithm=
(RSTS-077) "http://www.w3.org/2001/10/xml-exc-c14n#"/>
(RSTS-078) </Transforms>
(RSTS-079) <DigestMethod Algorithm=
(RSTS-080) "http://www.w3.org/2000/09/xmldsig#sha1"/>
(RSTS-081) <DigestValue>uXGSpCBfbT1fLNBLdGMgy6DGDio=</DigestValue>
(RSTS-082) </Reference>
(RSTS-083) <Reference URI="#_0">
(RSTS-084) <Transforms>
(RSTS-085) <Transform Algorithm=
(RSTS-086) "http://www.w3.org/2001/10/xml-exc-c14n#"/>
(RSTS-087) </Transforms>
(RSTS-088) <DigestMethod Algorithm=
(RSTS-089) "http://www.w3.org/2000/09/xmldsig#sha1"/>
(RSTS-090) <DigestValue>z86w+GrzqRZF56ciuz6ogzVXAUA=</DigestValue>
(RSTS-091) </Reference>
(RSTS-092) <Reference URI="#_1">
(RSTS-093) <Transforms>
(RSTS-094) <Transform Algorithm=
(RSTS-095) "http://www.w3.org/2001/10/xml-exc-c14n#"/>
(RSTS-096) </Transforms>
(RSTS-097) <DigestMethod Algorithm=
(RSTS-098) "http://www.w3.org/2000/09/xmldsig#sha1"/>
(RSTS-099) <DigestValue>Z9TfD20a5aGngsyOPEvQuE0urvQ=</DigestValue>
(RSTS-0100) </Reference>
(RSTS-0101) </SignedInfo>
(RSTS-0102) <SignatureValue>Q7HhboPUaZyXqUKgG7NCYlhMTXI=</SignatureValue>
(RSTS-0103) <KeyInfo>
(RSTS-0104) <o:SecurityTokenReference
(RSTS-0105) k:TokenType="http://docs.oasis-open.org/wss/
(RSTS-0106) oasis-wss-soap-message-security-1.1#EncryptedKey"
(RSTS-0107) xmlns:k="http://docs.oasis-open.org/wss/
(RSTS-0108) oasis-wss-wssecurity-secext-1.1.xsd">
(RSTS-0109) <o:KeyIdentifier ValueType=
(RSTS-0110) "http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd#EncryptedKeySHA1">
(RSTS-0111) CixQW5yEb3mw6XYqD8Ysvrf8cwI=
(RSTS-0112) </o:KeyIdentifier>
(RSTS-0113) </o:SecurityTokenReference>
(RSTS-0114) </KeyInfo>
(RSTS-0115) </Signature>
(RSTS-0116) </o:Security>
(RSTS-0117) </s:Header>
(RSTS-0118) <s:Body u:Id="_2">
(RSTS-0119) <e:EncryptedData Id="_3"
(RSTS-0120) Type="http://www.w3.org/2001/04/xmlenc#Content">
(RSTS-0121) <e:EncryptionMethod Algorithm=
(RSTS-0122) "http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
(RSTS-0123) <KeyInfo
xmlns="http://www.w3.org/2000/09/xmldsig#">
(RSTS-0124) <o:SecurityTokenReference
(RSTS-0125) k:TokenType="http://docs.oasis-open.org/wss/
(RSTS-0126) oasis-wss-soap-message-security-1.1#EncryptedKey"
(RSTS-0127) xmlns:k="http://docs.oasis-open.org/wss/
(RSTS-0128) oasis-wss-wssecurity-secext-1.1.xsd">
(RSTS-0129) <o:KeyIdentifier ValueType=
(RSTS-0130) "http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd#EncryptedKeySHA1">
(RSTS-0131) CixQW5yEb3mw6XYqD8Ysvrf8cwI=
(RSTS-0132) </o:KeyIdentifier>
(RSTS-0133) </o:SecurityTokenReference>
(RSTS-0134) </KeyInfo>
(RSTS-0135) <e:CipherData>
(RSTS-0136) <e:CipherValue>
(RSTS-0137) <!--base64 encoded octets of
encrypted RSTR-->
(RSTS-0138) <!—
(RSTS-0139) <t:RequestSecurityTokenResponseCollection>
(RSTS-0140) <t:RequestSecurityTokenResponse>
(RSTS-0141) <t:TokenType>
(RSTS-0142) http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1
(RSTS-0143) </t:TokenType>
(RSTS-0144) <t:KeySize>256</t:KeySize>
(RSTS-0145) <t:RequestedAttachedReference>
(RSTS-0146) <o:SecurityTokenReference>
(RSTS-0147) <o:KeyIdentifier ValueType=
(RSTS-0148) "http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID">
(RSTS-0149)
uuid-8222b7a2-3874-4884-bdb5-9c2ddd4b86b5-16
(RSTS-0150) </o:KeyIdentifier>
(RSTS-0151) </o:SecurityTokenReference>
(RSTS-0152) </t:RequestedAttachedReference>
(RSTS-0153) <t:RequestedUnattachedReference>
(RSTS-0154) <o:SecurityTokenReference>
(RSTS-0155) <o:KeyIdentifier ValueType=
(RSTS-0156) "http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID">
(RSTS-0157) uuid-8222b7a2-3874-4884-bdb5-9c2ddd4b86b5-16
(RSTS-0158) </o:KeyIdentifier>
(RSTS-0159) </o:SecurityTokenReference>
(RSTS-0160) </t:RequestedUnattachedReference>
(RSTS-0161) <t:Lifetime>
(RSTS-0162) <u:Created>2005-10-24T20:19:26.526Z</u:Created>
(RSTS-0163) <u:Expires>2005-10-25T06:24:26.526Z</u:Expires>
(RSTS-0164) </t:Lifetime>
(RSTS-0165) <t:RequestedSecurityToken>
(RSTS-0166) <saml:Assertion
MajorVersion="1" MinorVersion="1"
(RSTS-0167)
AssertionID="uuid-8222b7a2-3874-4884-bdb5-9c2ddd4b86b5-16"
(RSTS-0168) Issuer="Test STS" IssueInstant="2005-10-24T20:24:26.526Z"
(RSTS-0169) xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">
(RSTS-0170) <saml:Conditions
NotBefore="2005-10-24T20:19:26.526Z"
(RSTS-0171) NotOnOrAfter="2005-10-25T06:24:26.526Z">
(RSTS-0172) <saml:AudienceRestrictionCondition>
(RSTS-0173) <saml:Audience
(RSTS-0174) >http://server.example.com/Scenarios5</saml:Audience>
(RSTS-0175) </saml:AudienceRestrictionCondition>
(RSTS-0176) </saml:Conditions>
(RSTS-0177) <saml:Advice>
(RSTS-0178) </saml:Advice>
(RSTS-0179) <saml:AttributeStatement>
(RSTS-0180) <saml:Subject>
(RSTS-0181) <saml:SubjectConfirmation>
(RSTS-0182) <saml:ConfirmationMethod>
(RSTS-0183) urn:oasis:names:tc:SAML:1.0:cm:holder-of-key
(RSTS-0184) </saml:ConfirmationMethod>
(RSTS-0185) <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
(RSTS-0186) <e:EncryptedKey
(RSTS-0187) xmlns:e="http://www.w3.org/2001/04/xmlenc#">
(RSTS-0188) <e:EncryptionMethod
Algorithm=
(RSTS-0189) "http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p">
(RSTS-0190) </e:EncryptionMethod>
(RSTS-0191) <KeyInfo>
(RSTS-0192) <o:SecurityTokenReference
xmlns:o=
(RSTS-0193) "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
(RSTS-0194) <o:KeyIdentifier
ValueType=
(RSTS-0195) "http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd#ThumbprintSHA1">
(RSTS-0196) NQM0IBvuplAtETQvk+6gn8C13wE=
(RSTS-0197) </o:KeyIdentifier>
(RSTS-0198) </o:SecurityTokenReference>
(RSTS-0199) </KeyInfo>
(RSTS-0200) <e:CipherData>
(RSTS-0201) <e:CipherValue>
(RSTS-0202) EEcYjwNoYcJ+20xTYE5e/fixl5KOgzgrfaYAxkDFv/VXiuKfl084h8PmogTfM+azcgAf
(RSTS-0203) mArVQvOyKWXRb5vmXYfVHLlhZTbXacy+nowSUNnEjp37VDbI3RJ5k6tBHF+ow0NM/P6G
(RSTS-0204) PNZ9ZqJi11GDgWJkFsJzNZXNbbMgwuFu3cA=</e:CipherValue>
(RSTS-0205) </e:CipherData>
(RSTS-0206) </e:EncryptedKey>
(RSTS-0207) </KeyInfo>
(RSTS-0208) </saml:SubjectConfirmation>
(RSTS-0209) </saml:Subject>
(RSTS-0210) </saml:AttributeStatement>
(RSTS-0211) <Signature
xmlns="http://www.w3.org/2000/09/xmldsig#">
(RSTS-0212) <SignedInfo>
(RSTS-0213) <CanonicalizationMethod
Algorithm=
(RSTS-0214) "http://www.w3.org/2001/10/xml-exc-c14n#">
(RSTS-0215) </CanonicalizationMethod>
(RSTS-0216) <SignatureMethod Algorithm=
(RSTS-0217) "http://www.w3.org/2000/09/xmldsig#rsa-sha1">
(RSTS-0218) </SignatureMethod>
(RSTS-0219) <Reference
(RSTS-0220) URI="#uuid-8222b7a2-3874-4884-bdb5-9c2ddd4b86b5-16">
(RSTS-0221) <Transforms>
(RSTS-0222) <Transform Algorithm=
(RSTS-0223) "http://www.w3.org/2000/09/xmldsig#enveloped-signature">
(RSTS-0224) </Transform>
(RSTS-0225) <Transform Algorithm=
(RSTS-0226) "http://www.w3.org/2001/10/xml-exc-c14n#">
(RSTS-0227) </Transform>
(RSTS-0228) </Transforms>
(RSTS-0229) <DigestMethod Algorithm=
(RSTS-0230) "http://www.w3.org/2000/09/xmldsig#sha1">
(RSTS-0231) </DigestMethod>
(RSTS-0232) <DigestValue
(RSTS-0233) >7nHBrFPsm+LEFAoV4NoQPoEl5Lk=</DigestValue>
(RSTS-0234) </Reference>
(RSTS-0235) </SignedInfo>
(RSTS-0236) <SignatureValue
(RSTS-0237) >TugV4pTIwCH87bLD4jiMgVGtkbRBt1tRlHXJArL34A/YfA4AnGBLXB4pJdUsUxMUtbQ
(RSTS-0238) l4PoGgEsdLNg8C77peARELGP1/Tqw7T3u5zBYHxCHCiV2FWBBfeOmwJmqoaBf8XZJ4Al
(RSTS-0239) yqPq61P61jrQjZJafpHuYpAZnZQSvsiJaBPQ=</SignatureValue>
(RSTS-0240) <KeyInfo>
(RSTS-0241) <o:SecurityTokenReference
xmlns:o=
(RSTS-0242) "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
(RSTS-0243) <o:KeyIdentifier ValueType=
(RSTS-0244) http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd#ThumbprintSHA1
(RSTS-0245) >W+rgYBmLmVEG//scD7Vo8Kq5G7I=</o:KeyIdentifier>
(RSTS-0246) </o:SecurityTokenReference>
(RSTS-0247) </KeyInfo>
(RSTS-0248) </Signature>
(RSTS-0249) </saml:Assertion>
(RSTS-0250) </t:RequestedSecurityToken>
(RSTS-0251) <t:RequestedProofToken>
(RSTS-0252) <t:BinarySecret
(RSTS-0253)
u:Id="uuid-8222b7a2-3874-4884-bdb5-9c2ddd4b86b5-14"
(RSTS-0254) >zT8LWAUwUrIVKA/rkCr0kxlEmKAEhcB6TGWJuAgucBM=</t:BinarySecret>
(RSTS-0255) </t:RequestedProofToken>
(RSTS-0256) </t:RequestSecurityTokenResponse>
(RSTS-0257) </t:RequestSecurityTokenResponseCollection>
(RSTS-0258) -->
(RSTS-0259) </e:CipherValue>
(RSTS-0260) </e:CipherData>
(RSTS-0261) </e:EncryptedData>
(RSTS-0262) </s:Body>
(RSTS-0263) </s:Envelope>
From here on the description will be less detailed except
where new concepts that have not been covered previously in this example. For
instance, tracing the dsig References to their associated elements and policy
requirements will not be detailed since it follows the same patterns that have
just been described in the message above.
The message above is a response from the STS to the Client
that contains the requested security tokens that the Client needs to access the
Service.
Lines (RSTS-023)-(RSTS-025) contain a standalone
e:ReferenceList that has an e:DataReference (Id=”_3”) that points to the
e:EncryptedData element in the SOAP s:Body (RSTS-0119). This e:DataReference
will be used later in the processing of this message.
Lines (RSTS-026)-(RSTS-031) contain 2 WS-Security 1.1
k:SignatureConfirmation elements that indicate to the Client that the STS
has processed the data in the Client request and in particular, has processed
the information covered by the 2 dsig Signatures in that request, that are
identified by their respective dsig SignatureValue elements (see lines
(MSTS-0134)-(MSTS-0135) and (MSTS-0161)-(MSTS-0163) in the Client request to
the STS above to compare SignatureValues).
Lines (RSTS-032)-(RSTS-0115) contain the WS-SP message
signature for this message.
Lines (RSTS-0103)-(RSTS-0114) contain the WS-SP message
signature dsig KeyInfo element, which contains a WS-Security 1.1
o:SecurityTokenReference, which contains an o:KeyIdentifier of ValueType
“ … EncryptedKeySHA1”. This is a WS-Security 1.1 construct [WS_SECURITY_11] used to reference a security token that is
not included in the message, which in this case is the Client-generated
ephemeral key, K1, that the Client used to prepare the request and delivered to
the STS in the e:EncryptedKey element in that request (MSTS-027) that was
described in detail above. The contents of the o:KeyIdentifier (RSTS-0111)
consist of the SHA1 of K1. This should be sufficient information to let the
Client know that the STS used its X509 certificate, X509T2, to decrypt K1 from
the e:EncryptedKey in the Client request, which will enable the Client to trust
the contents of this STS response.
Lines (RSTS-0119)-(RSTS-0261) contain the e:EncryptedData,
which is also provided in decrypted form for instructive purposes. As mentioned
above, this element is referred to by the standalone e:ReferenceList element in
the WS-Security header (RSTS-023) and as a result can is not tied to any
particular encryption key as described in [WS_SECURITY_11],
and since referenced will be processed by WS-Security.
Lines (RSTS-0123)-(RSTS-0134) contain the e:EncryptedData
dsig KeyInfo, which refers to the same ephemeral key, K1, as described
above for the message signature for this message.
Lines (RSTS-0140)-(RSTS-0256) contain the decrypted
WS-Trust t:RequestSecurityTokenResponse from the STS. Briefly, lines
(RSTS-0145)-(RSTS-0160) contain WS-Security o:SecurityTokenReference elements
that refer to the SAML 1.1 Assertion that is provided below. These are
convenience elements for the Client to use in subsequent message preparation
where the SAML Assertion is used.
Lines (RSTS-0165)-(RSTS-0250) contain the actual
t:RequestedSecurityToken that has been the main object of discussion up
until this point, which is the SAML 1.1 Assertion, saml:Assertion
(RSTS-0166)-(RSTS-0249), that is the sp:IssuedToken provided by the STS for the
Client to use to access the Service.
Lines (RSTS-0170)-(RSTS-0176) of the saml:Assertion contain
the saml:Conditions that specify that this token is intended only for
the Service, identified by the URL in the saml:Audience element
(RSTS-0174).
Lines (RSTS-0181)-(RSTS-0208) contain the all-important
saml:SubjectConfirmation element, which contains the STS-generated
encrypted ephemeral key, K3, that will be used by the Client and Service to
communicate securely. There are 2 copies of this key, K3, in this
t:RequestSecurityTokenResponse. This copy is for the Service. The Client’s copy
is described below. In any event, the saml:SubjectConfirmation element contains
a dsig KeyInfo (RSTS-0185)-(RSTS-0207), which contains an e:EncryptedKey
element (RSTS-0186)-(RSTS-0206), which, in turn, contains a second dsig
KeyInfo, which contains a WS-Security o:SecurityTokenReference element that
contains an o:KeyIdentifier (RSTS-0194)-(RSTS-0197) that identifies the key,
X509T3, the Service’s public X509 certificate, that can be used by the Service
to decrypt the ultimate object here, which is the ephemeral key, K3, contained
in the e:CipherData (RSTS-0200)-(RSTS-0205). The Service’s public X509
certificate is identified by its WS-Security 1.1 ThumbprintSHA1 (RSTS-0196).
Therefore, when the Service receives this saml:Assertion, it has the ability to
obtain the ephemeral key, K3, contained in the saml:SubjectConfirmation, with
which it can securely communicate with the Client, based on the assurances
provided by the STS.
Lines (RSTS-0211)-(RSTS-0248) contain the saml:Assertion
dsig Signature that is contained in and covers the saml:Assertion via the
saml:AssertionID, the value of which appears on lines (RSTS-0220) and
(RSTS-0167).
Lines (RSTS-0240)-(RSTS-0247) contain the saml:Assertion
dsig Signature KeyInfo element, which contains the ThumbprintSHA1 of the STS
public key, X509T2, which is the same certificate that the Client
referenced in the e:EncryptedKey when it made initial contact with the STS
above (MSTS-035). This completes the initial discussion of the characteristics
of the IssuedToken saml:Assertion that will be used in the remainder of this
example.
Lines (RSTS-0251)-(RSTS-0255) of the
t:RequestSecurityTokenResponse contains the t:RequestedProofToken, which
contains the Client copy of the STS-generated ephemeral key, K3, which
will be used in the Client-Service communication to authenticate the client to
the Service.
At this point we have completed the setup portion of this
example that has enabled secure trusted communication between the Client and
Service as governed by an STS. The exact strength of the security protecting
this example would be the subject of an official security analysis that is
beyond the scope of this document, however, the intent has been to provide
sufficient detail that all parties concerned with such an analysis would have
sufficient context to understand and evaluate such an analysis.
Here is an example of a Client request to the Service using
the tokens from the STS response:
(M001)
<s:Envelope
xmlns:s=http://www.w3.org/2003/05/soap-envelope
(M002)
xmlns:a=http://www.w3.org/2005/08/addressing
(M003)
xmlns:e=http://www.w3.org/2001/04/xmlenc#
(M004)
xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
(M005)
xmlns:sc="http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512"
(M006)
xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" >
(M007)
<s:Header>
(M008)
<a:Action s:mustUnderstand="1"
u:Id="_5">
(M009)
http://example.org/Ping
(M010)
</a:Action>
(M011)
<a:MessageID u:Id="_6">
(M012)
urn:uuid:a859eb17-1855-4d4f-8f73-85e4cba3e423
(M013)
</a:MessageID>
(M014)
<a:ReplyTo u:Id="_7">
(M015)
<a:Address>
(M016)
http://www.w3.org/2005/08/addressing/anonymous
(M017)
</a:Address>
(M018)
</a:ReplyTo>
(M019)
<a:To s:mustUnderstand="1" u:Id="_8">
(M020)
http://server.example.com/Scenarios5
(M021)
</a:To>
(M022)
<o:Security
s:mustUnderstand="1">
(M023)
<u:Timestamp
(M024)
u:Id="uuid-40f5bac7-f9af-4384-80db-cfab34263849-14">
(M025)
<u:Created>2005-10-25T00:47:38.222Z</u:Created>
(M026)
<u:Expires>2005-10-25T00:52:38.222Z</u:Expires>
(M027)
</u:Timestamp>
(M028)
<e:EncryptedKey
(M029)
Id="uuid-40f5bac7-f9af-4384-80db-cfab34263849-4">
(M030)
<e:EncryptionMethod Algorithm=
(M031)
http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"/>
(M032)
<KeyInfo
xmlns="http://www.w3.org/2000/09/xmldsig#">
(M033)
<o:SecurityTokenReference>
(M034)
<o:KeyIdentifier ValueType=
(M035)
"http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd#ThumbprintSHA1">
(M036)
NQM0IBvuplAtETQvk+6gn8C13wE=
(M037)
</o:KeyIdentifier>
(M038)
</o:SecurityTokenReference>
(M039)
</KeyInfo>
(M040)
<e:CipherData>
(M041)
<e:CipherValue>
(M042)
<!-- base64 encoded octets of
encrypted key K2 -->
(M043)
</e:CipherValue>
(M044)
</e:CipherData>
(M045)
</e:EncryptedKey>
(M046)
<sc:DerivedKeyToken u:Id="_0" >
(M047)
<o:SecurityTokenReference>
(M048)
<o:Reference
(M049)
URI="#uuid-40f5bac7-f9af-4384-80db-cfab34263849-4"/>
(M050)
</o:SecurityTokenReference>
(M051)
<sc:Offset>0</sc:Offset>
(M052)
<sc:Length>24</sc:Length>
(M053)
<sc:Nonce>7hI6Ul6OHavffYgpquHWuQ==</sc:Nonce>
(M054)
</sc:DerivedKeyToken>
(M055)
<sc:DerivedKeyToken u:Id="_2">
(M056)
<o:SecurityTokenReference>
(M057)
<o:Reference
(M058)
URI="#uuid-40f5bac7-f9af-4384-80db-cfab34263849-4"/>
(M059)
</o:SecurityTokenReference>
(M060)
<sc:Nonce>OEu+WEeUxPFRQK7SCFAnEQ==</sc:Nonce>
(M061)
</sc:DerivedKeyToken>
(M062)
<e:ReferenceList>
(M063)
<e:DataReference URI="#_4"/>
(M064)
</e:ReferenceList>
(M065)
<!-- encrypted SAML assertion
-->
(M066)
<e:EncryptedData Id="_3"
(M067)
Type="http://www.w3.org/2001/04/xmlenc#Element">
(M068)
<e:EncryptionMethod Algorithm=
(M069)
"http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
(M070)
<KeyInfo
xmlns="http://www.w3.org/2000/09/xmldsig#">
(M071)
<!-- encrypted Key K2 -->
(M072)
<e:EncryptedKey>
(M073)
<e:EncryptionMethod Algorithm=
(M074)
"http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"/>
(M075)
<KeyInfo>
(M076)
<o:SecurityTokenReference>
(M077)
<o:KeyIdentifier ValueType=
(M078)
"http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd#ThumbprintSHA1">
(M079)
NQM0IBvuplAtETQvk+6gn8C13wE=
(M080)
</o:KeyIdentifier>
(M081)
</o:SecurityTokenReference>
(M082)
</KeyInfo>
(M083)
<e:CipherData>
(M084)
<e:CipherValue>
(M085)
cb7+JW2idPNSarK9quqCe9PQwmW2hoUghuyKRe+I9zOts6HaMcg73LqCWuK/jtdpvNl6
(M086)
GT/ZDYfcAJ7NLyMGxSiwi4DUlTOShqS6OTYBIKgUKiA+zXNl2koVSy7amcUhPMIT6/fo
(M087)
hH+6MZDA4t6jomcyhlCiW8d9IAzSWFkfg2k=
(M088)
</e:CipherValue>
(M089)
</e:CipherData>
(M090)
</e:EncryptedKey>
(M091)
</KeyInfo>
(M092)
<e:CipherData>
(M093)
<e:CipherValue>
(M094)
<!-- base64 encoded octets from
SAML assertion encrypted
(M095)
with the encrypted key K2 above
-->
(M096)
<!-- SAML assertion element is
identical as received in
(M097)
RSTR , unencrypted form is
omitted for brevity -->
(M098)
<!--..........-->
(M099)
</e:CipherValue>
(M0100)
</e:CipherData>
(M0101)
</e:EncryptedData>
(M0102)
(M0103)
<sc:DerivedKeyToken u:Id="_9">
(M0104)
<o:SecurityTokenReference>
(M0105)
<o:KeyIdentifier ValueType=
(M0106)
"http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID">
(M0107)
uuid-8222b7a2-3874-4884-bdb5-9c2ddd4b86b5-16
(M0108)
</o:KeyIdentifier>
(M0109)
</o:SecurityTokenReference>
(M0110)
<sc:Offset>0</sc:Offset>
(M0111)
<sc:Length>24</sc:Length>
(M0112)
<sc:Nonce>pgnS/VDSzJn6SFz+Vy23JA==</sc:Nonce>
(M0113)
</sc:DerivedKeyToken>
(M0114)
<Signature Id="_1"
xmlns="http://www.w3.org/2000/09/xmldsig#">
(M0115)
<SignedInfo>
(M0116)
<CanonicalizationMethod Algorithm=
(M0117)
"http://www.w3.org/2001/10/xml-exc-c14n#"/>
(M0118)
<SignatureMethod Algorithm=
(M0119)
"http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>
(M0120)
<Reference URI="#_3">
(M0121)
<Transforms>
(M0122)
<Transform Algorithm=
(M0123)
"http://www.w3.org/2001/10/xml-exc-c14n#"/>
(M0124)
</Transforms>
(M0125)
<DigestMethod Algorithm=
(M0126)
"http://www.w3.org/2000/09/xmldsig#sha1"/>
(M0127)
<DigestValue>eQdQVGRkVI1YfKJBw7vOYCOeLQw=</DigestValue>
(M0128)
</Reference>
(M0129)
<Reference URI="#_5">
(M0130)
<Transforms>
(M0131)
<Transform Algorithm=
(M0132)
"http://www.w3.org/2001/10/xml-exc-c14n#"/>
(M0133)
</Transforms>
(M0134)
<DigestMethod Algorithm=
(M0135)
"http://www.w3.org/2000/09/xmldsig#sha1"/>
(M0136)
<DigestValue>xxyKpp5RZ2TebKca2IGOafIgcxk=</DigestValue>
(M0137)
</Reference>
(M0138)
<Reference URI="#_6">
(M0139)
<Transforms>
(M0140)
<Transform Algorithm=
(M0141)
"http://www.w3.org/2001/10/xml-exc-c14n#"/>
(M0142)
</Transforms>
(M0143)
<DigestMethod Algorithm=
(M0144)
"http://www.w3.org/2000/09/xmldsig#sha1"/>
(M0145)
<DigestValue>WyGDDyYbL/hQZJfE3Yx2aK3RkK8=</DigestValue>
(M0146)
</Reference>
(M0147)
<Reference URI="#_7">
(M0148)
<Transforms>
(M0149)
<Transform Algorithm=
(M0150)
"http://www.w3.org/2001/10/xml-exc-c14n#"/>
(M0151)
</Transforms>
(M0152)
<DigestMethod Algorithm=
(M0153)
"http://www.w3.org/2000/09/xmldsig#sha1"/>
(M0154)
<DigestValue>AEOH0t2KYR8mivgqUGDrgMtxgEQ=</DigestValue>
(M0155)
</Reference>
(M0156)
<Reference URI="#_8">
(M0157)
<Transforms>
(M0158)
<Transform Algorithm=
(M0159)
"http://www.w3.org/2001/10/xml-exc-c14n#"/>
(M0160)
</Transforms>
(M0161)
<DigestMethod Algorithm=
(M0162)
"http://www.w3.org/2000/09/xmldsig#sha1"/>
(M0163)
<DigestValue>y8n6Dxd3DbD6TR6d6H/oVWsV4yE=</DigestValue>
(M0164)
</Reference>
(M0165)
<Reference
(M0166)
URI="#uuid-40f5bac7-f9af-4384-80db-cfab34263849-14">
(M0167)
<Transforms>
(M0168)
<Transform Algorithm=
(M0169)
"http://www.w3.org/2001/10/xml-exc-c14n#"/>
(M0170)
</Transforms>
(M0171)
<DigestMethod Algorithm=
(M0172)
"http://www.w3.org/2000/09/xmldsig#sha1"/>
(M0173)
<DigestValue>/Cc+bGkkeQ6jlVXZx8PGgmF6MjI=</DigestValue>
(M0174)
</Reference>
(M0175)
</SignedInfo>
(M0176)
<!--base64 encoded signature value
-->
(M0177)
<SignatureValue>EyKUHUuffPUPE/ZjaFrMJJ5KLKY=</SignatureValue>
(M0178)
<KeyInfo>
(M0179)
<o:SecurityTokenReference>
(M0180)
<o:Reference URI="#_0"/>
(M0181)
</o:SecurityTokenReference>
(M0182)
</KeyInfo>
(M0183)
</Signature>
(M0184)
<!-- signature over the primary
signature above
(M0185)
using the key derived from the proof-key,
K3,
(M0186)
associated with SAML assertion
-->
(M0187)
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
(M0188)
<SignedInfo>
(M0189)
<CanonicalizationMethod Algorithm=
(M0190)
"http://www.w3.org/2001/10/xml-exc-c14n#"/>
(M0191)
<SignatureMethod Algorithm=
(M0192)
"http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>
(M0193)
<Reference URI="#_1">
(M0194)
<Transforms>
(M0195)
<Transform Algorithm=
(M0196)
"http://www.w3.org/2001/10/xml-exc-c14n#"/>
(M0197)
</Transforms>
(M0198)
<DigestMethod Algorithm=
(M0199)
"http://www.w3.org/2000/09/xmldsig#sha1"/>
(M0200)
<DigestValue>TMSmLlgeUn8cxyb6OYe5Q2nUuxY=</DigestValue>
(M0201)
</Reference>
(M0202)
</SignedInfo>
(M0203)
<SignatureValue>Fh4NyOpAi+NqVFiHBgHWyvzah9I=</SignatureValue>
(M0204)
<KeyInfo>
(M0205)
<o:SecurityTokenReference>
(M0206)
<o:Reference URI="#_9"/>
(M0207)
</o:SecurityTokenReference>
(M0208)
</KeyInfo>
(M0209)
</Signature>
(M0210)
</o:Security>
(M0211)
</s:Header>
(M0212)
<s:Body u:Id="_3">
(M0213)
<e:EncryptedData Id="_4"
(M0214)
Type="http://www.w3.org/2001/04/xmlenc#Content">
(M0215)
<e:EncryptionMethod
Algorithm=
(M0216)
"http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
(M0217)
<KeyInfo
xmlns="http://www.w3.org/2000/09/xmldsig#">
(M0218)
<o:SecurityTokenReference >
(M0219)
<o:Reference URI="#_2"/>
(M0220)
</o:SecurityTokenReference>
(M0221)
</KeyInfo>
(M0222)
<e:CipherData>
(M0223)
<e:CipherValue>
(M0224)
<!-- base64 encoded octets of
encrypted body content-->
(M0225)
</e:CipherValue>
(M0226)
</e:CipherData>
(M0227)
</e:EncryptedData>
(M0228)
</s:Body>
(M0229)
</s:Envelope>
The message above is a request from the Client to the
Service using the tokens provided by the STS above.
Lines (M022)-(M0210) contain the WS-Security o:Security
header for this request.
Lines (M028)-(M045) contain an e:EncryptedKey that
contains the ephemeral key, K2, for the Client-Service communication. The
service must use its X509T3 (M034)-(M037) to decrypt this Client-generated
ephemeral key, K2.
Lines (M046)-(M054) contain a WS-SecureConversation
sc:DerivedKeyToken, that contains the information required to generate
the signing key, DKT1(K2) [WS_SECURE_CONV],
including an sc:Nonce (M053), and a WS-Security SecurityTokenReference that
contains a direct reference (M049) to the e:EncryptedKey, K2 (M042). This
derived key, DKT1(K2), is used to sign the message in the message signature
element (M0114)-(M0183).
Lines (M055)-(M054) provide similar sc:DerivedKeyToken
constructs the generate the encrypting key DKT2(K2). This derived key,
DKT2(K2), is used to encrypt the message body, resulting in the EncryptedData
element in the s:Body, on lines (M0213)-(M0227).
Lines (M062)-(M064) provide an e:ReferenceList to
reference the e:EncryptedData in the s:Body (M0213), which contains the
Client request for the Service. The s:Body payload data in this Client request
is not of interest to the security properties of this example and will not be
shown in decrypted form.
Lines (M066)-(M0101) contain an e:EncryptedData element
that contains the saml:Assertion described in the STS response above. This
e:EncryptedData contains a dsig KeyInfo, which, in turn, contains an
e:EncryptedKey element (M072)-(M090), which contains the Client-generated
ephemeral key, K2, which was used by the Client to directly encrypt the
saml:Assertion. The encryption key, K2, may be decrypted, again using the
Service public X509 certificate, again identified by its ThumbprintSHA1,
(M077)-(M080).
Lines (M0103)-(M0113) contain a third sc:DerivedKeyToken that
contains the information necessary for the Service to generate the endorsing
signing key, DKT3(K2).
Lines (M0114)-(M0183) contains the message signature.
It is signed using the key identified in the dsig KeyInfo
(M0178)-(M0182), which contains a reference to the derived signing key,
DKT1(K2), which may be constructed by the service using the
sc:DerivedKeyToken (M046) described above.
Lines (M0187)-(M0209) contain the message endorsing
signature. It is signed using the client proof key, K3, that was
generated by the STS. Note that the Service should compare this key, K3, with
the one in the saml:SubjectConfirmation in the decrypted saml:Assertion to
verify that the Client is using the same proof key, K3, that is contained in
the saml:Assertion that authenticates this request.
Lines (M0213)-(M0227) contain the SOAP s:Body message
payload, e:EncryptedData, which may be decrypted using the
sc:DerivedKeyToken (M055) to generate the decryption key DKT2(K2).
Here is an example response from the Service to the Client:
(R001) <s:Envelope
xmlns:s=http://www.w3.org/2003/05/soap-envelope
(R002) xmlns:a=http://www.w3.org/2005/08/addressing
(R003) xmlns:e=http://www.w3.org/2001/04/xmlenc#
(R004) xmlns:k="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd"
(R005) xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
(R006) xmlns:sc="http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512"
(R007) xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
(R008) <s:Header>
(R009) <a:Action s:mustUnderstand="1"
u:Id="_6">
(R010) http://example.org/PingResponse
(R011) </a:Action>
(R012) <a:RelatesTo u:Id="_7">
(R013) urn:uuid:a859eb17-1855-4d4f-8f73-85e4cba3e423
(R014) </a:RelatesTo>
(R015) <a:To s:mustUnderstand="1" u:Id="_8">
(R016) http://www.w3.org/2005/08/addressing/anonymous
(R017) </a:To>
(R018) <o:Security s:mustUnderstand="1">
(R019) <u:Timestamp u:Id="uuid-24adda3a-247a-4fec-b4f7-fb3827496cee-16">
(R020) <u:Created>2005-10-25T00:47:38.921Z</u:Created>
(R021) <u:Expires>2005-10-25T00:52:38.921Z</u:Expires>
(R022) </u:Timestamp>
(R023) <sc:DerivedKeyToken u:Id="_0" >
(R024) <o:SecurityTokenReference
(R025) k:TokenType="http://docs.oasis-open.org/wss/
(R026) oasis-wss-soap-message-security-1.1#EncryptedKey"
(R027) xmlns:k="http://docs.oasis-open.org/wss/
(R028) oasis-wss-wssecurity-secext-1.1.xsd">
(R029) <o:KeyIdentifier ValueType=
(R030) "http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd#EncryptedKeySHA1"
(R031) >pDJlrSJLzIqi+AcQLUB4GjUuRLs=</o:KeyIdentifier>
(R032) </o:SecurityTokenReference>
(R033) <sc:Offset>0</sc:Offset>
(R034) <sc:Length>24</sc:Length>
(R035) <sc:Nonce>KFjy1Gb73BubLul0ZGgx+w==</sc:Nonce>
(R036) </sc:DerivedKeyToken>
(R037) <sc:DerivedKeyToken u:Id="_3">
(R038) <o:SecurityTokenReference
(R039) k:TokenType="http://docs.oasis-open.org/wss/
(R040) oasis-wss-soap-message-security-1.1#EncryptedKey"
(R041) xmlns:k="http://docs.oasis-open.org/wss/
(R042) oasis-wss-wssecurity-secext-1.1.xsd">
(R043) <o:KeyIdentifier ValueType=
(R044) "http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd#EncryptedKeySHA1"
(R045) >pDJlrSJLzIqi+AcQLUB4GjUuRLs=</o:KeyIdentifier>
(R046) </o:SecurityTokenReference>
(R047) <sc:Nonce>omyh+Eg6XIa8q3V5IkHiXg==</sc:Nonce>
(R048) </sc:DerivedKeyToken>
(R049) <e:ReferenceList>
(R050) <e:DataReference URI="#_5"/>
(R051) </e:ReferenceList>
(R052) <k:SignatureConfirmation u:Id="_1"
(R053) Value="EyKUHUuffPUPE/ZjaFrMJJ5KLKY="/>
(R054) <k:SignatureConfirmation u:Id="_2"
(R055) Value="Fh4NyOpAi+NqVFiHBgHWyvzah9I="/>
(R056) <Signature
xmlns="http://www.w3.org/2000/09/xmldsig#">
(R057) <SignedInfo>
(R058) <CanonicalizationMethod Algorithm=
(R059) "http://www.w3.org/2001/10/xml-exc-c14n#"/>
(R060) <SignatureMethod Algorithm=
(R061) "http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>
(R062) <Reference URI="#_4">
(R063) <Transforms>
(R064) <Transform Algorithm=
(R065) "http://www.w3.org/2001/10/xml-exc-c14n#"/>
(R066) </Transforms>
(R067) <DigestMethod Algorithm=
(R068) "http://www.w3.org/2000/09/xmldsig#sha1"/>
(R069) <DigestValue>y/oItF5TcTOFan7SavhZTTTv48M=</DigestValue>
(R070) </Reference>
(R071) <Reference URI="#_6">
(R072) <Transforms>
(R073) <Transform Algorithm=
(R074) "http://www.w3.org/2001/10/xml-exc-c14n#"/>
(R075) </Transforms>
(R076) <DigestMethod Algorithm=
(R077) "http://www.w3.org/2000/09/xmldsig#sha1"/>
(R078) <DigestValue>X4UIaLWnaAWTriw4UJ/SFDgm090=</DigestValue>
(R079) </Reference>
(R080) <Reference URI="#_7">
(R081) <Transforms>
(R082) <Transform Algorithm=
(R083) "http://www.w3.org/2001/10/xml-exc-c14n#"/>
(R084) </Transforms>
(R085) <DigestMethod Algorithm=
(R086) "http://www.w3.org/2000/09/xmldsig#sha1"/>
(R087) <DigestValue>vqy8/D4CDCaI1nnd4wl1Qjyp+qM=</DigestValue>
(R088) </Reference>
(R089) <Reference URI="#_8">
(R090) <Transforms>
(R091) <Transform Algorithm=
(R092) "http://www.w3.org/2001/10/xml-exc-c14n#"/>
(R093) </Transforms>
(R094) <DigestMethod Algorithm=
(R095) "http://www.w3.org/2000/09/xmldsig#sha1"/>
(R096) <DigestValue>H11vLAr5g8pbZ6jfZ+2WNyiNjiM=</DigestValue>
(R097) </Reference>
(R098) <Reference
(R099) URI="#uuid-24adda3a-247a-4fec-b4f7-fb3827496cee-16">
(R0100) <Transforms>
(R0101) <Transform Algorithm=
(R0102) "http://www.w3.org/2001/10/xml-exc-c14n#"/>
(R0103) </Transforms>
(R0104) <DigestMethod Algorithm=
(R0105) "http://www.w3.org/2000/09/xmldsig#sha1"/>
(R0106) <DigestValue>dr0g6hycoc884i+BD8FYCJGbbbE=</DigestValue>
(R0107) </Reference>
(R0108) <Reference URI="#_1">
(R0109) <Transforms>
(R0110) <Transform Algorithm=
(R0111) "http://www.w3.org/2001/10/xml-exc-c14n#"/>
(R0112) </Transforms>
(R0113) <DigestMethod Algorithm=
(R0114) "http://www.w3.org/2000/09/xmldsig#sha1"/>
(R0115) <DigestValue>Rv3N7VNfAqpn0khr3F/qQZmE/l4=</DigestValue>
(R0116) </Reference>
(R0117) <Reference URI="#_2">
(R0118) <Transforms>
(R0119) <Transform Algorithm=
(R0120) "http://www.w3.org/2001/10/xml-exc-c14n#"/>
(R0121) </Transforms>
(R0122) <DigestMethod Algorithm=
(R0123) "http://www.w3.org/2000/09/xmldsig#sha1"/>
(R0124) <DigestValue>X2pxEnYPM8cMLrbhNqPgs8xk+a4=</DigestValue>
(R0125) </Reference>
(R0126) </SignedInfo>
(R0127) <SignatureValue>I2jQuDTWWQiNJy/ziyg8AFYO/z4=</SignatureValue>
(R0128) <KeyInfo>
(R0129) <o:SecurityTokenReference>
(R0130) <o:Reference URI="#_0"/>
(R0131) </o:SecurityTokenReference>
(R0132) </KeyInfo>
(R0133) </Signature>
(R0134) </o:Security>
(R0135) </s:Header>
(R0136) <s:Body u:Id="_4">
(R0137) <e:EncryptedData Id="_5"
(R0138) Type="http://www.w3.org/2001/04/xmlenc#Content">
(R0139) <e:EncryptionMethod Algorithm=
(R0140) "http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
(R0141) <KeyInfo
xmlns="http://www.w3.org/2000/09/xmldsig#">
(R0142) <o:SecurityTokenReference>
(R0143) <o:Reference URI="#_3"/>
(R0144) </o:SecurityTokenReference>
(R0145) </KeyInfo>
(R0146) <e:CipherData>
(R0147) <e:CipherValue>
(R0148) <!--base64 encoded octets of
encrypted body content-->
(R0149) </e:CipherValue>
(R0150) </e:CipherData>
(R0151) </e:EncryptedData>
(R0152) </s:Body>
(R0153) </s:Envelope>
The message above is a response from the Service to the
Client using the tokens based on the saml:Assertion IssuedToken from the STS.
Lines (R018)-(R0134) contain the WS-Security o:Security
header in the SOAP s:Header.
Lines (R023)-(R036) contain an sc:DerivedKeyToken
that may be used to construct the derived signing key DKT4(K2), which
uses the Client-generated ephemeral key, K2, that the Service received in the
Client request (M028)-(M045) above, and is now used in the response to the
client, similar to the way the STS used K1 to respond to the Client, except
that in this case the Service will use derived keys DKT4(K2) and DKT5(K2) in
addition to K2 in the response. This sc:DerivedKeyToken contains a WS-Security
o:SecurityTokenReference (R024)-(R032) that uses the WS-Security 1.1 mechanism
EncryptedKeySHA1 to identify the Client-generated ephemeral key, K2, as the key
to use to derive DKT4(K2) along with the sc:Nonce provided (R035) (and the
label as described in [WS_SECURE_CONV]).
Lines (R037)-(R048) contain a second sc:DerivedKeyToken
that may be used by the Client to construct the derived encryption key,
DKT5(K2). The same EncryptedKeySHA1 mechanism is used by the Client to
construct DKT5(K2) as described for DKT4(K2).
Lines (R049)-(R051) contain an e:ReferenceList
containing an e:DataReference to the EncryptedData element in the s:Body
(R0136).
Lines (R052)-(R055) contain 2 WS-Security 1.1
k:SignatureConfirmation elements confirming the dsig Signatures that were in
the client request above (M0203) on the endorsing signature and (M0177) on the
message signature of the Client request. The dsig SignatureValues compare
respectively to assure the Client that the data from the Client request was
processed and is what is being referred to in this response.
Lines (R056)-(R0134) contain the message signature, which is
signed as referenced in the dsig KeyInfo (R0128)-(R0132) by DKT4(K2), which may
be constructed as described above using the sc:DerivedKeyToken element
(R023)-(R036).
Lines (R0137)-(R0151) contain the Service response payload
to the Client which may be decrypted using DKT5(K2) using the
sc:DerivedKeyToken element (R037)-(R048).
This scenario corresponds to the situation where both
parties have an X.509 certificate (and public/private key pair). Because of the
volume of messages from each source, the Requestor/Initiator uses
WS-SecureConversation to establish a new session key and uses the session key
for integrity and/or confidentiality protection. This improves performance, by
using less expensive symmetric key operations and improves security by reducing
the exposure of the long term secret.
The recipient models this scenario by using the symmetric
binding that includes a SecureConversationToken assertion to describe the token
type accepted by this endpoint. This token assertion further contains a
bootstrap policy to indicate the security binding that is used by requestors
that want a security context token issued by this service. The bootstrap policy
affects the Request Security Token Request (RST) and Request Security Token
Request Response (RSTR) messages sent between the Initiator and the Recipient
to establish the security context. It is modeled by use of an asymmetric
binding assertion for this scenario because both parties mutually authenticate
each other using their X.509 certificates.
The message level policies 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 Message Policy Subject. These are shown
below as input and output policies. Thus, we need a set of coordinated policies
one with endpoint subject (WSS10SecureConversation_policy)
and two (WSS10SecureConversation_input_policy,
WSS10SecureConversation_output_policy)
with message subjects to achieve this use case.
(P001)
<wsp:Policy wsu:Id="WSS10SecureConversation_policy">
(P002)
<wsp:ExactlyOne>
(P003)
<wsp:All>
(P004)
<sp:SymmetricBinding
xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
(P005)
<wsp:Policy>
(P006)
<sp:ProtectionToken>
(P007)
<wsp:Policy>
(P008)
<sp:SecureConversationToken
sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
(P009)
<wsp:Policy>
(P010)
<sp:RequireDerivedKeys/>
(P011)
<sp:BootstrapPolicy>
(P012)
<wsp:Policy>
(P013)
<wsp:ExactlyOne>
(P014)
<wsp:All>
(P015)
<sp:AsymmetricBinding
xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
(P016)
<wsp:Policy>
(P017)
<sp:InitiatorToken>
(P018)
<wsp:Policy>
(P019)
<sp:X509Token
sp:IncludeToken="http://schemas.xmlsoap.org/ws/200512/securitypolicy/IncludeToken/AlwaysToRecipient">
(P020)
<wsp:Policy>
(P021)
<sp:WssX509V3Token10/>
(P022)
</wsp:Policy>
(P023)
</sp:X509Token>
(P024)
</wsp:Policy>
(P025)
</sp:InitiatorToken>
(P026)
<sp:RecipientToken>
(P027)
<wsp:Policy>
(P028)
<sp:X509Token
sp:IncludeToken="http://schemas.xmlsoap.org/ws/200512/securitypolicy/IncludeToken/AlwaysToInitiator">
(P029)
<wsp:Policy>
(P030)
<sp:WssX509V3Token10/>
(P031)
</wsp:Policy>
(P032)
</sp:X509Token>
(P033)
</wsp:Policy>
(P034)
</sp:RecipientToken>
(P035)
<sp:AlgorithmSuite>
(P036)
<wsp:Policy>
(P037)
<sp:TripleDesRsa15/>
(P038)
</wsp:Policy>
(P039)
</sp:AlgorithmSuite>
(P040)
<sp:Layout>
(P041)
<wsp:Policy>
(P042)
<sp:Strict/>
(P043)
</wsp:Policy>
(P044)
</sp:Layout>
(P045)
<sp:IncludeTimestamp/>
(P046)
<sp:OnlySignEntireHeadersAndBody/>
(P047)
</wsp:Policy>
(P048)
</sp:AsymmetricBinding>
(P049)
<sp:Wss10>
(P050)
<wsp:Policy>
(P051)
<sp:MustSupportRefKeyIdentifier/>
(P052)
</wsp:Policy>
(P053)
</sp:Wss10>
(P054)
<sp:SignedParts>
(P055)
<sp:Body/>
(P056)
<sp:Header
Name="Action"
Namespace="http://www.w3.org/2005/08/addressing"/>
(P057)
</sp:SignedParts>
(P058)
<sp:EncryptedParts>
(P059)
<sp:Body/>
(P060)
</sp:EncryptedParts>
(P061)
</wsp:All>
(P062)
</wsp:ExactlyOne>
(P063)
</wsp:Policy>
(P064)
</sp:BootstrapPolicy>
(P065)
</wsp:Policy>
(P066)
</sp:SecureConversationToken>
(P067)
</wsp:Policy>
(P068)
</sp:ProtectionToken>
(P069)
<sp:AlgorithmSuite>
(P070)
<wsp:Policy>
(P071)
<sp:Basic256/>
(P072)
</wsp:Policy>
(P073)
</sp:AlgorithmSuite>
(P074)
<sp:Layout>
(P075)
<wsp:Policy>
(P076)
<sp:Strict/>
(P077)
</wsp:Policy>
(P078)
</sp:Layout>
(P079)
<sp:IncludeTimestamp/>
(P080)
<sp:OnlySignEntireHeadersAndBody/>
(P081)
</wsp:Policy>
(P082)
</sp:SymmetricBinding>
(P083)
<sp:Trust13>
(P084)
<wsp:Policy>
(P085)
<sp:RequireClientEntropy/>
(P086)
<sp:RequireServerEntropy/>
(P087)
</wsp:Policy>
(P088)
</sp:Trust13>
(P089)
(P090)
</wsp:All>
(P091)
</wsp:ExactlyOne>
(P092)
</wsp:Policy>
(P093) <wsp:Policy
wsu:Id="WSS10SecureConversation_input_policy">
(P094) <wsp:ExactlyOne>
(P095) <wsp:All>
(P096) <sp:SignedParts>
(P097)
<sp:Header
Name="Action"
Namespace="http://www.w3.org/2005/08/addressing"/>
(P098)
<sp:Header
Name="To"
Namespace="http://www.w3.org/2005/08/addressing"/>
(P099)
<sp:Header
Name="MessageID"
Namespace="http://www.w3.org/2005/08/addressing"/>
(P0100)
<sp:Body/>
(P0101)
</sp:SignedParts>
(P0102)
</wsp:All>
(P0103) </wsp:ExactlyOne>
(P0104) </wsp:Policy>
(P0105)
(P0106) <wsp:Policy
wsu:Id="WSS10SecureConversation_output_policy">
(P0107) <wsp:ExactlyOne>
(P0108) <wsp:All>
(P0109) <sp:SignedParts>
(P0110) <sp:Header Name="Action"
Namespace="http://www.w3.org/2005/08/addressing"/>
(P0111) <sp:Header Name="To"
Namespace="http://www.w3.org/2005/08/addressing"/>
(P0112) <sp:Header
Name="MessageID"
Namespace="http://www.w3.org/2005/08/addressing"/>
(P0113) <sp:Header
Name="RelatesTo"
Namespace="http://www.w3.org/2005/08/addressing"/>
(P0114) <sp:Body/>
(P0115) </sp:SignedParts>
(P0116) </wsp:All>
(P0117) </wsp:ExactlyOne>
(P0118) </wsp:Policy>
Lines (P004) – (P082) indicate that the service uses the
symmetric security binding to protect messages, using a Security Context Token
(Lines (P008) – (P066)) to sign messages in both directions. The actual basis
for the signatures should be keys derived from that Security Context Token as
stated by the RequireDerivedKey assertion in Line (P010). Messages must include
a Timestamp element (Line (P079)) and the signature value must be calculated
over the entire body and header elements (Line (P080)).
Lines (P083) – (P088) contain the Trust13 assertion which
defines the requirements for the WS-Trust related message exchange as part of
the SC bootstrap. Line (P085) indicates that the Initiator (Client) has to
provide entropy to be used as key material for the requested proof token. Line
(P086) requires the same from the recipient (Server) which results in computed
key from both client and server entropy values.
Lines (P011) – (P065) contain the bootstrap policy for the
initial creation of the security context between the communication parties
before it is being used. It contains an AsymmetricBinding assertion (Lines
(P015) – (P048)) which indicates that the initiator’s (WS-Security 1.0 X.509
Certificate) token (Lines (P017) – (P025)) used by the recipient to verify the
signature in the RST must be included in the message (P019). The exchange of
entropy and key material in the body of the RST and RSTR messages is protected
by the EncryptedParts assertion of the bootstrap policy in lines (P058) –
(P061).
According to the MustSupportKeyRefIdentitier assertions in
Line (P051), an X.509 Key Identifier must be used to identify the token. Lines
(P054) – (P057) require that the body and the WS-Addressing Action header is
signed on each message (RST, RSTR) within the bootstrap process.
An example of an RST message sent from the initiator to the
recipient according to the bootstrap policy defined by this policy is as
follows:
(M001)
<?xml version="1.0" encoding="utf-8" ?>
(M002)
<soap:Envelope xmlns:soap="..." xmlns:wsse="..."
xmlns:wsu="..."
xmlns:wst="..." xmlns:xenc="..."
xmlns:wsa="...">
(M003)
<soap:Header>
(M004)
<wsa:Action
wsu:Id="action">
(M005)
http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/SCT
(M006)
</wsa:Action>
(M007)
<wsse:Security>
(M008)
<wsu:Timestamp
wsu:Id="timestamp">
(M009)
<wsu:Created>2007-06-17T00:00:00Z</wsu:Created>
(M010)
<wsu:Expires>2007-06-17T23:59:59Z</wsu:Expires>
(M011)
</wsu:Timestamp>
(M012)
<wsse:BinarySecurityToken
wsu:Id="clientToken"
ValueType="...#X509v3"
EncodingType="...#Base64Binary">
(M013)
MIICZDCCAc2gAwIBAgIRALSOLzt7...
(M014)
</wsse:BinarySecurityToken>
(M015)
<ds:Signature
xmlns:ds="...">
(M016)
<ds:SignedInfo>
(M017)
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
(M018)
<ds:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
(M019)
<ds:Reference
URI="#action">
(M020)
<ds:Transforms>
(M021)
<ds:Transform
Algorithm="http://www.w3.org/2001/10/xml-
exc-c14n#"/>
(M022)
</ds:Transforms>
(M023)
<ds:DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
(M024)
<ds:DigestValue>oZKZXftCbY43Wo4w...</ds:DigestValue>
(M025)
</ds:Reference>
(M026)
<ds:Reference
URI="#timestamp">...</ds:Reference>
(M027)
<ds:Reference
URI="#body">...</ds:Reference>
(M028)
</ds:SignedInfo>
(M029)
<ds:SignatureValue>Po9mb0Gw6hWn...</ds:SignatureValue>
(M030)
<ds:KeyInfo>
(M031)
<wsse:SecurityTokenReference>
(M032)
<wsse:Reference
URI="#clientToken"
ValueType="...#X509v3"/>
(M033)
</wsse:SecurityTokenReference>
(M034)
</ds:KeyInfo>
(M035)
</ds:Signature>
(M036)
<xenc:EncryptedKey>
(M037)
<xenc:EncryptionMethod
Algorithm="...#rsa-1_5"/>
(M038)
<ds:KeyInfo>
(M039)
<wsse:SecurityTokenReference>
(M040)
<wsse:KeyIdentifier
(M041)
ValueType="...#X509v3SubjectKeyIdentifier">AtETQ...
(M042)
</wsse:KeyIdentifier>
(M043)
</wsse:SecurityTokenReference>
(M044)
</ds:KeyInfo>
(M045)
<xenc:CipherData>
(M046)
<xenc:CipherValue>
(M047)
<!-- encrypted key
-->
(M048)
</xenc:CipherValue>
(M049)
</xenc:CipherData>
(M050)
<xenc:ReferenceList>
(M051)
<xenc:DataReference
URI="#request"/>
(M052)
</xenc:ReferenceList>
(M053)
</xenc:EncryptedKey>
(M054)
</wsse:Security>
(M055)
</soap:Header>
(M056)
<soap:Body
wsu:Id="body">
(M057)
<xenc:EncryptedData
Id="request" Type="...#Content">
(M058)
<xenc:EncryptionMethod
Algorithm="...#aes256-cbc"/>
(M059)
<xenc:CipherData>
(M060)
<xenc:CipherValue>
(M061)
<!-- encrypted RST
request -->
(M062) <!--
### Begin unencrypted RST request
(M063) <wst:RequestSecurityToken>
(M064) <wst:TokenType>
(M065) http://docs.oasis-open.org/ws-sx/ws-secureconversation/
200512/sct
(M066) </wst:TokenType>
(M067) <wst:RequestType>
(M068) http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue
(M069) </wst:RequestType>
(M070) <wsp:AppliesTo
xmlns:wsp="http://www.w3.org/ns/ws-policy">
(M071) <wsp:EndpointReference>
(M072) <wsp:Address>
(M073) http://acme.com/ping/
(M074) </wsp:Address>
(M075) </wsp:EndpointReference>
(M076) </wsp:AppliesTo>
(M077) <wst:Entropy>
(M078) <wst:BinarySecret>cr9bOcb1wCEyY9ehaGK33e41h9s=
(M079) </wst:BinarySecret>
(M080) </wst:Entropy>
(M081)
</wst:RequestSecurityToken>
(M082) ###
End unencrypted RST request -->
(M083)
</xenc:CipherValue>
(M084)
</xenc:CipherData>
(M085)
</xenc:EncryptedData>
(M086)
</soap:Body>
(M087)
</soap:Envelope>
Line (M005) indicates to the recipient that the SCT Binding
of WS-Trust is used.
Lines (M008) – (M011) hold the Timestamp element as required
by the IncludeTimestamp assertion.
Lines (M012) – (M014) contain the initiator’s X.509 token as
required by the InitiatorToken assertion’s value (“…/AlwaysToRecipient”).
Lines (M015) – (M035) hold the message signature.
Lines (M036) – (M053) hold the encrypted symmetric key used
to encrypt the RST request in the body of the message according to the
bootstrap policy. It contains a Subject Key Identifier of the X.509 Certificate
used to encrypt the key and not the certificate itself as required by the
RecipientToken assertion’s value (“…/Never”) in (P028).
Lines (M019) – (M025) indicate the WS-Addressing Action
header is included in the signature as required by the SignedParts assertion.
Line (M026) indicates the Timestamp is included in the
signature according to the IncludeTimestamp assertion definition.
Line (M027) indicates the SOAP Body is included in the
signature as required by the SignedParts assertion.
Lines (M056) – (M086) hold the Security Token Reference
pointing to the initiators X.509 certificate.
Lines (M038) – (M058) contain the SOAP Body of the message
with the encrypted RST element. Lines (M062) – (M082) show the unencrypted
content of the RST request. It specifies the Token Type (Lines (M064) – (M066))
and the Request Type (Lines (M067) – (M069). According to the Trust13
assertion, it also includes entropy provided by the initiator as indicated by
Lines (M077) – (M080).
An example of an RSTR message sent from the recipient to the
initiator according to the bootstrap policy defined by this policy is as
follows:
(M001)
<?xml version="1.0" encoding="UTF-8"?>
(M002)
<soap:Envelope xmlns:soap="..." xmlns:wst="..."
xmlns:wsc="..."
xmlns:xenc="...">
(M003)
<soap:Header>
(M004)
<wsa:Action
wsu:Id="action">
(M005)
http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTRC/IssueFinal
(M006)
</wsa:Action>
(M007)
<wsse:Security>
(M008)
<wsu:Timestamp
wsu:Id="timestamp">
(M009)
<wsu:Created>2007-06-17T00:00:00Z</wsu:Created>
(M010)
<wsu:Expires>2007-06-17T23:59:59Z</wsu:Expires>
(M011)
</wsu:Timestamp>
(M012)
<wsse:BinarySecurityToken
wsu:Id="serviceToken"
ValueType="...0#X509v3"
EncodingType="...#Base64Binary">
(M013)
MIIASDPIOASDsaöAgIRALSOLzt7...
(M014)
</wsse:BinarySecurityToken>
(M015)
<ds:Signature xmlns:ds="...">
(M016)
<ds:SignedInfo>
(M017)
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
(M018)
<ds:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
(M019)
<ds:Reference
URI="#action">
(M020)
<ds:Transforms>
(M021)
<ds:Transform
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
(M022)
</ds:Transforms>
(M023)
<ds:DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
(M024)
<ds:DigestValue>oZKZXftCbY43Wo4w...</ds:DigestValue>
(M025)
</ds:Reference>
(M026)
<ds:Reference
URI="#timestamp">...</ds:Reference>
(M027)
<ds:Reference
URI="#body">...</ds:Reference>
(M028)
</ds:SignedInfo>
(M029)
<ds:SignatureValue>Po9mb0Gw6hWn...</ds:SignatureValue>
(M030)
<ds:KeyInfo>
(M031)
<wsse:SecurityTokenReference>
(M032)
<wsse:Reference
URI="#myToken" ValueType="...#X509v3"/>
(M033)
</wsse:SecurityTokenReference>
(M034)
</ds:KeyInfo>
(M035)
</ds:Signature>
(M036)
<xenc:EncryptedKey>
(M037)
<xenc:EncryptionMethod
Algorithm="...#rsa-1_5"/>
(M038)
<ds:KeyInfo>
(M039)
<wsse:SecurityTokenReference>
(M040)
<wsse:KeyIdentifier
(M041)
ValueType="...#X509v3SubjectKeyIdentifier">AtETQ...
(M042)
</wsse:KeyIdentifier>
(M043)
</wsse:SecurityTokenReference>
(M044)
</ds:KeyInfo>
(M045)
<xenc:CipherData>
(M046)
<xenc:CipherValue>
(M047)
<!-- encrypted
key -->
(M048)
</xenc:CipherValue>
(M049)
</xenc:CipherData>
(M050)
<xenc:ReferenceList>
(M051)
<xenc:DataReference
URI="#response"/>
(M052)
</xenc:ReferenceList>
(M053)
</xenc:EncryptedKey>
(M054)
</wsse:Security>
(M055)
</soap:Header>
(M056)
<soap:Body wsu:Id="body">
(M057)
<xenc:EncryptedData
Id="response" Type="...#Content">
(M058)
<xenc:EncryptionMethod
Algorithm="...#aes256-cbc"/>
(M059)
<xenc:CipherData>
(M060)
<xenc:CipherValue>
(M061)
<!-- encrypted
RSTR -->
(M062) <!--
### Begin unencrypted RSTR
(M063) <wst:RequestSecurityTokenResponseCollection>
(M064) <wst:RequestSecurityTokenResponse>
(M065) <wst:RequestedSecurityToken>
(M066) <wsc:SecurityContextToken>
(M067) <wsc:Identifier>uuid:...</wsc:Identifier>
(M068) </wsc:SecurityContextToken>
(M069) </wst:RequestedSecurityToken>
(M070) <wst:RequestedProofToken>
(M071) <xenc:EncryptedKey
Id="ek049ea390c90011dbba4e00304852867e">
(M072) <xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
(M073) <ds:KeyInfo>
(M074) <wsse:SecurityTokenReference>
(M075) <wsse:KeyIdentifier
ValueType="...#X509SubjectKeyIdentifier"
EncodingType="...#Base64Binary">
(M076) Wjw2gDCBye6NJAh0lPCyUldvTN8=
(M077) </wsse:KeyIdentifier>
(M078) </wsse:SecurityTokenReference>
(M079) </ds:KeyInfo>
(M080) <xenc:CipherData>
(M081) <xenc:CipherValue>hhx9TcaVL6XwBNl...</xenc:CipherValue>
(M082) </xenc:CipherData>
(M083) </xenc:EncryptedKey>
(M084) </wst:RequestedProofToken>
(M085) <wsp:AppliesTo
xmlns:wsp="http://www.w3.org/ns/ws-policy">
(M086) <wsp:EndpointReference>
(M087) <wsp:Address>
(M088) http://acme.com/ping/
(M089) </wsp:Address>
(M090) </wsp:EndpointReference>
(M091) </wsp:AppliesTo>
(M092) <wst:Entropy>
(M093) <wst:BinarySecret>asdhjwkjqwe123498SDFALasd=
(M094) </wst:BinarySecret>
(M095) </wst:Entropy>
(M096) </wst:RequestSecurityTokenResponse>
(M097) </wst:RequestSecurityTokenResponseCollection>
(M098) ### End unencrypted RSTR
-->
(M099)
</xenc:CipherValue>
(M0100)
</xenc:CipherData>
(M0101)
</xenc:EncryptedData>
(M0102)
</soap:Body>
(M0103)
</soap:Envelope>
Line (M005) indicates to the initiator that th is is the
final response to the RST in an RSTRC.
Lines (M008) – (M011) hold the Timestamp element as required
by the IncludeTimestamp assertion.
Lines (M012) – (M014) contain the recipient’s X.509 token as
required by the RecipientToken assertion’s value (“…/AlwaysToInitiator”).
Lines (M015) – (M035) hold the message signature.
Lines (M036) – (M053) hold the encrypted symmetric key used
to encrypt the RSTR response in the body of the message according to the
bootstrap policy.
Lines (M019) – (M025) indicate the WS-Addressing Action
header is included in the signature as required by the SignedParts assertion.
Line (M026) indicates the Timestamp is included in the
signature according to the IncludeTimestamp assertion definition.
Line (M027) indicates the SOAP Body is included in the
signature as required by the SignedParts assertion.
Lines (M031) – (M033) hold the Security Token Reference
pointing to the requestor’s X.509 certificate.
Lines (M056) – (M102) contain the SOAP Body of the message
with the encrypted RSTR collection element. Commented out is the unencrypted
form of the RSTR collection in Lines (M063) – (M097), which includes one RSTR
(Lines (M064) – (M096)). Lines (M065) – (M069) contain the new Security Context
Token. The accompanying RequestedProofToken in Lines (M070) – (M084) include
the encrypted secret key (Lines (M071) – (M083)) of the security context. The
key is encrypted using the initiator’s public key that was already used to
verify its signature in the incoming request.
According to the Trust13 assertion, the response includes
entropy provided by the recipient as indicated by Lines (M092) – (M095).
An Example of an SCT-secured application message sent from
the initiator to the recipient according to the message input policy (WSS10SecureConversation_input_policy)
is as follows:
(M001)
<?xml version="1.0" encoding="UTF-8"?>
(M002)
<soap:Envelope xmlns:soap="..." xmlns:wsse="..."
xmlns:wsu="..."
xmlns:wst="..."
xmlns:xenc="..." xmlns:wsa="..."
xmlns:wsrm="...">
(M003)
<soap:Header>
(M004)
<wsa:To wsu:Id="to">http://acme.com/ping/</wsa:To>
(M005)
<wsa:MessageID
wsu:Id="msgid">
(M006)
http://acme.com/guid/1231873ledh-CA47-1067-B31D-10662DA
(M007)
</wsa:MessageID>
(M008)
<wsa:Action
wsu:Id="action">urn:Ping</wsa:Action>
(M009)
<wsse:Security>
(M010)
<wsu:Timestamp wsu:Id="timestamp">
(M011)
<wsu:Created>2007-06-17T00:00:00Z</wsu:Created>
(M012)
<wsu:Expires>2007-06-17T23:59:59Z</wsu:Expires>
(M013)
</wsu:Timestamp>
(M014)
<wsc:SecurityContextToken
wsu:Id="SCT">
(M015)
<wsc:Identifier>uuid:91f50600-60cc-11da-8e67-000000000000
(M016)
</wsc:Identifier>
(M017)
</wsc:SecurityContextToken>
(M018)
<wsc:DerivedKeyToken
wsu:Id="DKT">
(M019)
<wsse:SecurityTokenReference>
(M020)
<wsse:Reference
URI="#SCT" ValueType="http://docs.oasis-
open.org/ws-sx/ws-secureconversation/200512/sct"/>
(M021)
</wsse:SecurityTokenReference>
(M022)
<wsc:Offset>0</wsc:Offset>
(M023)
<wsc:Length>24</wsc:Length>
(M024)
<wsc:Label>
WSSecure
ConversationWSSecure Conversation
(M025)
</wsc:Label>
(M026)
<wsc:Nonce>ylN04kFBJesy2U2SQL6ezI3SCak=</wsc:Nonce>
(M027)
</wsc:DerivedKeyToken>
(M028)
<ds:Signature
xmlns:ds="...">
(M029)
<ds:SignedInfo>
(M030)
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
(M031)
<ds:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
(M032)
<ds:Reference
URI="#msgid">
(M033)
<ds:Transforms>
(M034)
<ds:Transform
Algorithm="http://www.w3.org/2001/10/xml-
exc-c14n#"/>
(M035)
</ds:Transforms>
(M036)
<ds:DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
(M037)
<ds:DigestValue>oZKZXftCbY43Wo4w...</ds:DigestValue>
(M038)
</ds:Reference>
(M039)
<ds:Reference
URI="#to">...</ds:Reference>
(M040)
<ds:Reference
URI="#action">...</ds:Reference>
(M041)
<ds:Reference
URI="#timestamp">...</ds:Reference>
(M042)
<ds:Reference URI="#body">...</ds:Reference>
(M043)
</ds:SignedInfo>
(M044)
<ds:SignatureValue>Po9mb0Gw6hWn...</ds:SignatureValue>
(M045)
<ds:KeyInfo>
(M046)
<wsse:SecurityTokenReference>
(M047)
<wsse:Reference
URI="#DKT" ValueType="http://docs.oasis-
open.org/ws-sx/ws-secureconversation/200512/dk"/>
(M048)
</wsse:SecurityTokenReference>
(M049)
</ds:KeyInfo>
(M050)
</ds:Signature>
(M051)
</wsse:Security>
(M052)
</soap:Header>
(M053)
<soap:Body
wsu:Id="body">
(M054)
<pns:Ping
xmlns:pns="http://tempuri.org/">
(M055)
<pns:Text>abc</pns:Text>
(M056)
</pns:Ping>
(M057)
</soap:Body>
(M058)
</soap:Envelope>
Lines (M004) – (M008) contain the WS-Addressing headers
according to the UsingAddressing assertion.
Lines (M010) – (M013) hold the Timestamp as specified by the
IncludeTimestamp assertion within the SymmetricBinding assertion.
Lines (M014) – (M017) contain the Security Context Token
which has been issued by the recipient in the previous message. Based on this
token, the initiator included a Derived Key Token (Lines (M018) – (M027)) as
indicated by the RequireDerivedKey assertion in the policy.
Lines (M028) – (M050) hold the message signature that uses
the Derived Key Token (Lines (M046) – (M048)) to sign the WS-Addressing headers
(Lines (M032) – (M040)), the timestamp (Line (M041)) and the body (Line (M042))
of the message, according to the SignedParts assertion of the message input
policy (WSS10SecureConversation_input_policy).
This document contains non-normative examples of usage of
WS-SecurityPolicy and other related specifications.
Therefore there are no conformance statements that apply
to this document.
Refer to the referenced specifications [References], which will individually contain
conformance requirements for WS-SecurityPolicy and related specifications.
The following individuals have participated in the creation
of this specification and are gratefully acknowledged:
Original Contributors:
Ashok Malhotra, Oracle
Prateek Mishra, Oracle
Ramana Turlapati, Oracle
Participants:
Don Adams, Tibco
Moushmi Banerjee, Oracle
Symon Chang, Oracle
Henry Chung, IBM
Paul Cotton, Microsoft
Marc Goodner, Microsoft
Martin Gudgin, Microsoft
Tony Gullotta, SOA
Jiandong Guo, Sun
Frederick Hirsch, Nokia
Chris Kaler, Microsoft
Rich Levinson, Oracle
Chunlong Liang, IBM
Hal Lockhart, Oracle
Mike Lyons, Layer 7
Ashok Malhotra, Oracle
Carlo Milono, Tibco
Prateek Mishra, Oracle
Anthony Nadalin, Microsoft
Martin Raepple, SAP AG
Bruce Rich, IBM
Ramana Turlapati, Oracle
Greg Whitehead, Hewlett-Packard
Ching-Yun (C.Y.) Chao, IBM
TC Members during the
development of this specification:
Don Adams, Tibco Software Inc.
Jan Alexander, Microsoft Corporation
Steve Anderson, BMC Software
Donal Arundel, IONA Technologies
Howard Bae, Oracle Corporation
Abbie Barbir, Nortel Networks Limited
Charlton Barreto, Adobe Systems
Mighael Botha, Software AG, Inc.
Toufic Boubez, Layer 7 Technologies Inc.
Norman Brickman, Mitre Corporation
Melissa Brumfield, Booz Allen Hamilton
Geoff Bullen, Microsoft Corporation
Lloyd Burch, Novell
Scott Cantor, Internet2
Greg Carpenter, Microsoft Corporation
Steve Carter, Novell
Symon Chang, Oracle Corporation
Ching-Yun (C.Y.) Chao, IBM
Martin Chapman, Oracle Corporation
Kate Cherry, Lockheed Martin
Henry (Hyenvui) Chung, IBM
Luc Clement, Systinet Corp.
Paul Cotton, Microsoft Corporation
Glen Daniels, Sonic Software Corp.
Peter Davis, Neustar, Inc.
Duane DeCouteau, Veterans Health
Administration
Martijn de Boer, SAP AG
Werner Dittmann, Siemens AG
Abdeslem DJAOUI, CCLRC-Rutherford
Appleton Laboratory
Fred Dushin, IONA Technologies
Petr Dvorak, Systinet Corp.
Colleen Evans, Microsoft Corporation
Ruchith Fernando, WSO2
Mark Fussell, Microsoft Corporation
Vijay Gajjala, Microsoft Corporation
Marc Goodner, Microsoft Corporation
Hans Granqvist, VeriSign
Martin Gudgin, Microsoft Corporation
Tony Gullotta, SOA Software Inc.
Jiandong Guo, Sun Microsystems
Phillip Hallam-Baker, VeriSign
Patrick Harding, Ping Identity
Corporation
Heather Hinton, IBM
Frederick Hirsch, Nokia Corporation
Jeff Hodges, Neustar, Inc.
Will Hopkins, Oracle Corporation
Alex Hristov, Otecia Incorporated
John Hughes, PA Consulting
Diane Jordan, IBM
Venugopal K, Sun Microsystems
Chris Kaler, Microsoft Corporation
Dana Kaufman, Forum Systems, Inc.
Paul Knight, Nortel Networks Limited
Ramanathan Krishnamurthy, IONA
Technologies
Christopher Kurt, Microsoft
Corporation
Kelvin Lawrence, IBM
Hubert Le Van Gong, Sun Microsystems
Jong Lee, Oracle Corporation
Rich Levinson, Oracle Corporation
Tommy Lindberg, Dajeil Ltd.
Mark Little, JBoss Inc.
Hal Lockhart, Oracle Corporation Mike Lyons, Layer 7 Technologies Inc.
Eve Maler, Sun Microsystems
Ashok Malhotra, Oracle Corporation
Anand Mani, CrimsonLogic Pte Ltd
Jonathan Marsh, Microsoft Corporation
Robin Martherus, Oracle Corporation
Miko Matsumura, Infravio, Inc.
Gary McAfee, IBM
Michael McIntosh, IBM
John Merrells, Sxip Networks SRL
Jeff Mischkinsky, Oracle Corporation
Prateek Mishra, Oracle Corporation
Bob Morgan, Internet2
Vamsi Motukuru, Oracle Corporation
Raajmohan Na, EDS
Anthony Nadalin, IBM
Andrew Nash, Reactivity, Inc.
Eric Newcomer, IONA Technologies
Duane Nickull, Adobe Systems
Toshihiro Nishimura, Fujitsu Limited
Rob Philpott, RSA Security
Denis Pilipchuk, Oracle Corporation.
Darren Platt, Ping Identity
Corporation
Martin Raepple, SAP AG
Nick Ragouzis, Enosis Group LLC
Prakash Reddy, CA
Alain Regnier, Ricoh Company, Ltd.
Irving Reid, Hewlett-Packard
Bruce Rich, IBM
Tom Rutt, Fujitsu Limited
Maneesh Sahu, Actional Corporation
Frank Siebenlist, Argonne National Laboratory
Joe Smith, Apani Networks
Davanum Srinivas, WSO2
David Staggs, Veterans Health
Administration
Yakov Sverdlov, CA
Gene Thurston, AmberPoint
Victor Valle, IBM
Asir Vedamuthu, Microsoft Corporation
Greg Whitehead, Hewlett-Packard
Ron Williams, IBM
Corinna Witt, Oracle Corporation
Kyle Young, Microsoft Corporation
|
Revision
|
Date
|
Editor
|
Changes Made
|
|
0.09
|
23-Feb-07
|
Rich Levinson
|
Updated doc format to latest OASIS template, added Symon
Chang’s encrypted UsernameToken scenario
|
|
0.10
|
6-Mar-07
|
Rich Levinson
Tony Gullotta
Symon Chang
Martin Raepple
|
Added sample messages and explanatory text to several
examples. Line numbered each example w Pxxx for the Policy, Mxxx for the
sample message. Intent is to do all examples, this version is to get feedback
along with progress as each example stands alone.
Completed examples: 2.1.1.2, 2.1.2.1, 2.1.3, 2.1.4, 2.2.1,
and 2.5.1.
Partially completed examples that have sample messages:
2.1.1.1, 2.1.1.3, 2.3.1.2, 2.3.1.4, 2.3.1.5, and 2.3.2.2, 2.3.2.4, 2.3.2.5
|
