GWD-R (draft-ogf-ogsa-sp-secure-soap-009)
Category: Recommendation
Open Grid Services Architecture Working Group
Duane Merrill, UVa
October 15, 2007
OGSA™ Security Profile 2.0 - Secure SOAP Messaging
Status of This Document
5
This document provides a recommendation to the Grid community on how to secure SOAP
message-layer interactions with OGSA services. This profile describes precisely the
requirements placed on the security mechanisms for communications of such services to ensure
interoperability. Distribution is unlimited.
Copyright Notice
10
Copyright © Open Grid Forum (2007). All Rights Reserved.
Trademarks
OGSA is a trademark of the Open Grid Forum.
ABSTRACT
15
20
25
This document defines the OGSA Security Profile 2.0 – Secure Soap Messaging (OGSA SP –
SSM) profile. The OGSA SP – SSM is an interoperability profile for the secure SOAP message
layer communication of Web services within the context of distributed resource management and
grid computing. This profile is a member of a logical suite of complimentary security profiles
collectively known as “OGSA Security Profile 2.0”, a set of profile documents concerned with
secure communication in the OGSA context. The OGSA SP – SSM is primarily an application of
the WS-I Basic Security Profile 1.0 (WS-I BSP) and its associated specifications to the OGSA
Basic Security Profile 2.0 – Secure Addressing profile for including security policy assertions
within endpoint references. This profile is intended to complement and be applied in conjunction
with the other component profiles within the “OGSA Security Profile 2.0”. The requirements
stated in this profile are concerned with security mechanisms for communications to ensure
mutual authentication, integrity and confidentiality; the profile prescribes the use of these
mechanisms to ensure secure communication of OGSA services within an insecure environment
(i.e., a network having the properties of the Internet Threat Model as defined in RFC 3552).
ogsa-wg@ogf.org
GWD-R (draft-ogf-ogsa-sp-secure-soap-009)
October 15, 2007
CONTENTS
30
35
40
45
50
55
60
65
Abstract ............................................................................................................................................ 1
1
Introduction ............................................................................................................................. 3
2
Document Conventions ........................................................................................................... 4
2.1
Notational Conventions .................................................................................................. 4
2.2
Security Considerations ................................................................................................. 5
2.3
Profile Identification and Versioning ............................................................................... 5
3
Profile Conformance ............................................................................................................... 5
3.1
Conformance Requirements .......................................................................................... 5
3.2
Conformance Targets .................................................................................................... 6
3.3
Conformance Scope ...................................................................................................... 7
3.4
Claiming Conformance ................................................................................................... 7
4
Requirements And Recommendations ................................................................................... 8
4.1
Authentication................................................................................................................. 8
4.2
Integrity Recommendations ........................................................................................... 8
4.3
Confidentiality Recommendations.................................................................................. 8
4.4
Policy Requirements ...................................................................................................... 9
5
Binding Assertion Policies....................................................................................................... 9
5.1
References and Extensibility Points ............................................................................... 9
5.2
Username-Token (USERNAME_TOKEN) Policy ........................................................ 10
5.3
Password Digest Username-Token (PASSWORD_DIGEST) Policy ........................... 10
5.4
Asymmetric X.509 Mutual Authentication (MUTUAL_X509) Policy ............................. 11
6
Example SECURE_EPR....................................................................................................... 11
7
Example SOAP Request Message ....................................................................................... 14
8
Contributors .......................................................................................................................... 15
8.1
Author Information ........................................................................................................ 15
8.2
Acknowledgements ...................................................................................................... 16
8.3
Intellectual Property Statement .................................................................................... 16
8.4
Disclaimer..................................................................................................................... 16
8.5
Full Copyright Notice .................................................................................................... 16
9
References ............................................................................................................................ 16
9.1
Normative References ................................................................................................. 16
9.2
Non-Normative References .......................................................................................... 17
Appendix A. Extensibility Points .................................................................................................... 19
Appendix B. Normative policy documents ..................................................................................... 20
B.1. USERNAME_TOKEN Policy Document ............................................................................ 20
B.2. PASSWORD_DIGEST Policy Document .......................................................................... 20
B.3. MUTUAL_X509 Policy Document ..................................................................................... 20
Appendix C. Referenced Specification Status and Adoption Level Classification ........................ 24
ogsa-wg@ogf.org
2
GWD-R (draft-ogf-ogsa-sp-secure-soap-009)
October 15, 2007
70
1
INTRODUCTION
75
This profile defines a set of conformance statements in order to facilitate the interoperability of
“OGSA services” when using SOAP message layer security. OGSA services are Web services
that are concerned with distributed resource management, grid computing, or other purposes that
involve the modeling and management of stateful entities as profiled by an OGSA Basic Profile.
More specifically, this profile defines normative policy documents identifying commonly-used
message-layer security mechanisms. This profile leverages the OGSA Basic Security Profile 2.0
– Secure Addressing profile to disclose these secure-communication policies to service
consumers within endpoint references. The security mechanisms implied by these policies are
well-defined by external profiles and are incorporated by reference.
80
Normative profiles are useful tools for understanding and defining the interaction amongst
existing Web services specifications in order to achieve interoperability. They are particularly
important within the context of secure communication: common treatment of Web services
security and addressing specifications (e.g., SSL/TLS, WS-Security and related token profiles,
XML-Encryption, XML-Signature, WS-Addressing, etc.) is crucial for real-world interoperability.
85
This document defines the OGSA Security Profile 2.0 – Secure SOAP Messaging (hereafter, “the
Profile”). The Profile is a member of the logical suite of complimentary security profiles
collectively known as “OGSA Security Profile 2.0”. The “OGSA Security Profile 2.0” profiles are
intended to address secure and interoperable interaction within the scope of distributed system
management and grid computing. Within this context, it is the intent of these specifications to:
90

Inherit and refine the requirements defined by the WS-I Basic Security Profile 1.0 [WS-I
BSP], an interoperability profile addressing transport and SOAP messaging security
considerations for basic Web Services.

Provide clarifications, refinements, interpretations and amplifications of other
communication-related specifications (such as WS-Addressing 1.0 – Core) not addressed
by the WS-I BSP

Profile the application of WS-SecurityPolicy 1.2 policy assertions by which securecommunication requirements can be asserted within endpoint references.
95
100
105
In of itself, the suite of OGSA Security Profile 2.0 profiles is not sufficient to guarantee
interoperability of all OGSA services. The purpose of these profiles is to provide a flexible and
extensible profiling of how secure communication requirements are advertised, discovered, and
enacted. The specific secure communication requirements may vary between grid communities.
The intent is for a community to self-select such requirements that are appropriate and then
leverage these profiles as necessary to achieve interoperability between its members (and/or
cleanly discover where interoperability is not possible).
The primary issues addressed in the Profile are as follows:

110
115
Authentication. It is important to ensure communicating parties that they are indeed
communicating with each other, instead of with imposter(s). This is typically
accomplished by having each party cryptographically prove a “fact” about themselves to
the other(s). The caller’s authenticatable “fact” is often useful for making authorization
decisions and for auditing. (Other than being a facilitator to authorization and auditing,
such policy and mechanisms are out of scope of the “OGSA Security Profile 2.0”.) These
authenticatable “facts” are typically in the form of cryptographic identity (e.g., an X.509
certificate), however, other cryptographic tokens (e.g., attributes/privileges) are equally
reasonable. Authentication may be performed at different protocol layers, or in
combination. The Profile defines how authentication can be performed at the message
layer, and how endpoint references to OGSA services requiring such message layer
authentication may indicate this requirement.
ogsa-wg@ogf.org
3
GWD-R (draft-ogf-ogsa-sp-secure-soap-009)
October 15, 2007

Integrity. The Profile recommends that data be protected from modification while in transit
between both ends of a Web service communication. The Profile addresses the use of
message level integrity to ensure data integrity while communicating between two
endpoints.

Confidentiality. The Profile recommends that data not be exposed to third-parties while in
transit between both ends of a Web service communication. The Profile addresses the
use of message level confidentiality to ensure data confidentiality while communicating
between two endpoints.
120
125
OGSA services are not required to use this Profile. OGSA services implementing secure SOAP
messaging that is compliant with this Profile must implement OGSA Basic Security 2.0 – Secure
Addressing and may require compliance with other “OGSA Security Profile 2.0” component
profiles.
130
135
The remainder of this profile is organized as follows. Section 2, "Document Conventions,"
describes notational conventions utilized by the Profile. Section 3, "Profile Conformance,"
explains what it means to be conformant to the Profile. Section 4 describes the global
requirements and recommendations put forth by the Profile. Section 5 defines common binding
assertion policies. Note that there is no relationship between the section numbers in this
document and those in the referenced profiles and specifications.
2
DOCUMENT CONVENTIONS
This Profile is a Recommended Profile as Proposed Recommendation, as defined in the OGSA
Profile Definition [OGSA Profile Definition]. Additional document conventions of the Profile are
defined normatively in WS-I Basic Profile 1.1 [WS-I BP], and are briefly summarized below.
140
2.1
Notational Conventions
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in RFC-2119 (HTTP-TLS).
145
Normative statements of requirements in the Profile (i.e., those impacting conformance, as
outlined in Section 3, “Conformance Requirements") are presented in the following manner:
Rnnnn Statement text here.
where "nnnn" is replaced by a number that is unique among the requirements in the Profile,
thereby forming a unique requirement identifier.
Extensibility points in underlying specifications are presented in a similar manner:
150
Ennnn Extensibility Point Name - Description
where "nnnn" is replaced by a number that is unique among the extensibility points in the Profile.
This specification uses a number of namespace prefixes throughout; their associated URIs are
listed in the table below:
Table 1 Namespaces used by OGSA Security Profile 2.0 – Secure SOAP Messaging
155
soapenv
http://www.w3.org/2003/05/soap-envelope
[SOAP]
wsse
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wsswssecurity-secext-1.0.xsd
[WS-S]
ds
http://www.w3.org/2000/09/xmldsig#
[XML-DigSig]
ogsa-wg@ogf.org
4
GWD-R (draft-ogf-ogsa-sp-secure-soap-009)
October 15, 2007
wsu
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wsswssecurity-utility-1.0.xsd
[WS-S]
wsa
http://www.w3.org/2005/08/addressing
[WSA-Core]
wsp
http://schemas.xmlsoap.org/ws/2004/09/policy
[WS-Policy], [WSPolicyAttachment]
sp
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702
[WSSecurityPolicy]
secsoap
http://www.ogf.org/ogsa/2007/05/sp-secure-soap-messaging
This Document
2.2
Security Considerations
In addition to interoperability requirements (which are made in Rnnnn statements and intended to
improve interoperability), the Profile makes a number of security considerations intended to
improve security. These Security Considerations are presented as follows:
160
Cnnnn Statement text here.
where "nnnn" is replaced by a number that is unique among the security considerations in the
Profile, thereby forming a unique security consideration identifier. Each security consideration
contains a SHOULD or a MAY to highlight exactly what is being considered; however, these
considerations are informational only and are non-normative.
165
2.3
170
This document is identified by a name (in this case, OGSA Security Profile – Secure SOAP
Messaging) and a version number (here, 2.0). Together, they identify a particular profile instance.
Version numbers are composed of a major and minor portion, in the form "major.minor". Version
numbers indicate profile instance precedence: higher version numbers indicate a more recent
instance that supersedes earlier instances.
3
Profile Identification and Versioning
PROFILE CONFORMANCE
Conformance to the Profile is defined by adherence to the set of requirements defined for a
specific target, within the scope of the Profile. This section explains these terms and describes
how conformance is defined and used.
175
3.1
Conformance Requirements
180
Requirements state the criteria for conformance to the Profile. They typically refer to an existing
specification and embody refinements, amplifications, interpretations and clarifications to it in
order to improve interoperability. All requirements in the Profile are considered normative, and
those in the specifications it references that are in-scope (see Section 3.3, “Conformance Scope")
should likewise be considered normative.
Each requirement is individually identified (e.g., R9999) for convenience.
For example;
R9999 Any WIDGET SHOULD be round in shape.
185
This requirement is identified by "R9999", applies to the target WIDGET (see below), and places
a conditional requirement upon widgets; i.e., although this requirement must be met to maintain
conformance in most cases, there are some situations where there may be valid reasons for it not
being met (which are explained in the requirement itself, or in its accompanying text).
ogsa-wg@ogf.org
5
GWD-R (draft-ogf-ogsa-sp-secure-soap-009)
3.2
190
October 15, 2007
Conformance Targets
Conformance targets identify what artifacts (e.g., SOAP message, WSDL description, UDDI
registry data, etc.) or parties (e.g., SOAP processor, end user, etc.) requirements apply to.
This allows for the definition of conformance in different contexts, to assure unambiguous
interpretation of the applicability of requirements, and to allow conformance testing of artifacts
(e.g., SOAP messages and WSDL descriptions) and the behavior of various parties to a Web
service (e.g., clients and service instances).
195
The Profile is an extension of the OGSA Basic Security Profile 2.0 – Secure Addressing [OGSA
BSP-SA] profile. The following conformance targets are inherited from those in the OGSA BSPSA:

POLICY - A collection of POLICY_ALTERNATIVEs. A <wsp:Policy> element is used
in conjunction with its child <wsp:ExactlyOne> element to indicate a policy expression
as a union of POLICY_ALTERNATIVEs. If there are no children of <wsp:ExactlyOne>,
there are no admissible policy alternatives (i.e., no behavior is admissible). If there is
only one logical POLICY_ALTERNATIVE, the compact policy form can be used in which
the requisite POLICY_ASSERTIONs are placed as direct children of the <wsp:Policy>
element and the <wsp:ExactlyOne> and <wsp:All> elements are omitted.

POLICY_ALTERNATIVE - A cohesive collection of POLICY_ASSERTIONs represented
by a <wsp:All> element. The <wsp:All> element is a child of <wsp:ExactlyOne>
and indicates a group of POLICY_ASSERTIONs. If there are no children of <wsp:All>,
this is an admissible policy alternative that is empty (i.e., no behavior is specified).

POLICY_ASSERTION - An individual requirement, capability, other property, or a
behavior. (E.g., the <sp:SignedParts> element is a
SECURITY_BINDING_ASSERTION indicating which portions of a document are to be
signed.)

SECURITY_BINDING_ASSERTION - A POLICY_ASSERTION that identifies the type of
security binding being used to secure an exchange of messages. A security binding is a
set of properties that together provide enough information to secure a given message
exchange.

TOKEN_ASSERTION - A POLICY_ASSERTION that describes a token requirement.
Token assertions defined within a SECURITY_BINDING_ASSERTION are used to
satisfy protection requirements.

POLICY_SUBJECT – A policy subject is an entity (e.g., an endpoint, message, resource,
operation, action, etc.) with which a POLICY can be associated.

POLICY_SCOPE – A policy scope is a collection of POLICY_SUBJECTs to which a
POLICY may apply.

POLICY_ATTACHMENT – A policy attachment is a mechanism for associating policy
with one or more POLICY_SCOPEs. Policy attachments are represented in XML as
<wsp:PolicyAttachment> elements.

ENDPOINT_REFERENCE – A <wsa:EndpointReference> endpoint reference
element as defined by the WS Addressing 1.0 – Core [WSA-Core] specification.

INSTANCE – Software that implements a <wsdl:port>.

INITIATOR – The role sending the initial message in a message exchange.

RECIPIENT - The targeted role to process the initial message in a message exchange.

OGSA_ENDPOINT – An OGSA service resource RECIPIENT, identifiable with an
ENDPOINT_REFERENCE. (An OGSA_ENDPOINT may have a different
200
205
210
215
220
225
230
ogsa-wg@ogf.org
6
GWD-R (draft-ogf-ogsa-sp-secure-soap-009)
October 15, 2007
cryptographic identity than the INSTANCE on which it resides, e.g., when multiple
stateful resources are hosted within the same Web Services container.)
235

SECURE_EPR – a <wsa:EndpointReference> endpoint reference element
conformant to this Profile.

SECURITY_POLICY_ATTACHMENT – A POLICY_ATTACHMENT child of the
SECURE_EPR <wsa:Metadata> element whose POLICY_SUBJECTs are valid
WS-Addressing actions.
240
The Profile defines the following conformance targets:

RECIPIENT_MESSAGE_IDENTITY – a <wsse:SecurityTokenReference> placed
within the <wsa:Metadata> element of an endpoint reference containing an embedded
binary security token of type X509PKIPathv1 as defined in the Web Services Security:
X.509 Token Profile [WS-S: X509 TP]. The binary security token must be identified with
an wsu:Id='RecipientMessageIdentity' attribute.

CRITICAL_SIGNING – SENDER signing of the following SOAP message elements in
accordance with Section 8 of the WS-I BSP:
245
250
270
Any WS-Addressing 1.0 – SOAP Binding [WSA-SOAP] message
addressing property header elements.

MESSAGE_PASSING_INTERMEDIARY – A message-forwarding INSTANCE that
receives a message for which it is not the ultimate RECIPIENT for the message body.

USERNAME_TOKEN – A normative POLICY document indicating that a
Username/Token credential should be supplied in the message security header.

PASSWORD_DIGEST – A normative POLICY document indicating that a
Username/Token credential utilizing a password digest (a hash of a password,
timestamp, and nonce) should be supplied in the message security header.

MUTUAL_X509 – A normative POLICY document indicating a requirement for secure
communication in which both parties have X.509v3 certificates (and corresponding
private keys).
Conformance Scope
The scope of the Profile delineates the technologies that it addresses; in other words, the Profile
only attempts to improve interoperability within its own scope. Generally, the Profile’s scope is
bounded by the specifications referenced by it (Section 7).
Referenced specifications often provide extension mechanisms and unspecified or open-ended
configuration parameters. The Profile defines such extensibility points within referenced
specifications, possibly refining them in the process. The extensibility points exposed by the
Profile are enumerated in Appendix A. These extensibility points (e.g., mechanisms or
parameters) are outside the scope of the Profile, and their use or non-use is not relevant to
conformance.
3.4
275

CRITICAL_ENCRYPTION – SENDER encryption of the entire <soap:body> message
body in accordance with Section 9 of the WS-I BSP.
260
265
The entire <soap:body> message body.

255
3.3

Claiming Conformance
Claims of conformance to the Profile are the same as normatively described in WS-I Basic Profile
1.1 [WS-I BP]. The conformance claim URI for this Profile is
http://www.ogf.org/ogsa/2007/05/sp-secure-soap-messaging
ogsa-wg@ogf.org
7
GWD-R (draft-ogf-ogsa-sp-secure-soap-009)
4
REQUIREMENTS AND RECOMMENDATIONS
4.1
280
October 15, 2007
Authentication
Authentication is a crucial component of secure communication because it exposes imposters
and facilitates authorization and auditing. Message-level authentication requirements are
specified via binding assertion policies (such as those defined within this profile).
This profile makes the following recommendations for authentication:

285
290
This profile places the following constraints on such INSTANCEs that perform message-level
authentication of INITIATORs:

295
C0500 – An INSTANCE SHOULD require that the INITIATOR authenticate itself to the
INSTANCE in some fashion (e.g., at the transport-level as part of the SSL or TLSProtocol as per the OGSA Security Profile 2.0 – Secure Transport profile, at the
message-level as per a client-authenticated secure messaging scheme compliant to
this profile, etc.).
4.2
R0500 – If a message-level client-authentication mechanism is required by an
INSTANCE, any SECURE_EPRs referencing such an INSTANCE MUST disclose the
that mechanism in accordance with the requirements outlined in the OGSA SP-SA and
as refined in Section 5 of this Profile.
Integrity Recommendations
In order to provide data integrity during communication, this Profile recommends signed
communication. The Profile defines the following integrity recommendations:

300
C0501 – In the presence of MESSAGE_PASSING_INTERMEDIARIES, the SENDER
SHOULD perform CRITICAL_SIGNING.
As discussed in Section 5, such signing requirements are indicated in a POLICY ALTERNATIVE
via protection assertions (e.g., <wsp:SignedParts> and <wsp:SignedElements> protection
assertions).

305
310
4.3
C0502 – In the absence of MESSAGE_PASSING_INTERMEDIARIES, a secure
transport layer protocol as profiled by the OGSA Security Profile 2.0 – Secure
Transport profile SHOULD be implemented by the INSTANCE when all of the following
conditions are met:
o
The OGSA_ENDPOINT does not require a message-level client-authentication
scheme that implicitly requires signing.
o
The OGSA_ENDPOINT does not explicitly require a message-level encryption or
signing action.
Confidentiality Recommendations
In order to provide confidentiality during communication, this Profile recommends encrypted
communication. The Profile defines the following confidentiality recommendations:

C0503 – In the presence of MESSAGE_PASSING_INTERMEDIARIES, the SENDER
SHOULD perform CRITICAL_ENCRYPTION.

C0504 – In the absence of MESSAGE_PASSING_INTERMEDIARIES and
CRITICAL_ENCRYPTION, a secure transport layer protocol as profiled by the OGSA
Security Profile 2.0 – Secure Transport profile SHOULD be implemented by the
INSTANCE to ensure data confidentiality.
315
ogsa-wg@ogf.org
8
GWD-R (draft-ogf-ogsa-sp-secure-soap-009)
320
4.4
October 15, 2007
Policy Requirements
SECURE_EPRs contain POLICY_ATTACHMENTS specifying the security requirements (and
ancillary tokens) needed for communication with an OGSA_ENDPOINT.

325
R0501 – A SECURE_EPR MUST contain at least one
SECURITY_POLICY_ATTACHMENT referencing at least one POLICY element
containing a message-level SECURITY_BINDING_ASSERTION as profiled within this
Profile (or within a derivative of this Profile as per E0501).
Table 3 below enumerates such binding policies defined within Section 5 of this profile:
Table 2 Secure Message Binding Policies
Binding Policy
Name
Conformance Claim
Policy Reference URI
Username Token
USERNAME_TOKEN
http://www.ogf.org/ogsa/2007/05/spsecure-soap#UsernameToken
Password Digest
Username Token
PASSWORD_DIGEST
http://www.ogf.org/ogsa/2007/05/spsecure-soap#PasswordDigest
Asymmetric X.509
Mutual Authentication
MUTUAL_X509
http://www.ogf.org/ogsa/2007/05/spsecure-soap#MutualX509
330
5
BINDING ASSERTION POLICIES
This section defines several binding assertion policies that identify commonly-used security
mechanisms. The security mechanisms implied by these policies are defined and profiled
externally and incorporated by reference.
335
5.1
References and Extensibility Points
This profile incorporates by reference the following sections of WS-I Basic Security Profile
Version 1.0 [WS-I BSP] and referenced specifications:
340
345
350

Section 4, “SOAP Nodes and Messages”

Section 5, “Security Headers”

Section 6, “Timestamps”

Section 7, “Security Token References”

Section 8, “XML Signature”

Section 9, “XML Encryption”

Section 10, “Binary Security Tokens”

Section 11, “Username Token”

Section 12, “X.509 Certificate Token
Other sections of the WS-I BSP are considered out of scope of the Profile because they either (a)
pertain to security token profiles not identified by policies profiled within this document or (b)
pertain to transport-level security mechanisms. The Profile inherits and refines the following
extensibility points from these sections of the WS-I BSP:
ogsa-wg@ogf.org
9
GWD-R (draft-ogf-ogsa-sp-secure-soap-009)

355

E0301 – WS-Addressing Extensibility – WS-Addressing allows extensibility elements for
the <wsa:EndpointReference> element.

E0302 – WS-Addressing Metadata Extensibility – WS-Addressing allows extensibility
elements for metadata as children of the <wsa:Metadata> element.

E0303 – WS-Addressing Reference Parameters Extensibility – WS Addressing allows
extensibility elements for Reference Parameters as children of the
<wsa:ReferenceParameters> element

E0304 – WS-PolicyAttachment “Applies-to” Extensibility – WS-PolicyAttachment requires
that the <wsp:AppliesTo> element be extended in order to define a domain
expression for identifying policy scope.

E0305 – WS-Addressing Metadata Extensibility – WS-Addressing allows extensibility
elements for metadata as children of the <wsa:Metadata> element.

E0306 – WS-SecurityPolicy Token Assertion Extensibility – WS-SecurityPolicy allows the
extensibility of token assertions.
365
This Profile defines the following extensibility points:

5.2
375
The USERNAME_TOKEN policy is a referenceable message-level binding policy indicating that a
Username/Token credential should be supplied in the message security header in accordance
with the Section 11 of the WS-I Basic Security Profile Version 1.0 (WS-I BSP). The normative
policy document for the USERNAME_TOKEN policy is defined in Appendix B.
380
5.3
R0502 – The actions upon an OGSA_ENDPOINT for which the USERNAME_TOKEN
policy is advertised MUST support a Username/Token credential in accordance with
the WS-I BSP as per the semantics of the USERNAME_TOKEN policy document
defined in Appendix B.
Password Digest Username-Token (PASSWORD_DIGEST) Policy
The PASSWORD_DIGEST policy is a referenceable message-level binding policy indicating that
a Username/Token credential utilizing a password digest (a hash of a password, timestamp, and
nonce) should be supplied in the message security header in accordance with the Section 11 of
the WS-I Basic Security Profile Version 1.0 (WS-I BSP). The normative policy document for the
PASSWORD_DIGEST policy is defined in Appendix B.

390
E0501 – Additional message-level SECURITY_BINDING_ASSERTIONs may be profiled
in accordance to the requirements in Section 5.1: Security Mechanism Specifics.
Username-Token (USERNAME_TOKEN) Policy

385
E0002 – Security Tokens – Security tokens may be specified in additional security token
profiles.
The Profile additionally incorporates by reference the OGSA Basic Security Profile 2.0 – Secure
Addressing (OGSA SP-SA) profile and referenced specifications. The Profile inherits and refines
the following extensibility points from the OGSA SP-SA:
360
370
October 15, 2007
R0503 – The actions upon an OGSA_ENDPOINT for which the PASSWORD_DIGEST
policy is advertised MUST support a password-digest Username/Token credential in
accordance with the WS-I BSP as per the semantics of the USERNAME_TOKEN
policy document defined in Appendix B.
ogsa-wg@ogf.org
10
GWD-R (draft-ogf-ogsa-sp-secure-soap-009)
5.4
395
400
October 15, 2007
Asymmetric X.509 Mutual Authentication (MUTUAL_X509) Policy
The MUTUAL_X509 policy is a referenceable message-level binding policy indicating a
requirement for secure communication in which both parties have X.509v3 certificates (and
corresponding private keys).
At a minimum, this policy requires a signature over a request message covering the
<soapenv:Body> message body as well as any message-addressing headers. If a response
message is sent, this policy requires a signature over the response message that covers the
<soapenv:Body> message body. (This profile defines a message-addressing header as a child
element of the <soapenv:Header> that is either declared under the wsa: namespace or has a
‘wsa:IsReferenceParameter=true’ attribute.)
The normative policy document for the MUTUAL_X509 policy is defined in Appendix B.

R0504 – The actions upon an OGSA_ENDPOINT for which the MUTUAL_X509 policy is
advertised MUST support an X.509-based mutually-authenticated message exchange
in accordance with the WS-I BSP as per the semantics of the MUTUAL_X509 policy
document defined in Appendix B.

R0505 – The enclosing SECURE_EPR MUST provide a
RECIPIENT_MESSAGE_IDENTITY for which the <sp:X509Token> element within
the MUTUAL_X509 policy document’s RecipientToken refers to.

C0505 – SECURE_EPRs that incorporate the MUTUAL_X509 policy MAY specify
additional portions of the message documents to be signed and/or encrypted. These
additional requirements are (optionally) specified as siblings of the SECURE_EPR’s
<wsp:PolicyReference>http://www.ggf.org/ogsa/2007/05/sp-securesoap#MutualX509</wsp:PolicyReference> element.
405
410
415
6
EXAMPLE SECURE_EPR
420
The following shows an example SECURE_EPR conformant to the Profile. This example
provides two alternatives for secure communication with the OGSA_ENDPOINT: (a) usernametoken authentication of the client over server-authenticated TLS, and (b) mutually authenticated
X.509 message-level communication in which message exchange is integrity protected and
encrypted. The EPR is also signed to facilitate trust verification.
It should be noted that several of the components of the policies shown in this example are
profiled in the OGSA Security Profile 2.0 – Secure Transport (OGSA SP – ST) profile and are
shown here for illustrative purposes only.
425
430
435
440
(01)
(02)
(03)
(04)
(05)
(06)
(07)
(08)
(09)
(10)
(11)
(12)
(13)
(14)
(15)
(16)
(17)
(18)
(19)
<wsa:EndpointReference>
<wsa:Address wsu:Id='TheAddress'>
http://www.example.org/some/path
</wsa:Address>
<wsa:ReferenceParameters wsu:Id='TheRefParams'>
...
</wsa:ReferenceParameters>
<wsa:Metadata wsu:Id='TheMetadata'>
<!-- This policy attachment applies to all actions on this endpoint -->
<wsp:PolicyAttachment>
<wsp:AppliesTo>
<wsp:URI>urn:wsaaction:*</wsp:URI>
</wsp:AppliesTo>
<!-- Collection of policy alternatives -->
ogsa-wg@ogf.org
11
GWD-R (draft-ogf-ogsa-sp-secure-soap-009)
445
450
455
460
465
470
475
480
485
490
495
500
505
510
October 15, 2007
(20)
<wsp:Policy>
(21)
<wsp:ExactlyOne>
(22)
(23)
<!-- Alternative 1: Server-authenticated TLS + Username-token -->
(24)
<wsp:All>
(25)
<wsp:PolicyReference>
(26)
http://www.ggf.org/ogsa/2007/05/sp-securetransport#CertifiedServerTLS
(27)
</wsp:PolicyReference>
(28)
<wsp:PolicyReference>
(29)
http://www.ggf.org/ogsa/2007/05/sp-secure-soap#UsernameToken
(30)
</wsp:PolicyReference>
(31)
</wsp:All>
(32)
(33)
<!-- Alternative 2: X.509 msg-lvl authN + msg-body encryption -->
(34)
<wsp:All>
(35)
<wsp:PolicyReference>
(36)
http://www.ggf.org/ogsa/2007/05/sp-secure-soap#MutualX509
(37)
</wsp:PolicyReference>
(38)
<wsp:Policy wsu:Id=”SupplementalInputPolicy”>
(39)
<sp:EncryptedParts>
(40)
<sp:Body/>
(41)
</sp:EncryptedParts>
(42)
</wsp:Policy>
(43)
<wsp:Policy wsu:Id=”SupplementalOutputPolicy”>
(44)
<sp:EncryptedParts>
(45)
<sp:Body/>
(46)
</sp:EncryptedParts>
(47)
</wsp:Policy>
(48)
</wsp:All>
(49)
(50)
</wsp:ExactlyOne>
(51)
</wsp:Policy>
(52)
</wsp:PolicyAttachment>
(53)
...
(54)
<!-- X.509 recipient cert to be used for hostname verification during
(55)
server-authenticated TLS policy alternative -->
(56)
<wsse:SecurityTokenReference>
(57)
<wsse:Embedded>
(58)
<wsse:BinarySecurityToken
(59)
wsu:Id='RecipientTransportIdentity'
(60)
ValueType="http://docs.oasis...x509-token-profile-1.0#X509v3"
(61)
EncodingType="http://docs.oasis...security-1.0#Base64Binary">
(62)
MIIC.....
(63)
</wsse:BinarySecurityToken>
(64)
</wsse:Embedded>
(65)
</wsse:SecurityTokenReference>
(66)
(67)
<!-- X.509 recipient cert to be used for message-level encryption during
(68)
X.509 message-level alternative -->
(69)
<wsse:SecurityTokenReference>
(70)
<wsse:Embedded>
(71)
<wsse:BinarySecurityToken
(72)
wsu:Id='RecipientMessageIdentity'
(73)
ValueType="http://...x509-token-profile-1.0# X509PKIPathv1"
(74)
EncodingType="http://docs.oasis...security-1.0#Base64Binary">
(75)
MIIC.....
(76)
</wsse:BinarySecurityToken>
(77)
</wsse:Embedded>
(78)
</wsse:SecurityTokenReference>
(79)
...
(80)
</wsa:Metadata>
(81)
(82)
<!-- Digital Signature of the EPR document -->
(83)
<ds:Signature xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
(84)
<ds:SignedInfo>
(85)
<ds:CanonicalizationMethod Algorithm='http://.../xml-exc-c14n#'/>
(86)
<ds:SignatureMethod Algorithm='http://.../xmldsig#rsa-sha1'/>
(87)
<ds:Reference URI='#TheAddress'>
(88)
<ds:Transforms>
(89)
<ds:Transform Algorithm='http://.../xml-exc-c14n#'/>
ogsa-wg@ogf.org
12
GWD-R (draft-ogf-ogsa-sp-secure-soap-009)
515
520
525
530
535
540
545
550
(90)
(91)
(92)
(93)
(94)
(95)
(96)
(97)
(98)
(99)
(100)
(101)
(102)
(103)
(104)
(105)
(106)
(107)
(108)
(109)
(110)
(111)
(112)
(113)
(114)
(115)
(116)
(117)
(118)
(119)
(120)
(121)
(122)
(123)
</ds:Transforms>
<ds:DigestMethod Algorithm='http://.../xmldsig#sha1'/>
<ds:DigestValue>+VTJraRYFT3pl7Z4uAWhmr5+bf4=</ds:DigestValue>
</ds:Reference>
<ds:Reference URI='#TheRefParams'>
<ds:Transforms>
<ds:Transform Algorithm='http://.../xml-exc-c14n#'/>
</ds:Transforms>
<ds:DigestMethod Algorithm='http://.../xmldsig#sha1'/>
<ds:DigestValue>+VTJraRYFT3pl7Z4uAWhmr5+bf4=</ds:DigestValue>
</ds:Reference>
<ds:Reference URI='#TheMetadata'>
<ds:Transforms>
<ds:Transform Algorithm='http://.../xml-exc-c14n#'/>
</ds:Transforms>
<ds:DigestMethod Algorithm='http://.../xmldsig#sha1'/>
<ds:DigestValue>+VTJraRYFT3pl7Z4uAWhmr5+bf4=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>+diIuEyDpV7qxVoUOkb5rj61+Zs=</ds:SignatureValue>
<ds:KeyInfo>
<wsse:SecurityTokenReference>
<wsse:Embedded>
<wsse:BinarySecurityToken wsu:Id='SomeCert'
ValueType="http://...-wss-x509-token-profile-1.0#X509v3"
EncodingType="http://...-message-security-1.0#Base64Binary">
GJW5xM3aHnLxOpGVIpzSg4V486hHFe7sHET/uxxVBovT7JV1A2RnWSWkXm9jAEdsm/...
</wsse:BinarySecurityToken>
</wsse:Embedded>
</wsse:SecurityTokenReference>
</ds:KeyInfo>
</ds:Signature>
</wsa:EndpointReference>

Lines 01-123: An example ENDPOINT_REFERENCE.

Lines 14-52: An example of a POLICY ATTACHMENT element is shown.

Lines 15-17: The <wsp:AppliesTo> element indicates that the subsequent policies are
within scope for all supported WS-Addressing actions.

Lines 20-51: An enclosing POLICY containing a set of two mutually-exclusive policy
alternatives.

Lines 24-31: A POLICY ALTERNATIVE indicating username-token authentication of the
client over server-authenticated TLS. The <wsp:TransportBinding> policy
referenced is defined in Section 5.1.1 of the OGSA Security Profile 2.0 – Secure
Transport profile. The referenced <wsp:SupportingToken> policy indicating
username-token is defined in Section 5.2.2 of the OGSA Security Profile 2.0 – Secure
Soap Messaging profile.

Lines 36-49: A POLICY ALTERNATIVE indicating mutually authenticated X.509
message-level communication in which message exchange is integrity protected and
encrypted. The particular “MutualX509” binding assertion policy is defined in Section
5.2.1 of the OGSA Security Profile 2.0 – Secure Soap Messaging profile.

Lines 38-47: Additional “InputPolicy” and “OutputPolicy” policy expressions that
supplement those defined in elsewhere in the POLICY_ALTERNATIVE (i.e., inside the
“MutualX509” binding assertion policy) in order to denote the requirement for
input/output message body encryption.

Lines 56-65: The embedded X.509 certificate that is referenced within the
http://www.ggf.org/ogsa/2007/05/sp-secure-transport#CertifiedServerTLS transport
555
560
565
570
October 15, 2007
ogsa-wg@ogf.org
13
GWD-R (draft-ogf-ogsa-sp-secure-soap-009)
October 15, 2007
binding assertion. For more information, see the OGSA Security Profile 2.0 – Secure
Transport profile.

Lines 69-78: The embedded X.509 certificate that is referenced within the
http://www.ggf.org/ogsa/2007/05/sp-secure-soap#MutualX509 message-level asymmetric
binding assertion.

Lines 83-121: The XML digital signature indicating the minter of the EPR and providing
protection against tampering

Lines 87-93: Signature reference indicating that the signature covers the
<wsa:Address> data object.

Lines 84-100: Signature reference indicating that the signature covers the
<wsa:ReferenceProperties> data object.

Lines 101-107: Signature reference indicating that the signature covers the
<wsa:Metadata> data object.

Lines 110-120: <ds:KeyInfo> element indicating the X.509 identity of the EPR minter,
which includes the public key necessary for signature verification.
575
580
585
7
590
595
600
605
610
615
620
625
EXAMPLE SOAP REQUEST MESSAGE
The following shows an example of an input message to an RNS OGSA_ENDPOINT performing
a list operation that conforms to the above EPR policy. (The Remote Naming Service
specification defines a directory/namespace service.)
(01)
(02)
(03)
(04)
(05)
(06)
(07)
(08)
(09)
(10)
(11)
(12)
(13)
(14)
(15)
(16)
(17)
(18)
(19)
(20)
(21)
(22)
(23)
(24)
(25)
(26)
(27)
(28)
(29)
(30)
(31)
(32)
(33)
(34)
(35)
(36)
(37)
<?xml version="1.0" encoding="utf-8"?>
<soapenv:Envelope
xmlns:soapenv=".../envelope/"
xmlns:xsd=".../XMLSchema"
xmlns:xsi=".../XMLSchema-instance"
xmlns:wsu="...-wss-wssecurity-utility-1.0.xsd"
xmlns:wsse="...-wss-wssecurity-secext-1.0.xsd"
xmlns:wsa=".../addressing"
xmlns:ds=".../xmldsig#">
<soapenv:Header>
<wsse:Security soapenv:mustUnderstand="1">
<wsse:BinarySecurityToken
EncodingType="...-wss-soap-message-security-1.0#Base64Binary"
ValueType="...-wss-x509-token-profile-1.0#X509v3"
wsu:Id="CertId-2891833">MIIDqjCCAp...</wsse:BinarySecurityToken>
<ds:Signature Id="Signature-10923886">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm=".../xml-exc-c14n#">
</ds:CanonicalizationMethod>
<ds:SignatureMethod Algorithm=".../xmldsig#rsa-sha1">
</ds:SignatureMethod>
<ds:Reference URI="#id-28713819">
<ds:Transforms>
<ds:Transform Algorithm=".../xml-exc-c14n#">
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm=".../xmldsig#sha1">
</ds:DigestMethod>
<ds:DigestValue>u+KE5lscRkzx2dTFim8S5Bpn9i4=</ds:DigestValue>
</ds:Reference>
<ds:Reference URI="#id-08675309">
<ds:Transforms>
<ds:Transform Algorithm=".../xml-exc-c14n#">
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm=".../xmldsig#sha1">
</ds:DigestMethod>
ogsa-wg@ogf.org
14
GWD-R (draft-ogf-ogsa-sp-secure-soap-009)
630
635
640
645
650
655
(38)
(39)
(40)
(41)
(42)
(43)
(44)
(45)
(46)
(47)
(48)
(49)
(50)
(51)
(52)
(53)
(54)
(55)
(56)
(57)
(58)
(59)
(60)
(61)
(62)
(63)
(64)
(65)
(66)
(67)
(68)
October 15, 2007
<ds:DigestValue>sZHtJewewO40zT9K76NJ5hKNAoc=</ds:DigestValue>
</ds:Reference>
<ds:Reference URI="#id-13320911">
<ds:Transforms>
<ds:Transform Algorithm=".../xml-exc-c14n#">
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm=".../xmldsig#sha1">
</ds:DigestMethod>
<ds:DigestValue>5oHvfCRfo89/PDJ72u97uQa8ds0=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>fQ6bwvRjQ8...</ds:SignatureValue>
<ds:KeyInfo Id="KeyId-29398564">
<wsse:SecurityTokenReference wsu:Id="STRId-19608393">
<wsse:Reference URI="#CertId-2891833"
ValueType="...-wss-x509-token-profile-1.0#X509v3"/>
</wsse:SecurityTokenReference>
</ds:KeyInfo>
</ds:Signature>
</wsse:Security>
<wsa:To wsu:Id="id-28713819”>
https://vcgr.cs.virginia.edu:18080/axis/services/RNSPortType</wsa:To>
<wsa:Action wsu:Id="id-08675309”>list</wsa:Action>
</soapenv:Header>
<soapenv:Body wsu:Id="id-13320911">
<list xmlns=".../rns">
<entry_name_regexp>.*</entry_name_regexp>
</list>
</soapenv:Body>
</soapenv:Envelope>
660

Lines 01-68: An example input message to an RNS OGSA_ENDPOINT.

Lines 11-58: The WS-S SOAP message security header

Lines 12-15: The SENDER’s X.509 v.3 certificate used to sign the message.

Lines 17-49: SignedInfo description of the signature and canonicalization algorithms
used, as well as references to the portions of the SOAP message that are signed. In this
case, signing is done in accordance with the SHA1/RSA signature/digest algorithms in
accordance with the WSI-BSP. Lines 22-30 indicate the digest used for the signing of the
WS-Addressing To header. Lines 31-39 indicate the digest used for the signing of the
WS-Addressing Action header. Lines 40-48 indicate the digest used for the signing of
the message body.

Line 50: The signature of the digests contained within the SignedInfo element.

Lines 42-47: Binding of the X.509 v.3 certificate in Lines 12-15 to the signature.

Lines 59-60: WS-Addressing To header

Line 61: WS-Addressing Action header.

Lines 63-67: SOAP message body indicating a wildcard listing of the RNS
OGSA_ENDPOINT’s entries.
665
670
675
8
8.1
680
CONTRIBUTORS
Author Information
Duane Merrill
Computer Science Department
ogsa-wg@ogf.org
15
GWD-R (draft-ogf-ogsa-sp-secure-soap-009)
October 15, 2007
University of Virginia
Charlottesville, VA 22903
Email: dgm4d@cs.virginia.edu
685
8.2
Acknowledgements
We are grateful to colleagues for discussions on the topics covered in this document, in particular
(in alphabetical order, with apologies to anybody we've missed) Blair Dillaway, Andrew
Grimshaw, John Karpovich, Hiro Kishimoto, Mark Morgan, and Andreas Savva. Much of the
format, rigor, and conventions of the Profile have been adapted from the WS-I Basic Profile 1.1.
690
695
700
8.3
Intellectual Property Statement
The OGF takes no position regarding the validity or scope of any intellectual property or other
rights that might be claimed to pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights might or might not be
available; neither does it represent that it has made any effort to identify any such rights. Copies
of claims of rights made available for publication and any assurances of licenses to be made
available, or the result of an attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this specification can be obtained from the
OGF Secretariat.
The OGF invites any interested party to bring to its attention any copyrights, patents or patent
applications, or other proprietary rights which may cover technology that may be required to
practice this recommendation. Please address the information to the OGF Executive Director.
8.4
705
Disclaimer
This document and the information contained herein is provided on an “As Is” basis and the OGF
disclaims all warranties, express or implied, including but not limited to any warranty that the use
of the information herein will not infringe any rights or any implied warranties of merchantability or
fitness for a particular purpose.
8.5
Full Copyright Notice
Copyright (C) Open Grid Forum (2007). All Rights Reserved.
710
715
This document and translations of it may be copied and furnished to others, and derivative works
that comment on or otherwise explain it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction of any kind, provided that the
above copyright notice and this paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such as by removing the copyright
notice or references to the OGF or other organizations, except as needed for the purpose of
developing Grid Recommendations in which case the procedures for copyrights defined in the
OGF Document process must be followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be revoked by the OGF or its
successors or assignees.
720
9
REFERENCES
9.1
Normative References

[SOAP] M. Gudgin, M. Hadley, N. Mendelsohn, J. Moreau, H. Nielsen, A. Karmarkar, Y.
Lafon (ed.): SOAP Version 1.2 Part 1: Messaging Framework (Second Edition), W3C
ogsa-wg@ogf.org
16
GWD-R (draft-ogf-ogsa-sp-secure-soap-009)
October 15, 2007
Recommendation, 27 April 2007, http://www.w3.org/TR/2007/REC-soap12-part120070427/
725

[RFC2119] S. Bradner (ed.): Key words for use in RFCs to Indicate Requirement Levels,
The Internet Engineering Task Force Best Current Practice, March 1997.
http://www.ietf.org/rfc/rfc2119

[HTTP-TLS] E. Rescorla (ed.): HTTP Over TLS, Internet Engineering Task Force, May
2000. http://www.ietf.org/rfc/rfc2818

[TLS 1.0] T. Dierks, C. Allen (ed.): The TLS Protocol Version 1.0, Internet Engineering
Task Force, January 1999. http://www.ietf.org/rfc/rfc2246

[WS-A Core] M. Gudgin, Marc Hadley, T. Rogers (ed.), Web Services Addressing 1.0 Core, W3C Recommendation, 9 May 2006, http://www.w3.org/TR/2006/REC-ws-addrcore-20060509/

[WS-A SOAP] M. Gudgin, Marc Hadley, T. Rogers (ed.), Web Services Addressing 1.0 –
SOAP Binding, W3C Recommendation, 9 May 2006, http://www.w3.org/TR/2006/RECws-addr-soap-20060509/

[WS-I BP 1.1] K. Ballinger, D. Ehnebuske, C. Ferris, M. Gudgin, C.K. Liu, M. Nottingham,
and P. Yendluri (ed.): Basic Profile Version 1.1, Web Services Interoperability
Organization Final Material, 24 August 2004. http://www.ws-i.org/Profiles/BasicProfile1.1.html

[WS-I BSP 1.0] A. Barbir, M. Gudgin, M. McIntosh, and K.S. Morrison (ed.): Basic
Security Profile Version 1.0, Web Services Interoperability Organization, Working Group
Draft, 17 August 2006. http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0-2006-0817.html

[X.509] Information Technology - Open Systems Interconnection - The Directory:
Authentication Framework, 08/05. http://www.itu.int/rec/T-REC-X.509-200508-I

[WS-Policy] A. Vedamuthu, D. Orchard, F. Hirsch, M. Hondo, P. Yendluri, T. Boubez, Ü.
Yalçinalp (ed.): Web Services Policy 1.5 – Framework. W3C Candidate
Recommendation, 05 June 2007. http://www.w3.org/TR/2007/CR-ws-policy-20070605

[WS-SecurityPolicy] A. Nadalin, M. Goodner, A. Barbir, H. Granqvist (ed.): WSSecurityPolicy 1.2. Committee Specification, 30 April 2007. http://docs.oasisopen.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-cs.pdf

[WS-PolicyAttachment] A. Vedamuthu, D. Orchard, F. Hirsch, M. Hondo, P. Yendluri, T.
Boubez, Ü. Yalçinalp (ed.): Web Services Policy 1.5 – Attachment. W3C Candidate
Recommendation 05 June 2007. http://www.w3.org/TR/2007/CR-ws-policy-attach20070605

[OGSA SP – SA] D. Merrill: OGSA Basic Security Profile 2.0 –Secure Addressing.
Global Grid Forum OGSA-WG, Draft, 01 May 2007

[OGSA SP – ST] D. Merrill: OGSA Security Profile 2.0 –Secure Transport. Global Grid
Forum OGSA-WG, Draft, 01 May 2007
730
735
740
745
750
755
760
9.2
Non-Normative References

[OGSA WSRF BP] I. Foster., T. Maguire. and D. Snelling.: OGSA WSRF Basic Profile
1.0. Open Grid Forum, Lemont, Illinois, USA, GFD-R.P.072,
http://www.ogf.org/gf/docs/?final

[WS-S] A. Nadalin, C. Kaler, P. Hallam-Baker and R. Monzillo (ed.): Web Services
Security: SOAP Message Security 1.0 (WS-Security 2004), OASIS Standard, 200401,
765
ogsa-wg@ogf.org
17
GWD-R (draft-ogf-ogsa-sp-secure-soap-009)
March 2004. http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-messagesecurity-1.0.pdf
770
775
October 15, 2007

[XML-DigSig] D. Eastlake, J. Reagle, D. Solo (ed.): XML-Signature Syntax and
Processing, W3C Recommendation, Feb 12, 2002. http://www.w3.org/TR/xmldsig-core/

[XML-Enc] D. Eastlake, J. Reagle (ed.): XML Encryption Syntax and Processing, W3C
Recommendation, Dec 10, 2002. http://www.w3.org/TR/xmlenc-core/

[OGSA Profile Definition] T. Maguire. and D. Snelling: OGSA Profile Definition Version
1.0. Open Grid Forum, Lemont, Illinois, U.S.A., GFD-I.059, January 2006.
http://www.ogf.org/gf/docs/?final
ogsa-wg@ogf.org
18
GWD-R (draft-ogf-ogsa-sp-secure-soap-009)
October 15, 2007
APPENDIX A. EXTENSIBILITY POINTS
780
This section identifies extensibility points for the Profile's component specifications. These
mechanisms are out of the scope of the Profile; their use may affect interoperability, and may
require private agreement between the parties to a Web service.
In WS-I Basic Security Profile 1.0 [WS-I BSP]:
785

E0002 – Security Tokens – Security tokens may be specified in additional security token
profiles.

E0012 – Certificate Authority – The choice of the Certificate Authority is a private
agreement between parties.

E0013 – Certificate Extensions – X.509 allows for arbitrary certificate extensions.
In OGSA Basic Security Profile 2.0 – Secure Addressing [OGSA SP-SA]:

E0301 – WS-Addressing Extensibility – WS-Addressing allows extensibility elements for
the <wsa:EndpointReference> element.

E0302 – WS-Addressing Metadata Extensibility – WS-Addressing allows extensibility
elements for metadata as children of the <wsa:Metadata> element.

E0303 – WS-Addressing Reference Parameters Extensibility – WS Addressing allows
extensibility elements for Reference Parameters as children of the
<wsa:ReferenceParameters> element

E0304 – WS-PolicyAttachment “AppliesTo” Extensibility – WS-PolicyAttachment requires
that the <wsp:AppliesTo> element be extended in order to define a domain
expression for identifying policy scope.

E0305 – WS-Addressing Metadata Extensibility – WS-Addressing allows extensibility
elements for metadata as children of the <wsa:Metadata> element.

E0306 – WS-SecurityPolicy Token Assertion Extensibility – WS-SecurityPolicy allows the
extensibility of token assertions.
790
795
800
In OGSA Security Profile 2.0 – Secure SOAP Messaging [OGSA SP-SSM]:

805
E0501 – Additional message-level binding assertions may be profiled in accordance to
the requirements in Section 5.1: Security Mechanism Specifics.
ogsa-wg@ogf.org
19
GWD-R (draft-ogf-ogsa-sp-secure-soap-009)
October 15, 2007
APPENDIX B. NORMATIVE POLICY DOCUMENTS
This appendix defines the normative policy documents introduced by the Profile along with nonnormative descriptions.
B.1. USERNAME_TOKEN Policy Document
810
815
820
The normative policy document for the USERNAME_TOKEN policy is as follows:
(01)
<?xml version="1.0" encoding="UTF-8"?>
(02)
<wsp:Policy wsu:Id=”UsernameToken”
(03)
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
(04)
xmlns:sp="http://docs.oasis-open.org/ws-sx/wssecuritypolicy/200702"><wsp:Policy wsu:Id=”UsernameToken”>
(05)
<sp:SupportingTokens>
(06)
<wsp:Policy>
(07)
<sp:UsernameToken/>
(08)
</wsp:Policy>
(09)
</sp:SupportingTokens>
(10)
</wsp:Policy>
Below is a detailed non-normative description for the USERNAME_TOKEN policy document:
825
o
Lines 06–10 contain the <sp:SupportingTokens> assertion which includes a
<sp:UsernameToken> indicating that a UsernameToken must be included in the
security header.
B.2. PASSWORD_DIGEST Policy Document
The normative policy document for the PASSWORD_DIGEST policy is as follows:
830
835
840
845
(01)
<?xml version="1.0" encoding="UTF-8"?>
(02)
<wsp:Policy wsu:Id=”PasswordDigest”
(03)
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
(04)
xmlns:sp="http://docs.oasis-open.org/ws-sx/wssecuritypolicy/200702">
(05)
<sp:SupportingTokens>
(06)
<wsp:Policy>
(07)
<sp:UsernameToken>
(08)
<wsp:Policy>
(09)
<sp:HashPassword/>
(10)
</wsp:Policy>
(11)
</sp:UsernameToken>
(12)
</wsp:Policy>
(13)
</sp:SupportingTokens>
(14)
</wsp:Policy>
Below is a detailed non-normative description for the PASSWORD_DIGEST policy document:
o
Lines 05–13: contain the <sp:SupportingTokens> assertion which includes a
<sp:UsernameToken> indicating that a UsernameToken must be included in the
security header.
o
Line 08 – 10: Sub-policy requiring that the password be protected by combining it
with a nonce and timestamp, and then hashing the combination.
850
B.3. MUTUAL_X509 Policy Document
The normative policy document for the MUTUAL_X509 policy is as follows:
ogsa-wg@ogf.org
20
GWD-R (draft-ogf-ogsa-sp-secure-soap-009)
October 15, 2007
855
860
865
870
875
880
885
890
895
900
905
910
915
920
(01)
<?xml version="1.0" encoding="UTF-8"?>
(02)
<wsp:Policy wsu:Id=”MutualX509”
(03)
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
(04)
xmlns:sp="http://docs.oasis-open.org/ws-sx/wssecuritypolicy/200702">
(05)
<wsp:ExactlyOne>
(06)
<wsp:All>
(07)
(08)
<sp:AsymmetricBinding>
(09)
<wsp:Policy>
(10)
<sp:InitiatorToken>
(11)
<wsp:Policy>
(12)
<sp:X509Token sp:IncludeToken="http://docs.oasisopen.org/ws-sx/ws-securitypolicy/200512/IncludeToken/AlwaysToRecipient">
(13)
<wsp:Policy>
(14)
<wsp:ExactlyOne>
(15)
<wsp:All>
(16)
<sp:WssX509V3Token11/>
(17)
</wsp:All>
(18)
<wsp:All>
(19)
<sp:WssX509PkiPathV1Token11/>
(20)
</wsp:All>
(21)
<wsp:All>
(22)
<sp:WssX509Pkcs7Token11/>
(23)
</wsp:All>
(24)
</wsp:ExactlyOne>
(25)
</wsp:Policy>
(26)
</sp:X509Token>
(27)
</wsp:Policy>
(28)
</sp:InitiatorToken>
(29)
<sp:RecipientToken>
(30)
<wsp:Policy>
(31)
<wsp:ExactlyOne>
(32)
<wsp:All>
(33)
<sp:X509Token sp:IncludeToken="http://docs.oasisopen.org/ws-sx/ws-securitypolicy/200512/IncludeToken/Never>
(34)
<wsse:SecurityTokenReference>
(35)
<wsse:Reference URI='#RecipientMessageIdentity'
ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509token-profile-1.0#X509v3"/>
(36)
</wsse:SecurityTokenReference>
(37)
<wsp:Policy>
(38)
<sp:WssX509V3Token11/>
(39)
</wsp:Policy>
(40)
</sp:X509Token>
(41)
</wsp:All>
(42)
<wsp:All>
(43)
<sp:X509Token sp:IncludeToken="http://docs.oasisopen.org/ws-sx/ws-securitypolicy/200512/IncludeToken/Never>
(44)
<wsse:SecurityTokenReference>
(45)
<wsse:Reference URI='#RecipientMessageIdentity'
ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509token-profile-1.0#X509PKIPathv1"/>
(46)
</wsse:SecurityTokenReference>
(47)
<wsp:Policy>
(48)
<sp:WssX509PkiPathV1Token11/>
(49)
</wsp:Policy>
(50)
</sp:X509Token>
(51)
</wsp:All>
(52)
<wsp:All>
(53)
<sp:X509Token sp:IncludeToken="http://docs.oasisopen.org/ws-sx/ws-securitypolicy/200512/IncludeToken/Never>
(54)
<wsse:SecurityTokenReference>
(55)
<wsse:Reference URI='#RecipientMessageIdentity'
ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509token-profile-1.0#PKCS7"/>
(56)
</wsse:SecurityTokenReference>
(57)
<wsp:Policy>
(58)
<sp:WssX509Pkcs7Token11/>
ogsa-wg@ogf.org
21
GWD-R (draft-ogf-ogsa-sp-secure-soap-009)
925
930
935
(59)
(60)
(61)
(62)
(63)
(64)
(65)
(66)
(67)
(68)
(69)
(70)
</wsp:Policy>
</sp:X509Token>
</wsp:All>
</wsp:Policy>
</sp:RecipientToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256/>
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:OnlySignEntireHeadersAndBody/>
<sp:ProtectTokens>
</wsp:Policy>
</sp:AsymmetricBinding>
(71)
940
945
950
955
960
965
(72)
(73)
(74)
(75)
(76)
(77)
(78)
(79)
(80)
(81)
(82)
(83)
(84)
(85)
(86)
(87)
(88)
(89)
(90)
(91)
(92)
(93)
(94)
(95)
(96)
(97)
(98)
(99)
(100)
October 15, 2007
<sp:Wss10>
<wsp:Policy>
<sp:MustSupportRefKeyIdentifier/>
</wsp:Policy>
</sp:Wss10>
<wsp:Policy wsu:Id=”RequestPolicy”>
<sp:SignedParts>
<sp:Body/>
<Header namespace="http://www.w3.org/2005/08/addressing"/>
</sp:SignedParts>
<sp:SignedElements>
<sp:XPath/>
/Envelope/Header/*[@isReferenceParameter="true"]'
</sp:XPath>
</sp:SignedElements>
</wsp:Policy>
<wsp:Policy wsu:Id=”ResponsePolicy”>
<sp:SignedParts>
<sp:Body/>
</sp:SignedParts>
</wsp:Policy>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
Below is a detailed non-normative description for the MUTUAL_X509 policy document:
o
Lines 02-100: An encapsulating POLICY_ASSERTION comprised of several child
POLICY_ASSERTIONs that serve to establish a message-level binding policy
indicating a mutual authentication with X.509v3 certificates.
o
Lines 08-72: A <sp:AsymmetricBinding> assertion which indicates that the
SENDER’s token must be used for the message signature and the RECIPIENT’s
token may be used for message encryption.
o
Lines 10-28: The Initiator token assertion describes the token required of the
SENDER by the RECIPIENT. Line 23 indicates that this SENDER-token is to be
included in each message from the SENDER to the RECIPIENT. Lines 13-25
indicate the SENDER’s token can be one of the following:
970
975
980
o
o
An X.509 v3 certificate capable of signature-verification at a minimum
o
An ordered list of X.509 certificates packaged in a PKIPath
o
A list of X.509 certificates and (optionally) CRLs packaged in a PKCS#7
wrapper
Lines 29-63: The Recipient token assertion describes a token identifying the
RECIPIENT to be used during communication. The RECIPIENT-token will be
ogsa-wg@ogf.org
22
GWD-R (draft-ogf-ogsa-sp-secure-soap-009)
985
October 15, 2007
embedded elsewhere within the SECURE_ENDPOINT_REFERENCE and may take
one of three forms:
o
An X.509 v3 certificate capable of signature-verification at a minimum
o
An ordered list of X.509 certificates packaged in a PKIPath
o
A list of X.509 certificates and (optionally) CRLs packaged in a PKCS#7
wrapper
990
This token will not be included in any request message. Instead, according to the
<sp:MustSupportKeyRefIdentifier> assertion on line 76, a KeyIdentifier must
be used to identify the token in any messages where it is used (e.g., for encryption).
o
Lines 64-68: Indicate that the Basic256 algorithm suite (as defined in WSSecurityPolicy Section 6.1) must be used for cryptographic activities.
o
Line 69: The <sp:OnlySignEntireHeadersAndBody> element indicates that any
signing performed must be done on entire message bodies and message headers
(as opposed to selective child elements).
o
Line 70: The <sp:ProtectTokens> element requires token protection which
dictates that the signature must cover the X.509 certificate token used to generate
that signature. (This enables authentication of the message origin.)
o
Lines 80-90: Contains a policy that is attached to request messages to the
RECIPIENT. Lines 82-83 specify that the message body and any WS-Addressing
headers must be signed. Line 87 specifies that any WS-Addressing reference
parameter headers (as identified by the IsReferenceParameter attribute) must be
signed.
o
Lines 92-96: Contains a policy that is attached to response messages from the
RECIPIENT. The message body must be signed.
995
1000
1005
1010
As specified in Section 4 of WS-SecurityPolicy, multiple message protection assertions (e.g.,
<sp:SignedParts>, <sp:EncryptedParts>, etc.) contained within a policy composition are
equivalent to a single message protection assertion of the same action containing the union of all
specified message parts. As an example of specifying additional signature/encryption
requirements, Section 5.3 illustrates a SECURE_EPR that augments the MUTUAL_X509 policy
to include message-level encryption of both request and response messages.
1015
ogsa-wg@ogf.org
23
GWD-R (draft-ogf-ogsa-sp-secure-soap-009)
October 15, 2007
APPENDIX C. REFERENCED SPECIFICATION STATUS AND ADOPTION
LEVEL CLASSIFICATION
The classification of this Profile’s referenced specifications at the time of writing is shown below:
Table 3 Status of specifications referenced by OGSA Security Profile 2.0 – Secure SOAP
Messaging
Referenced Specifications / Profiles: OGSA Security Profile 2.0 – Secure SOAP Messaging
Specifications
Web Services Addressing 1.0 - Core
WS-Policy 1.5 - Framework
WS-Policy 1.5 - Attachment
WS-SecurityPolicy 1.2
WS-S SOAP Message Security 1.1
WS-S X.509 Certificate Token Profile 1.1
XML Signature Syntax and Processing
WS-S UsernameToken Profile 1.1
XML Encryption Syntax and Processing
X
Unimplemented
Implemented
Interoperable
Community
Adopted
Ubiquitous
Draft
Evolving Consortium
Adoption
Consortium
Draft Institutional
Evolving Institutional
Specification/Profile Name
Institutional
Status
De Facto
1020
X
X
X
Note
W3C Recommendation
W3C Proposed Recommendation
W3C Proposed Recommendation
OASIS Standard
OASIS Standard
OASIS Standard
W3C Recommendation
OASIS Standard
OASIS Standard
<
<
<
X
X
X
X
X
X
X
X
X
X
X
Profiles
WS-I Basic Profile Version 1.1
X
–
–
–
–
–
–
Final Material
WS-I Basic Security Profile Version 1.0
X
–
–
–
–
–
–
Final Material
Legend:
ogsa-wg@ogf.org
X
<
–
Specification or profile is currently at this status or adoption level
Specification or profile is approaching this status or adoption level
Status or adoption level is not applicable
24