Transformation of policy and binding assertions for WSDL

The following WS-SecurityPolicy 1.2 assertions can be represented in the policy returned on WSDL, or a WS-MEX request.

EncryptSignature

Represented in the product using XPath expressions in the encrypted elements.

EncryptBeforeSigning

The order attribute of the encryptionInfo and signingInfo elements on the outbound section of the bindings determines the order in which the transform takes place, and whether this assertion is set. The default behavior is to sign before encrypting.

ContentEncryptedElements

Represented using XPath expressions ending with /node() in the encrypted elements. The Application Server can consume this policy assertion, but existing XPath expressions that end with /node() are not transformed.

KerberosToken

Represented using the custom token in the policy and bindings. The Kerberos custom token assertion specifies a local name of http://docs.oasis-open.org/wss/oasis-wss-kerberos-token-profile-1.1#GSS_Kerberosv5_AP_REQ, or http://docs.oasis-open.org/wss/oasis-wss-kerberos-token-profile-1.1#Kerberosv5_AP_REQ, depending on the desired Kerberos token type. Also, there is a custom property in the bindings, com.ibm.wsspi.wssecurity.krbtoken.requireDerivedKey, which specifies use of derived keys for Kerberos. Using the local name of the custom token, along with the derived key custom property from the product representation, an equivalent Version 1.2 representation can be created.

Require<variable>Reference, where <variable> is one of the following: KeyIdentifier, IssuerSerial, EmbeddedToken, or Thumbprint

Rrepresented using the type attribute on keyInfo in the bindings.

MustSupportRef<variable>, where <variable> is one of the following: KeyIdentifier, IssuerSerial, EmbeddedToken, or Thumbprint

This assertion is not represented in the WebSphere Application Server policies, but the product supports all four types of references.

Protection of the SignatureConfirmation element

The SignatureConfirmation element is implicitly signed and encrypted. However, if nothing is encrypted on the response, then the SignatureConfirmation element is not encrypted, and if nothing is signed on the response, then the SignatureConfirmation element is not signed. All XPath expressions representing the signing or encryption of the SignatureConfirmation element are removed from the policy during transformation. The explicitlyProtectSignatureConfirmation attribute in the Web Services Security binding is provided to disable implicit signature and encryption of the SignatureConfirmation element on the response message. This provides interoperability with WebSphere Application Server Version 6.1.x. To add the attribute, check the option Disable implicit protection for Signature Confirmation in the Authentication and protection panel for the default policy set bindings. If the explicitlyProtectSignatureConfirmation attribute is present in the binding, all XPath expressions representing the signing or encryption of the SignatureConfirmation element remain unchanged during transformation.

SC13SecurityContextToken

Version 1.3 of the Security Context Token is supported by specifying the local name http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512, in the binding for the security context token.

RequireImpliedDerivedKeys

This is supported by adding the custom property, com.ibm.ws.wssecurity.token.generateImpliedDerivedKey, in the token generator bindings.

ExactlyOne

This assertion is transformed when callers are used. Callers specify which token to use for authentication. The ExactlyOne assertion communicates the caller tokens that the service expects. All caller options are enclosed inside the <ExactlyOne> assertion, and each option is enclosed inside the <wsp:All> assertion. As the name implies, the client sends only one of the token types. For example, in the server side bindings, using the product representation, the following caller options are specified:

 <caller order="1">
        <jAASConfig configName="system.wss.caller"/>
        <callerIdentity uri="" localName="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#UsernameToken"/>
 </caller>
 <caller order="2">
        <jAASConfig configName="system.wss.caller"/>
        <callerIdentity localName="LTPA" uri="http://www.ibm.com/websphere/appserver/tokentype/5.0.2" />
</caller>

This assertion indicates that a UsernameToken token or an LTPA token is used as the caller. The requirement to use one of these two types of tokens is communicated to the client in the transformed policy, as in the following example:

<sp:ExactlyOne>
<wsp:All> 
<sp:SupportingTokens>
   <wsp:Policy wsu:Id="request:token_auth">
     <sp:UsernameToken sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/IncludeToken/AlwaysToRecipient">
       <wsp:Policy>
         <sp:WssUsernameToken10 />
       </wsp:Policy>
     </sp:UsernameToken>
 </wsp:Policy>
</sp:SupportingTokens>
</wsp:All>
<wsp:All> 
<sp:SupportingTokens>
<wsp:Policy wsu:Id="request:token_auth">
     <spe:LTPAToken sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/IncludeToken/AlwaysToRecipient" />
</wsp:Policy>
 </sp:SupportingTokens>
<wsp:All>
</sp:ExactlyOne>