Transformation of policy and binding assertions for WSDL

WAS v8.5 > Secure applications > Secure web services > Define and managing secure policy set bindings
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 WebSphere Application Server 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 Metadata Exchange (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 the Application Server run time can process them. This transformation provides interoperability between Application Server and other systems that support the WS-SecurityPolicy version 1.2 standard.

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 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 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 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

v1.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 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>
WAS v8.5-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

Reference:

WS-Security authentication and protection for general bindings

+
Search Tips | Advanced Search