WS-Security known issues and work-arounds
The following items are issues with the WS-Security implementation in the Apache CXF open source services framework.
- If your SupportingToken is being encrypted when you intended to encrypt nothing, try removing any encryption-related token assertions to resolve the issue. If there are no EncryptedParts and no EncryptedElements in an AsymmetricBinding with SupportingToken assertion, then the SupportingToken is encrypted unexpectedly.
- XML Signature with Enveloped Signature Transformation does not work. There is no work-around.
- Although the PolicyReference within <wsdl:output> is honored, the PolicyReference within <wsdl:input> is ignored. If you must distinguish PolicyReference between input and output, the work-around is to attach PolicyReference at the binding level and then override PolicyReference in <wsdl:output>.
- sp:requireEmbeddedTokenReference policy assertion is not supported.
- When the org.apache.ws.security.crypto.merlin.truststore.* properties exist in the signatureProperties element and the org.apache.ws.security.crypto.merlin.keystore.* properties exist in the encrytpionProperties element in the wsSecurityProvider or wsSecurityClient section of the server.xml file, the org.apache.ws.security.crypto.merlin.keystore.* values in the encrytpionProperties element overrides the org.apache.ws.security.crypto.merlin.truststore.* properties in the signatureProperties element. This behavior means that your encryption keystore is used for your signature trust store. The work-around is to use the same keystore for both encryption and signature trust store; separate keystores cannot be used.
- The X509PKIPathv1 and PKCS#7 token types are not supported.
- In the WS-Security policy, the Require* assertions within the X509Token assertion are only used when generating an X509 token. They are not enforced when consuming an X509 token. These assertions include, but are not limited to, RequireKeyIdentifierReference, RequireIssuerSerialReference, and RequireThumbprintReference.
- In the SymmetricBinding assertion, neither the SignatureToken nor the EncryptionToken assertions can be specified. The only supported assertion that can be used within a SymmetricBinding assertion is the ProtectionToken assertion. The ProtectionToken specified is used for both signature and encryption.
- The ProtectTokens assertion in the WS-Security policy is not supported and is ignored.
- The KeyValueToken assertion in the WS-Security policy is not supported.
- X509Token within EndorsingEncryptedSupportingTokens or SignedEndorsingEncryptedSupportingTokens is not supported.
- WS-Security in Liberty supports the version 1.1 specification, which is compatible with an
earlier version with the version 1.0 specification. This means that URIs and schema elements that
are defined in 1.0 remain unchanged, while new schema elements and constants are defined with 1.1
namespaces and URIs.
WS-Security options and properties in the WS-Security policy is defined with the wss10 assertion or the wss11 assertion. If you must configure a policy to support the WS-Security 1.1 properties, you must configure only the wss11 policy assertion that already includes the wss10 assertion, and you must not configure both the wss11 and the wss10 policy assertions.
Examples of wss11 policy assertions that contain the wss10 assertion include, but are not limited to, RequireSignatureConfirmation, MustSupportRefKeyIdentifier and MustSupportRefIssuerSerial.
- WS-Security and MTOM cannot be configured together for the same service at this time. When MTOM is used and WS-Security is also configured, the SOAP message is not sent properly. The user must make a choice to either use MTOM or configure WS-Security. If MTOM is required, you must remove the WS-Security policy from the WSDL file to disable WS-Security.
- If you are using a Liberty client and a WebSphere® Application Server traditional provider and receive a CWWSS6001E: Key object was not obtained. response from the provider, the issue might be resolved by WebSphere Application Server traditional APAR PM88011. This issue specifically relates to configurations that include both asymmetric digital signature and encryption of the Body.