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 the Liberty profile 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 profile client and a full profile provider
and receive a CWWSS6001E: Key object was not obtained. response
from the provider, the issue might be resolved by full profile APAR
PM88011. This issue specifically relates to configurations that include
both asymmetric digital signature and encryption of the Body.