WS-Security behavior differences between traditional and Liberty

The WS-Security constraints that can be added to a web service application in Liberty may behave differently from the same constraints applied to a service in traditional.


WS-Security enablement and configuration

WS-Security in Liberty is configured using the WS-SecurityPolicy within the WSDL file of a web service application, and is enabled by adding the wsSecurity-1.1 feature in server.xml. WS-Security in traditional is configured using a policyset and enabled by attaching a policyset. If we deploy a WS-Security enabled Liberty web service application to traditional, create and attach an equivalent policyset and bindings to get the same level of web service security.


WS-Security Policy

  • Namespaces

    • The Liberty CXF WS-Security supports the following WS-Security Policy namespaces: 

        http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200802

    • The following namespace is also supported, with limitations: 

        http://schemas.xmlsoap.org/ws/2005/07/securitypolicy

    • The WS-Security of traditional supports the following WS-Security Policy namespaces: 

        http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512

  • AssertionsLiberty supports more assertions in the WS-Security Policy 1.2 than traditional. Some policy assertions in traditional WS-Security are implemented through XPath or bindings. The following list shows some important differences:

    • Supporting Tokens

      To sign or encrypt a SupportingToken such as a UsernameToken in Liberty, you assert the token as SignedSupportingTokens, SignedEncryptedSupportingTokens, or EncryptedSupportingTokens. In traditional, we must use an XPath expression to sign or encrypt a SupportingToken.

      All endorsing tokens are not supported in traditional, including EndorsingSupportingTokens, SignedEndorsingSupportingTokens, EndorsingEncryptedSupportingTokens, and SignedEndorsingEncryptedSupportingTokens.

    • Security Binding Assertion

      Liberty supports the SymmetricBinding, AsymmetricBinding, and TransportBinding assertions. The traditional server does not support the TransportBinding assertion.

    • IncludeToken Assertion

      The IncludeToken assertion is enforced in Liberty, but is ignored in the WS-Security runtime environment of traditional.

    • UsernameToken Assertion

      Liberty supports PasswordDigest and key derivation in the UsernameToken assertion. WebSphere Application Server traditional supports only PasswordText in a UsernameToken.


Unrecognized elements in the Security headers

  • An unrecognized element in the Security header is rejected by traditional, while it is accepted by Liberty.


Encrypted header

  • The WS-Security 1.1 specification recommends using the <wsse11:EncryptedHeader> element for encrypting SOAP header blocks.

    • The CXF WS-Security used in Liberty does not generate an EncryptedHeader element. Instead, the CXF WS-Security generates an <xenc:EncryptedData> element. However, the CXF WS-Security used in Liberty can process and consume an incoming <wsse11:EncryptedHeader> element if mustUnderstand in the <security> header is set to 0.

    • WebSphere Application Server traditional always sets mustUnderstand to 1 in the <security> header. In order for Liberty to process the EncryptedHeaderelement successfully, we must explicitly set mustUnderstand to 0 by setting the following property in the outbound bindings configuration: 

        <properties name="com.ibm.wsspi.wssecurity.config.request.setMustUnderstand" value="false"/>


Intermediate non-trusted certificates

  • There is no way to specify intermediate non-trusted certificates to allow the certificate path validator to build a certificate path from an inbound certificate to a trusted certificate in a trust store. Either the inbound certificate or its immediate issuer must be in the trust store for the certificate to be trusted.


Known issues


Not tested and not supported features

  • Liberty WS-Security includes all of the WS-Security runtime environment code from the CXF project. However, not all functions and features in the CXF WS-Security were tested or verified. To see a list of the specifications that were not verified, see Untested WS-Security specifications.