WS-SecurityPolicy Examples Version 1.0
Committee Specification 02
4 November 2010
Specification URIs:
This Version:
http://docs.oasis-open.org/ws-sx/security-policy/examples/ws-sp-usecases-examples-cs-02.doc (Authoritative)
http://docs.oasis-open.org/ws-sx/security-policy/examples/ws-sp-usecases-examples-cs-02.pdf
http://docs.oasis-open.org/ws-sx/security-policy/examples/ws-sp-usecases-examples-cs-02.html
Previous Version:
http://docs.oasis-open.org/ws-sx/security-policy/examples/ws-sp-usecases-examples-cd-04.doc (Authoritative)
http://docs.oasis-open.org/ws-sx/security-policy/examples/ws-sp-usecases-examples-cd-04.pdf
http://docs.oasis-open.org/ws-sx/security-policy/examples/ws-sp-usecases-examples-cd-04.html
Latest Version:
http://docs.oasis-open.org/ws-sx/security-policy/examples/ws-sp-usecases-examples.doc
http://docs.oasis-open.org/ws-sx/security-policy/examples/ws-sp-usecases-examples.pdf
http://docs.oasis-open.org/ws-sx/security-policy/examples/ws-sp-usecases-examples.html
Technical Committee:
OASIS Web Services Secure Exchange TC
Chair(s):
Kelvin Lawrence, IBM
Chris Kaler, Microsoft
Editor(s):
Rich Levinson, Oracle Corporation
Tony Gullotta, SOA Software Inc.
Symon Chang, Oracle Corporation.
Martin Raepple, SAP AG
Related work:
N/A
Declared XML Namespace(s):
N/A
Abstract:
This document contains examples of how to set up WS-SecurityPolicy [WSSP] policies for a variety of common token types that are described in WS-Security 1.0 [WSS10] and WS-Security 1.1 [WSS11] token profiles [WSSTC]. Particular attention is focused on the different “security bindings” (defined in [WSSP]) within the example policies. Actual messages that have been documented in WS-Security TC [WSSTC]and other WS-Security-based Interops [WSSINTEROPS, WSSXINTEROPS, OTHERINTEROPS] that conform to some of the example policies are referenced when appropriate.
The purpose of this document is to give examples of how policies may be defined for several existing use cases that have been part of the WS-Security Interops that have been conducted (see References section for Interop documents [INTEROPS]). In addition, some example use cases have been included which show some variations from the WS-Security Interop use cases in order to demonstrate how different options and security bindings impact the structure of the policies.
Status:
This document was last revised or approved by the WS-SX TC on the above date. The level of approval is also listed above. Check the “Latest Version” or “Latest Approved Version” location noted above for possible later revisions of this document.
Technical Committee members should send comments on this specification to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the “Send A Comment” button on the Technical Committee’s web page at http://www.oasis-open.org/committees/ws-sx/.
For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page (http://www.oasis-open.org/committees/ws-sx/ipr.php.
Notices
Copyright © OASIS® 1993–2010. All Rights Reserved.
All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.
OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.
OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.
The names "OASIS", here] are trademarks of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see http://www.oasis-open.org/who/trademark.php for above guidance.
Table of Contents
1 Introduction 6
1.1 Terminology and Concepts 6
1.1.1 Actors 7
1.1.2 Concepts 9
1.1.2.1 X509 Certificates 10
1.2 Terminology 11
1.3 Normative References 11
1.4 Non-Normative References 12
1.5 Specifications 13
1.6 Interops and Sample Messages 13
2 Scenarios 14
2.1 UsernameToken 14
2.1.1 UsernameToken – no security binding 14
2.1.1.1 UsernameToken with plain text password 14
2.1.1.2 UsernameToken without password 15
2.1.1.3 UsernameToken with timestamp, nonce and password hash 16
2.1.2 Use of SSL Transport Binding 17
2.1.2.1 UsernameToken as supporting token 17
2.1.3 (WSS 1.0) UsernameToken with Mutual X.509v3 Authentication, Sign, Encrypt 19
2.1.3.1 (WSS 1.0) Encrypted UsernameToken with X.509v3 22
2.1.4 (WSS 1.1), User Name with Certificates, Sign, Encrypt 25
2.2 X.509 Token Authentication Scenario Assertions 29
2.2.1 (WSS1.0) X.509 Certificates, Sign, Encrypt 29
2.2.2 (WSS1.0) Mutual Authentication with X.509 Certificates, Sign, Encrypt 32
2.2.2.1 (WSS1.0) Mutual Authentication, X.509 Certificates, Symmetric Encryption 35
2.2.3 (WSS1.1) Anonymous with X.509 Certificate, Sign, Encrypt 39
2.2.4 (WSS1.1) Mutual Authentication with X.509 Certificates, Sign, Encrypt 42
2.3 SAML Token Authentication Scenario Assertions 48
2.3.1 WSS 1.0 SAML Token Scenarios 49
2.3.1.1 (WSS1.0) SAML1.1 Assertion (Bearer) 49
2.3.1.2 (WSS1.0) SAML1.1 Assertion (Sender Vouches) over SSL 51
2.3.1.3 (WSS1.0) SAML1.1 Assertion (HK) over SSL 53
2.3.1.4 (WSS1.0) SAML1.1 Sender Vouches with X.509 Certificates, Sign, Optional Encrypt 54
2.3.1.5 (WSS1.0) SAML1.1 Holder of Key, Sign, Optional Encrypt 60
2.3.2 WSS 1.1 SAML Token Scenarios 65
2.3.2.1 (WSS1.1) SAML 2.0 Bearer 65
2.3.2.2 (WSS1.1) SAML2.0 Sender Vouches over SSL 69
2.3.2.3 (WSS1.1) SAML2.0 HoK over SSL 71
2.3.2.4 (WSS1.1) SAML1.1/2.0 Sender Vouches with X.509 Certificate, Sign, Encrypt 75
2.3.2.5 (WSS1.1) SAML1.1/2.0 Holder of Key, Sign, Encrypt 80
2.4 Secure Conversation Scenarios 105
2.4.1 (WSS 1.0) Secure Conversation bootstrapped by Mutual Authentication with X.509 Certificates 105
3 Conformance 114
A. Acknowledgements 115
B. Revision History 118
ws-sp-usecases-examples-cs-02 4 November 2010
Copyright © OASIS® 1993–2010. All Rights Reserved. Page 1 of 118
1 Introduction
This document describes several WS-SecurityPolicy [WS-SECURITYPOLICY] examples. An example typically consists of the security aspects of a high-level Web Service use-case with several variable components. Many of the examples are based on existing use cases that have been conducted during WS-Security Interops [WSS-INTEROPS]. In those examples a reference is included to identify the specific use case in the specific interop document that is being demonstrated.
In the policy examples below, the “wsp” prefix refers to the elements defined in the WS-Policy namespace:
xmlns:wsp=”http://www.w3.org/ns/ws-policy/”
the “sp” prefix refers to elements defined in the WS-SecurityPolicy (WS-SP) namespace:
xmlns:sp=“http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702”
the “t” prefix refers to elements defined in the WS-Trust namespace:
xmlns:t=” http://docs.oasis-open.org/ws-sx/ws-trust/200512”
Where uses cases are based on existing scenarios, those scenarios are referenced at the beginning of the use case section. The explicit documents describing the scenarios are identified by links in [Section3.2].
1.1 Terminology and Concepts
This section (1.1.*) describes the logical “actors” that participate in the examples. In addition, there is a discussion on general concepts that describes how the logical actors typically relate to the physical message exchanges that take place.
This section also provides a security reference model designed to provide context for the examples in terms of a conceptual framework within which the actors interact, which is intended to help readers understand the trust relationships implicit in the message exchanges shown in the examples.
In these examples there are always three important conceptual entities to recognize that exist on the initiating side of a transaction, where the transaction is being requested by sending an electronic message that contains the details of the what is being requested and by whom (the “entities” become “actors” as the discussion moves from the conceptual to the specific). These three entities are:
· 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.
1.1.1 Actors
The following diagram shows the actors and the relationships that may be typically involved in a network security scenario:
Figure 1.
The diagram is intended to show the possible interactions that may occur between actors in any given scenario, although, in general, depending on the policy specified by the recipient, only a subset of the possible interactions will actually occur in a given scenario. Note that the Issuing and Validating Authorities, may, in general be either a WS-Trust Security Token Service (STS) or other authority.
First, a brief narrative will describe the diagram, then the actors will be defined in more detail.
In a typical example interaction, a Requestor wants to issue a Web Service request to a Web Service that is hosted by the “Recipient” web site on behalf of a RelyingParty, who is actually the business entity responsible for making the service available and with whom any business arrangements with the Requestor are made. One may think of this as an end to end interaction between a Requestor and a RelyingParty, with technical resources being provided by the Initiator on the Requestor side and the Recipient on the RelyingParty side.
Technically, what occurs is that the Requestor hands the request to the Initiator, which in turn issues a query to the Recipient and is returned the WSDL [WSDL] describing the Web Service, which generally includes WS-SP policy Assertions [WS-POLICY, WS-POLICYATTACHMENT] that describe the security policies supported by the Recipient for this Web Service (Note: it is not necessary that the information in the Assertions be obtained this way. It may also be stored locally based on out of band agreements between the Requestor and RelyingParty). This interaction is shown by the upper pair of arrows between the Initiator and the Recipient.