WS-Security behavior differences between traditional and Liberty

WS-Security enablement and configuration

WS-Security in Liberty is configured by using the WS-SecurityPolicy within the WSDL file of a web service application, and is enabled by adding the wsSecurity-1.1 feature in the server.xml file. WS-Security in traditional is configured by using a policyset and enabled by attaching a policyset. If you deploy a WS-Security enabled Liberty web service application to traditional, you must 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

• Assertions
  Liberty 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, you 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 that is used in Liberty does not generate an EncryptedHeader element. Instead, the CXF WS-Security generates an <xenc:EncryptedData> element. However, the CXF WS-Security that is 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, you 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

• There are some known issues in Liberty CXF WS-Security. Some of the issues have work-arounds. To find known issues and work-arounds, see WS-Security known issues and work-arounds.

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.