Ws-policy pdf

What is the Importance of Policies in the Workplace? What is the Difference Between Policies and Procedures? Sick Leave Policy eli. Paid Time Off Policy nonprofnetwork. Customer Service Policy mcdonalds. Insurance Policy rbcinsurance. A policy is a set of principles that are used by organizations or government bodies to guide decisions, especially in politics, economics, or business.

Follow us:. Share this page:. Download BibTex. A value of 'false' indicates that the wst:IssuedTokens header is not supported. This boolean property specifies whether a wst:RequestSecurityTokenCollection element is present.

The Trust13 assertion allows you to specify which WS-Trust 1. This identifies a Trust13 assertion. This indicates a policy that controls WS-Trust 1. This optional element is a policy assertion indicates that the [Client Challenge] property is set to 'true'.

This optional element is a policy assertion indicates that the [Server Challenge] property is set to 'true'. This optional element is a policy assertion indicates that the [Client Entropy] property is set to 'true'. This optional element is a policy assertion indicates that the [Server Entropy] property is set to 'true'. This optional element is a policy assertion indicates that the [Issued Tokens] property is set to 'true'.

This optional element is a policy assertion that indicates that the [Collection] property is set to 'true'. This optional element is a policy assertion that indicates that the STS requires the requestor to specify the scope for the issued token using wsp:AppliesTo in the RST.

This non-normative appendix provides guidance for designers of new assertions intended for use with this specification. Matching does not take into account attributes that are present on the assertion element. Nor does it take into account child elements except for wsp:Policy elements. If a wsp:Policy element is present, then matching occurs against the assertions nested inside that wsp:Policy element recursively see Policy Assertion Nesting [ WS-Policy ].

When designing new assertions for use with WS-SP, the above matching behaviour needs to be taken into account. For example, given two possible assertion designs;. A good example of design 1 is the token assertions defined in Section 5. The section defines 10 distinct token assertions, rather than a single sp:Token assertion with, for example, a TokenType attribute. These distinct token assertions make policy matching much more useful as less false positives are generated when performing policy matching.

There are cases where using attributes or child elements as parameters in assertion design is reasonable. Examples include cases when implementations are expected to understand all the values for a given parameter and when encoding the parameter information into the assertion QName would result in an unmanageable number of assertions.

A good example is the sp:IncludeToken attribute that appears on the various token assertions. Five possible values are currently specified for the sp:IncludeToken attribute and implementations are expected to understand the meaning of all 5 values. If this information was encoded into the assertion QNames, each existing token assertion would require five variants, one for each Uri value which would result in 45 assertions just for the tokens defined in Section 5.

Nested policy is ideal for encoding parameters that can be usefully matched using policy matching. For example, the token version assertions defined in Section 5 use such an approach. The overall token type assertion is parameterized by the nested token version assertions. Policy matching can use these parameters to find matches between policies where the broad token type is support by both parties but they might not support the same specific versions.

It is strongly recommended that policies and assertions be signed to prevent tampering. It is recommended that policies should not be accepted unless they are signed and have an associated security token to specify the signer has proper claims for the given policy. That is, a party shouldn't rely on a policy unless the policy is signed and presented with sufficient claims. It is further recommended that the entire policy exchange mechanism be protected to prevent man-in-the-middle downgrade attacks.

It is recommended that policies not specify two or more SignedSupportingTokens or SignedEndorsingSupportingTokens of the same token type. Messages conforming to such policies are subject to modification which may be undetectable.

It is recommended that policies specify the OnlySignEntireHeadersAndBody assertion along with the rest of the policy in order to combat certain XML substitution attacks.

Assertions and WS-PolicyAttachment. This non-normative appendix classifies assertions according to their suggested scope in WSDL 1. See Figure 1 in Section 4. TransportBinding Assertion Section 7. SymmetricBinding Assertion Section 7.

AsymmetricBinding Assertion Section 7. SupportingTokens Assertion Section 8. SignedSupportingTokens Assertion Section 8. EndorsingSupportingTokens Assertion Section 8. Wss10 Assertion Section 9. Wss11 Assertion Section 9. Trust13 Assertion Section SignedParts Assertion Section 4. SignedElements Assertion Section 4. EncryptedParts Assertion Section 4. EncryptedElements Assertion Section 4. ContentEncryptedElements Assertion Section 4. RequiredElements Assertion Section 4.

RequiredParts Assertion Section 4. The assertions listed in this section do not have a defined policy subject because they appear nested inside some other assertion which does have a defined policy subject.

This list is derived from nested assertions in the specification that have independent sections. It is not a complete list of nested assertions.

Many of the assertions previously listed in this appendix as well as the ones below have additional nested assertions. AlgorithmSuite Assertion Section 7. Layout Assertion Section 7. UsernameToken Assertion Section 5. IssuedToken Assertion Section 5. XToken Assertion Section 5. KerberosToken Assertion Section 5. SpnegoContextToken Assertion Section 5. SecurityContextToken Assertion Section 5. SecureConversationToken Assertion Section 5. SamlToken Assertion Section 5.

RelToken Assertion Section 5. HttpsToken Assertion Section 5. Issued Token Policy. The section provides further detail about behavior associated with the IssuedToken assertion in section 5. The issued token security model involves a three-party setup. Policy may be embedded inside an Issued Token assertion, or acquired out-of-band.

There may be an explicit trust relationship between the Server and the STS. There must be a trust relationship between the Client and the STS. The Issued Token policy assertion includes two parts: 1 client-specific parameters that must be understood and processed by the client and 2 STS specific parameters which are to be processed by the STS.

The format of the Issued Token policy assertion is illustrated in the figure below. The client-specific parameters of the Issued Token policy assertion along with the remainder of the server policy are consumed by the client.

The Client may augment or replace the contents of the RST made to the STS based on the Client-specific parameters received from the Issued Token policy assertion contained in the Server policy, from policy it received for the STS, or any other local parameters.

The assertion contains one element which contains a list of arbitrary elements which should be sent along to the STS by copying the elements as-is directly into the wst:SecondaryParameters of the RST request sent by the Client to the STS following the protocol defined in WS-Trust.

All items are optional, since the Server and STS may already have a pre-arranged relationship which specifies some or all of the conditions and constraints for issued tokens. Strict Security Header Layout Examples. The following example shows a policy indicating a Transport Binding, an Https Token as the Transport Token, an algorithm suite, a requirement to include tokens in the supporting signatures, a username token attached to the message, and finally an X token attached to the message and endorsing the message signature.

No message protection requirements are described since the transport covers all message parts. This policy is used as the basis for the examples shown in the subsequent section describing the security header layout for this binding.

Messages sent from initiator to recipient have the following layout for the security header:. A wsu:Timestamp element. Any tokens contained in the [Signed Supporting Tokens] property. Any tokens contained in the [Signed Endorsing Supporting Tokens] property each followed by the corresponding signature. If [Derived Keys] is 'true' and the supporting token is associated with a symmetric key, then a Derived Key Token, based on the supporting token, appears between the supporting token and the signature.

Any signatures for tokens contained in the [Endorsing Supporting Tokens] property. If [Derived Keys] is 'true' and the supporting token is associated with a symmetric key, then a Derived Key Token, based on the supporting token, appears before the signature. The following diagram illustrates the security header layout for the initiator to recipient message:. The outer box shows that the entire message is protected signed and encrypted by the transport. The arrows on the left from the box labeled Sig 2 indicate the parts signed by the supporting token labeled ST 2 , namely the message timestamp labeled TS and the token used as the basis for the signature labeled ST 2.

The dotted arrow indicates the token that was used as the basis for the signature. In general, the ordering of the items in the security header follows the most optimal layout for a receiver to process its contents. Initiator to recipient message. Messages sent from recipient to initiator have the following layout for the security header:.

If the [Signature Confirmation] property has a value of 'true', then a wsseSignatureConfirmation element for each signature in the corresponding message sent from initiator to recipient. If there are no signatures in the corresponding message from the initiator to the recipient, then a wsseSignatureConfirmation element with no Value attribute. The following diagram illustrates the security header layout for the recipient to initiator message:. One wsseSignatureConfirmation element labeled SC 1 corresponding to the signature in the initial message illustrated previously is included.

Recipient to initiator message. The following example shows a policy indicating a Symmetric Binding, a symmetric key based IssuedToken provided as the Protection Token, an algorithm suite, a requirement to encrypt the message parts before signing, a requirement to encrypt the message signature, a requirement to include tokens in the message signature and the supporting signatures, a username token attached to the message, and finally an X token attached to the message and endorsing the message signature.

Minimum message protection requirements are described as well. A wsu:Timestamp element if [Timestamp] is 'true'. If the sp:IncludeToken attribute on the [Encryption Token] is This Derived Key Token is used for encryption. A reference list including references to encrypted items. This Derived Key Token is used for signature. A signature over the wsu:Timestamp from 1 above, any tokens from 5 above regardless of whether they are included in the message, and any message parts specified in SignedParts assertions in the policy.

Signatures covering the main signature from 8 above for any tokens from the [Endorsing Supporting Tokens] and [Signed Endorsing Supporting Tokens] properties.

If [Derived Keys] is 'true' and the endorsing token is associated with a symmetric key, then a Derived Key Token, based on the endorsing token, appears before the signature. If [Protection Order] is 'EncryptBeforeSigning', then a reference list referencing all the message parts specified in EncryptedParts assertions in the policy. The arrows on the right indicate parts that were signed as part of the message signature labeled Sig 1.

The dashed arrows on the left from the box labeled Sig 2 indicate the parts signed by the supporting token labeled ST 2 , namely the message signature labeled Sig 1 and the token used as the basis for the signature labeled ST 2. The arrows on the left from boxes labeled Ref 1 indicate references to parts encrypted using a key based on the Shared Secret Token labeled ST 1.

The dotted arrows inside the box labeled Security indicate the token that was used as the basis for each cryptographic operation.

Initiator to recipient message using EncryptBeforeSigning:. Messages send from recipient to initiator have the following layout for the security header:. If [Signature Protection] is 'true', then the reference list MUST include a reference to the message signature from 6 below, and the wsseSignatureConfirmation elements from 5 below if any.

If [Signature Confirmation] is 'true' then a wsseSignatureConfirmation element for each signature in the corresponding message sent from initiator to recipient. A signature over the wsu:Timestamp from 1 above, any wsseSignatureConfirmation elements from 5 above, and all the message parts specified in SignedParts assertions in the policy. If [Protection Order] is 'EncryptBeforeSigning' then a reference list referencing all the message parts specified in EncryptedParts assertions in the policy.

The arrows on the left from boxes labeled Ref 1 indicate references to parts encrypted using a key based on the [SharedSecret Token] not shown in these diagrams as it is referenced as an external token.

Two wsseSignatureConfirmation elements labeled SC 1 and SC 2 corresponding to the two signatures in the initial message illustrated previously is included. The rules used to determine this ordering are described in Appendix C. Recipient to initiator message using EncryptBeforeSigning:. The following example shows a policy indicating an Asymmetric Binding, an X token as the [Initiator Token], an X token as the [Recipient Token] , an algorithm suite, a requirement to encrypt the message parts before signing, a requirement to encrypt the message signature, a requirement to include tokens in the message signature and the supporting signatures, a requirement to include wsseSignatureConfirmation elements, a username token attached to the message, and finally an X token attached to the message and endorsing the message signature.

Messages sent from initiator to recipient have the following layout:. If a [Recipient Token] is specified, and the associated sp:IncludeToken attribute is If [Signature Protection] is 'true' then the reference list MUST contain a reference to the message signature from 6 below. It is an error if [Signature Protection] is 'true' and there is not a message signature. Any tokens from the supporting tokens properties as defined in section 8 whose sp:IncludeToken attribute is If an [Initiator Token] is specified, and the associated sp:IncludeToken attribute is A signature based on the key in the [Initiator Token] if specified, over the wsu:Timestamp from 1 above, any tokens from 4 above regardless of whether they are included in the message, and any message parts specified in SignedParts assertions in the policy.

If [Token Protection] is 'true', the signature MUST also cover the supporting token regardless of whether it is included in the message. If a [Recipient Token] is specified and [Protection Order] is 'EncryptBeforeSigning' then if [Signature Protection] is 'false' then an xenc:EncryptedKey element, containing a key encrypted for the recipient and a reference list, else if [Signature Protection] is 'true', a reference list.

The reference list includes a reference to all the message parts specified in EncryptedParts assertions in the policy. The following diagram illustrates the security header layout for the initiator to recipient messages:. The arrows on the right indicate parts that were signed as part of the message signature labeled Sig 2 using the [Initiator Token] labeled ST 2. The dashed arrows on the left from the box labeled Sig 3 indicate the parts signed by the supporting token ST 3 , namely the message signature Sig 2 and the token used as the basis for the signature labeled ST 3.

The arrows on the left from boxes labeled EK 1 indicate references to parts encrypted using a key encrypted for the [Recipient Token] labeled ST 1. The arrows on the left from boxes labeled Ref 1 indicate additional references to parts encrypted using the key contained in the encrypted key labeled EK 1. The dotted arrows inside the box labeled Security indicate the token used as the basis for each cryptographic operation. Note: In most typical scenarios, the recipient key is not included in the message, but rather the encrypted key contains an external reference to the token containing the encryption key.

The diagram illustrates how one might attach a security token related to the encrypted key for completeness. One possible use-case for this approach might be a stack which does not support the STR Dereferencing Transform, but wishes to include the encryption token in the message signature.

Initiator to recipient message Example. Messages sent from recipient to initiator have the following layout:. If an [Initiator Token] is specified and [Protection Order] is 'SignBeforeEncrypting' or [SignatureProtection] is 'true' then an xenc:EncryptedKey element, containing a key encrypted for the initiator.

If [Signature Protection] is 'true' then the reference list MUST also contain a reference to the message signature from 6 below, if any and references to the wsseSignatureConfirmation elements from 4 below, if any. If [Signature Confirmation] is 'true', then a wsseSignatureConfirmation element for each signature in the corresponding message sent from initiator to recipient.

If a [Recipient Token] is specified, then a signature based on the key in the [Recipient Token], over the wsu:Timestamp from 1 above, the wsseSignatureConfirmation elements from 4 above, and any message parts specified in SignedParts assertions in the policy.

If an [Initiator Token] is specified and [Protection Order] is 'EncryptBeforeSigning' then if [Signature Protection] is 'false' then an xenc:EncryptedKey element, containing a key encrypted for the recipient and a reference list, else if [Signature Protection] is 'true', a reference list. The following diagram illustrates the security header layout for the recipient to initiator messages:. The arrows on the right indicate parts that were signed as part of the message signature labeled Sig 2 using the [Recipient Token] labeled ST 2.

Recipient to initiator message Example:. Signed and Encrypted Elements in the Security Header. It assumes that there are no sp:SignedElements and no sp:EncryptedElements assertions in the policy. The wsu:Timestamp element Section 6. All wsseSignatureConfirmation elements Section 9. The ds:Signature element that forms the message signature Section 8. The wsu:Timestamp element in the case of a transport binding Section 8.

The ds:Signature element that forms the message signature when [Signature Protection] has a value of 'true' Section 6. All wsseSignatureConfirmation elements when [Signature Protection] has a value of 'true' Section 6. A wsse:UsernameToken may be encrypted when a transport binding is not being used Section 5. The following individuals have participated in the creation of this specification and are gratefully acknowledged:. Original Authors of the intial contribution:.

Giovanni Della-Libera , Microsoft. Phillip Hallam-Baker, VeriSign. Hans Granqvist, Verisign. Chris Kaler , Microsoft editor. Maryann Hondo, IBM.

Hiroshi Maruyama, IBM. Anthony Nadalin, IBM editor. Nataraj Nagaratnam, IBM. Hemma Prafullchandra, VeriSign. John Shewchuk , Microsoft. Doug Walter , Microsoft. Original Acknowledgements of the initial contribution:. Vaithialingam B. Balayoghan, Microsoft. Francisco Curbera, IBM. Christopher Ferris, IBM.

Andy Gordon, Microsoft. Tomasz Janczuk, Microsoft. David Melgar, IBM. Mike Perks, IBM. Bruce Rich, IBM. Jeffrey Schlimmer, Microsoft. Chris Sharp, IBM. Kent Tamura, IBM. Vishwanath, Microsoft. Elliot Waingold, Microsoft. TC Members during the development of this specification:. Don Adams, Tibco Software Inc. Jan Alexander, Microsoft Corporation. Howard Bae, Oracle Corporation. Abbie Barbir, Nortel Networks Limited. Charlton Barreto, Adobe Systems. Toufic Boubez, Layer 7 Technologies Inc.

Norman Brickman, Mitre Corporation. Melissa Brumfield, Booz Allen Hamilton. Lloyd Burch, Novell. Scott Cantor, Internet2. Greg Carpenter , Microsoft Corporation.

Steve Carter, Novell. Ching-Yun C. Chao, IBM. Martin Chapman, Oracle Corporation. Kate Cherry, Lockheed Martin. Luc Clement, Systinet Corp. Paul Cotton , Microsoft Corporation.

Glen Daniels, Sonic Software Corp. Peter Davis, Neustar, Inc. Werner Dittmann, Siemens AG. Petr Dvorak, Systinet Corp. Colleen Evans , Microsoft Corporation. Ruchith Fernando, WSO2. Mark Fussell , Microsoft Corporation.

Vijay Gajjala , Microsoft Corporation. Marc Goodner, Microsoft Corporation. Martin Gudgin , Microsoft Corporation. Jiandong Guo, Sun Microsystems. Patrick Harding, Ping Identity Corporation. Heather Hinton, IBM. Frederick Hirsch, Nokia Corporation. Jeff Hodges, Neustar, Inc. 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.

Christopher Kurt, Microsoft Corporation. Rich Levinson, Oracle Corporation. Tommy Lindberg, Dajeil Ltd. Mark Little, JBoss Inc. Mike Lyons, Layer 7 Technologies Inc. Eve Maler, Sun Microsystems. Ashok Malhotra, Oracle Corporation. Jonathan Marsh , Microsoft Corporation. Robin Martherus, Oracle Corporation.

Miko Matsumura, Infravio, Inc. Jeff Mischkinsky, Oracle Corporation. Prateek Mishra, Oracle Corporation. Bob Morgan, Internet2. Vamsi Motukuru, Oracle Corporation. Raajmohan Na, EDS. Andrew Nash, Reactivity, Inc. Duane Nickull, Adobe Systems. Toshihiro Nishimura, Fujitsu Limited.

Darren Platt, Ping Identity Corporation. Prakash Reddy, CA. Alain Regnier, Ricoh Company, Ltd. Irving Reid, Hewlett-Packard. Tom Rutt, Fujitsu Limited. Maneesh Sahu, Actional Corporation. Frank Siebenlist, Argonne National Laboratory. Joe Smith, Apani Networks. Davanum Srinivas, WSO2. Yakov Sverdlov, CA. Gene Thurston, AmberPoint. Victor Valle, IBM.

Asir Vedamuthu , Microsoft Corporation. Greg Whitehead, Hewlett-Packard. Ron Williams, IBM. Kyle Young, Microsoft Corporation.