Integration Server 10.11 | Web Services Developer’s Guide | Securing Web Services Using WS-SecurityPolicy | WS-SecurityPolicy Assertions Reference | Security Binding Assertions
 
Security Binding Assertions
Use security binding assertions to define the properties of the mechanisms used to secure message exchanges, such as the keys being used, algorithms, and layout. Integration Server supports all three security binding assertions: <sp:TransportBinding>, <sp:SymmetricBinding>, and <sp:AsymmetricBinding>.
You can use the following security binding properties to provide additional information to the security binding assertions:
*Algorithm Suite (<sp:AlgorithmSuite>), which specifies an algorithm suite that includes cryptographic algorithms for performing operations, such as signing and encryption. Integration Server support of WS-SecurityPolicy includes the following algorithm suites in the WS-SecurityPolicy 1.2 and WS-SecurityPolicy 1.1 standards:
*<sp:Basic256>
*<sp:Basic192>
*<sp:Basic128>
*<sp:TripleDes>
*<sp:Basic256Rsa15>
*<sp:Basic192Rsa15>
*<sp:Basic128Rsa15>
*<sp:TripleDesRsa15>
*<sp:Basic256Sha256>
*<sp:Basic192Sha256>
*<sp:Basic128Sha256>
*<sp:TripleDesSha256>
*<sp:Basic256Sha256Rsa15>
*<sp:Basic192Sha256Rsa15>
*<sp:Basic128Sha256Rsa15>
*<sp:TripleDesSha256Rsa15>
*Timestamp (<sp:IncludeTimestamp>), which specifies whether a Timestamp element must be included in the security header.
If this property is set to true, the timestamp element must be present and be integrity protected either by transport or message level security.
If this property is set to false, the timestamp element must not be present. The default value for this property is false.
*Protection order, which specifies the order of signature and encryption operations in case the content has to be signed as well as encrypted. You can set either of the following values for this property:
*<sp:EncryptBeforeSigning>: Performs the encryption operation before generating a signature for the message. Signature must be computed over cipher text. Encryption key and signing key must be derived from the same source key unless distinct keys are provided.
*<sp:SignBeforeEncrypting>: Generates a signature for the message before encrypting any portion of the message. Signature must be computed over plain text. The resulting signature should be encrypted and the supporting signatures must be over the plain text signature. This is the default value.
*Signature protection (<sp:EncryptSignature>), which specifies whether the signature must be encrypted.
If this property is set to true, the primary signature as well as any signature confirmation elements, if present, must be encrypted. If there are no signature confirmation elements, it is not required to encrypt the primary signature element.
If this property is set to false, the primary signature as well as any signature confirmation elements, if present, must not be encrypted. The default value for this property is false.
*Token protection (<sp:ProtectTokens>), which specifies whether the signature should cover the token that is used to generate that signature.
If this property is set to true, each signature digest over the SOAP body must be over the entire SOAP body element and each signature digest over a SOAP header must be over an actual header element and not a descendant of a header element.
If this property is set to false, the signature digests can be over a descendant of the SOAP body or header element. The default value for this property is false.
*Entire Header and Body Signatures (<sp:OnlySignEntireHeadersAndBody>), which specifies whether the signature digests over the SOAP body and SOAP headers should only cover the entire body and entire header elements.
If this property is set to true, each signature digest over the SOAP body must be over the entire SOAP body element and each signature digest over a SOAP header must be over an actual header element and not a descendant of a header element.
If this property is set to false, the signature digests can be over a descendant of the SOAP body or header element. The default value for this property is false.
*Security Header Layout (<sp:Layout>), which specifies the security header layout. Integration Server supports the <sp:Strict> optional element of the <sp:Layout> assertion.
Integration Server always generates the Security header following the Strict layout rules specified in the web Services Security 1.0 standards according to a general principle of “declare before use”. While processing an inbound message, Integration Server always follows the Lax layout rules with the security header layout.
Important:
If you are implementing WS-SecurityPolicy 1.2 standards, the sp prefix in the assertions described below represents this namespace: http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702. If you are implementing WS-SecurityPolicy 1.1 standards, the sp prefix represents this namespace: http://schemas.xmlsoap.org/ws/2005/07/securitypolicy.
The following table lists the WS-Security security binding assertions that Integration Server supports.
Security Binding Assertion
Add to a WS-Policy to...
<sp:TransportBinding>
Indicate that message protection and security correlation is provided using a secure transport.
Integration Server supports all the nested assertions of <sp:TransportBinding>.
<sp:SymmetricBinding>
Indicate that message protection is provided using asymmetric key (Public Key) technology, such as RSA. For a symmetric binding only one party generates the security tokens used for signing and encrypting. Although the same key pair can be used for both signing and encryption, it is common practice to use distinct keys for each because of their different life cycles.
Integration Server supports all the nested assertions of <sp:SymmetricBinding>.
<sp:AsymmetricBinding>
Indicate that message protection is provided using asymmetric key (Public Key) technology, such as RSA. For a asymmetric binding both parties generate the security tokens used for signing and encrypting. With asymmetric bindings:
*For signing, the initiator uses its private key. As a result, the recipient can use the initiator’s public key for verification.
*For encryption, the initiator uses the recipient’s public key. As a result, the recipient can decrypt using its private key.
Although the same key pair can be used for both signing and encryption, it is common practice to use distinct keys for each because of their different life cycles.
Integration Server supports all the nested assertions of <sp:AsymmetricBinding>.