+

Search Tips   |   Advanced Search

Transformation of policy and binding assertions for WSDL


Web Services security does not fully support the OASIS WS-SecurityPolicy V1.2 standard. However, several of the policy and binding assertions supported by WAS can be transformed and represented as WS-SecurityPolicy V1.2 assertions. The supported assertions are transformed when a Web Services Description Language (WSDL) or Web Services MetadataExhange (WS-MEX) request is received in a message, and also when the client receives a policy containing WS-SecurityPolicy 1.2 assertions.

When the WAS receives a WSDL or WS-MEX request, some policy and binding assertions are transformed into standard assertions and included in the policy that is embedded into the WSDL. In addition, when the client receives a policy containing these WS-SecurityPolicy assertions, the assertions are transformed back into product-specific assertions so that the appserver run time can process them. This transformation provides interoperability between Application Server and other systems that support the WS-SecurityPolicy version 1.2 standard.

 

Example

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

EncryptSignature

Represented in WAS 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 WAS representation, an equivalent V1.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 WAS policies, but WAS 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 WS-Security binding is provided to disable implicit signature and encryption of the SignatureConfirmation element on the response message. This provides interoperability with WAS V6.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 WAS 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>

The product-specific policy assertions LTPAToken and LTPAPropagationToken are not altered during transformation. These assertions are included in the embedded policy in the WSDL if they are present in the policy being transformed. This allows a WAS client and WAS service provider to interoperate.


 

Related concepts


WSDL

 

Related tasks


Set policy set bindings

 

Related


WS-Security authentication and protection for general bindings