Troubleshooting
Problem
Learning more about Web Services Security (WS-Security) is the first step in the troubleshooting process. This document provides you with educational information that can help you learn more about this topic.
Resolving The Problem
Topics:
Overview 
Note: This document uses the term full profile to refer to WebSphere Application Server v9.0 traditional, WebSphere Application Server v8.5 full profile, WebSphere Application Server v8.0 and earlier, WebSphere classic, traditional WebSphere, traditional WAS and tWAS.
This topic contains a list of common restrictions for the Web Services Security (WS-Security) runtime in the WebSphere® Application Server. The main focus is the JAX-WS runtime.
Note: This document uses the term full profile to refer to WebSphere Application Server v9.0 traditional, WebSphere Application Server v8.5 full profile, WebSphere Application Server v8.0 and earlier, WebSphere classic, traditional WebSphere, traditional WAS and tWAS.| Function not supported | Comments |
| Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO) tokens | Definition: http://en.wikipedia.org/wiki/SPNEGO The WebSphere WS-Security runtime does not support SPNEGO tokens. In WS-Security, the most common use is a Kerberos ticket wrapped in a SPNEGO token for interaction with a Microsoft® .NET provider. An alternative is to use pure Kerberos tokens: See Secure Web services between WebSphere Application Server and Microsoft Windows Communication Foundation |
| NT LAN Manager (NTLM) | Definition: http://en.wikipedia.org/wiki/NTLM This is a Microsoft Windows authentication mechanism that the WebSphere WS-Security runtime does not support. |
| EndorsingSupportingTokens | The EndorsingSupportingTokens will sometimes be found in a Microsoft .NET wsdl that defines a symmetric policy. Since the WebSphere WS-Security runtime in the full profile does not support EndorsingSupportingTokens, a WebSphere WS-Security policy/binding in the full profile cannot be created to interoperate with a .NET provider that has a wsdl that contains this directive. EndorsingSupportingTokens is supported in the CXF WS-Security runtime in Liberty. |
| X.509 Symmetric Encryption | The only types of symmetric encryption that the WebSphere WS-Security runtime supports are SAML Holder of Key and Kerberos. The following attribute of a SOAP message indicates that a message has been encrypted with X.509 symmetric: The EncryptedKey has a SecurityTokenReference/KeyIdentifier with a Thumbprint that identifies to decrypt the EncryptedKey. |
| EncryptedKeySHA1 | The http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#EncryptedKeySHA1 value type for the KeyIdentifier as a child of a SecurityTokenReference element is not supported. Although the EncryptedKeySHA1 value type is valid for a KeyIdentifier, the WebSphere JAX-WS runtime does not support the EncryptedKeySHA1 KeyIdentifier. In order to use an EncryptedKeySHA1 KeyIdentifier, the key must be cached by the receiver of the message. The WebSphere client does not cache the keys, so the response message cannot be decrypted when it is received. |
| Emitting the http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3 ValueType attribute on a KeyIdentifier element | The http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3 value type for the KeyIdentifier as a child of a SecurityTokenReference element is not supported. When a KeyIdentifier element has this ValueType attribute, it means that its value contains a Base64 encoded X.509 certificate. The WebSphere WS-Security runtime does not support the generation of this type of KeyIdentifier element. An X.509 certificate can only be emitted in a BinarySecurityToken element. That BinarySecurityToken element can be referenced with a SecurityTokenReference/Reference element or be a child of SecurityTokenReference/Embedded element. See the XML Signature tab for more information on the supported KeyInfo types. |
| The http://schemas.xmlsoap.org/ws/2002/07/secext WS-Security namespace | The http://schemas.xmlsoap.org/ws/2002/07/secext namespace is not supported by either the WebSphere JAX-RPC or JAX-WS runtimes. The following namespaces are supported by the WebSphere JAX-WS runtime: WSSE: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd WSSE11: http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd The WebSphere JAX-RPC runtime only supports the WSSE namespace. |
| Role-based authorization for a servlet based on a token in the Security header of the SOAP message | Although security roles for servlet and EJB implementations are configured the same way, access to the services differs by implementation. For a provider that is implemented as a servlet, the web container performs role-based authorization through HTTP basic authentication. When a web service provider is implemented as a servlet, unless custom token token consumer code is in place, a token that passes in the Security header of the SOAP request cannot be used for role-based authorization for access to the service. For a provider that is implemented as an EJB, the EJB container performs role-based authorization. When a web service provider is implemented as an EJB, a token that Web services security passes in the Security header of the SOAP request can only be used for role-based authorization by the EJB container for access to the service if there is a caller configuration for that token in the active Web services security constraints. See the Web Services Security authorization models topic in the Knowledge Center for more information. |
| Protection of SOAP faults | The WebSphere WS-Security runtime does not support either applying security constraints to outbound SOAP faults or evaluating the security constraints applied to inbound SOAP faults. Inbound SOAP faults must not have security constraints applied. |
| PasswordDigest | The JAX-RPC runtime does not support the UsernameToken Password with type http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest at all. In the full profile, after fixpacks 7.0.0.41, 8.0.0.12, and 8.5.5.8, a JAX-WS client can be configured to emit PasswordDigest with a custom property, but it only supports consuming #PasswordDigest with custom code. For more information see the Consuming a UsernameToken with PasswordDigest topic in the Knowledge Center. |
| Forward references to security tokens by Signature or EncryptedData | Any non-external security token that is referenced within a Signature or EncryptedData/EncryptedKey must appear in the message before the element that references it. Although the WS-Security spec uses SHOULD when referencing 'prepending existing elements', the WebSphere WS-Security runtime requires it. An error will occur if the runtime encounters forward dependencies for security tokens in a SOAP Security header. |
| Using anything but the Sha1 Signature Algorithms as default | The OASIS WS-SecurityPolicy 1.2 (open in new window or tab) specification, section 6.1 defines the Sha1 signature algorithms are a base for all the algorithm suites. If you want to use anything other than Sha1, you must override the signature algorithm defined for your algorithm suite with a custom property in the WS-Security bindings. More information on the custom properties can be found with APAR PM62842. New general bindings that include settings for the SHA256 signature algorithms for all the sign parts can be found on this technote. |
| Security tokens that appear in the SOAP message outside the Security header | All tokens that are referenced by an element in the Security header that appear in the message must reside within the Security header. If one or more do not, an error will occur. Also, any authentication token defined in the policy must appear in the Security header. It cannot be placed in a different header or in the Body of the SOAP message. |
| Evaluation of encrypted data that is not referenced in any way by the Security header | If a policy requires that a message be encrypted, there must be some way to find the encrypted data by evaluating the SOAP Security header. For instance, if the EncryptedData is self-contained, meaning that it contains both the KeyInfo/EncryptedKey and the CipherData for the element being encrypted and that EncryptedData does not reside inside the Security header, if the policy requires that element be encrypted, an error will occur. |
[{"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Component":"Web Services Security","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF010","label":"HP-UX"},{"code":"PF012","label":"IBM i"},{"code":"PF016","label":"Linux"},{"code":"PF027","label":"Solaris"},{"code":"PF033","label":"Windows"},{"code":"PF035","label":"z\/OS"}],"Version":"9.0;8.5.5;8.5;8.0;7.0","Edition":"Base;Network Deployment;Single Server","Line of Business":{"code":"LOB45","label":"Automation"}}]
Was this topic helpful?
Document Information
Modified date:
25 October 2019
UID
swg21972049