Download
Abstract
SAML token may fail signature validation after being propagated by WS-Security
Download Description
THIS FIX HAS BEEN SUPERSEDED BY THE FIX FOR PI56581.
This fix has been superseded by the fix for PI56581. To obtain a fix for PI56377, see http://www-01.ibm.com/support/docview.wss?uid=swg24042605.
PI56377 resolves the following problem:
ERROR DESCRIPTION:
When a JAX-WS provider application receives a signed SAML token in an inbound SOAP request, then propagates the token to a downstream service, the token may fail signature validation.
This behavior happens after installing fix packs 7.0.0.39, 7.0.0.41, 8.0.0.11, 8.0.0.12, 8.5.5.7, 8.5.5.8 or 8.5.5.9. This problem does not occur on fixpacks 7.0.0.0 through 7.0.0.37, 8.0.0.0 through 8.0.0.10 or 8.5.0.0 through 8.5.5.6.
LOCAL FIX:
Use one of types of SAML tokens that are not affected:
- Encrypted SAML tokens
- Unsigned SAML tokens
PROBLEM SUMMARY
USERS AFFECTED:
IBM WebSphere Application Server administrators of WS-Security enabled JAX-WS applications and SAML
RECOMMENDATION:
Install a fix pack or interim fix that contains this APAR.
PROBLEM DESCRIPTION:
After installing fix packs 7.0.0.39, 8.0.0.11 or 8.5.5.7, signed SAML tokens can no longer be propagated on downstream JAX-WS or trust client invocations. If your scenario meets all of the following conditions then you may experience this issue.
|
The XML in the token emitted will differ from the one received on each element where a namespace prefix is used. The emitted XML will be logically the same as the one received, but signature validation may fail. For example:
<saml2:Issuer>IS02</saml2:Issuer> |
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">IS02</saml2:Issuer> |
- Unsigned SAML tokens
Although the XML is altered, since the token emitted is logically the same as the one that was received, the token will pass validation.
- Encrypted SAML tokens
Since the signature in an encrypted SAML token is included in the encrypted token bytes, it cannot be modified. After the token is decrypted, the signature validation will pass.
To fix a memory leak, APAR PI32262 used an alternative cloning mechanism to clone a SAML token before it is put on the runAs subject. This alternative cloning method produced an element that has XML that is logically the same as the original, but the XML text is different. The difference is that the namespace declaration is replicated on each element that uses a namespace prefix. In many cases that is ok, however, if the token was signed, the signature in the token will no longer be valid.
If the SAML token that has a signature is pulled from the runAs subject or auth cache and re-used in any way where the signature must be validated, the signature validation will fail. For instance, it cannot be propagated on a downstream web services invocation or used in a trust client token exchange.
The fix for this APAR is currently targeted for inclusion in fix packs 7.0.0.43, 8.0.0.13 and 8.5.5.10. Please refer to the Recommended Updates page for delivery information:
http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980
Keywords: IBMWL3WSS, WSSEC, SAMLWSSEC, INTERIMFIX
THIS FIX HAS BEEN SUPERSEDED BY THE FIX FOR PI56581.
This fix has been superseded by the fix for PI56581. To obtain a fix for PI56377, see http://www-01.ibm.com/support/docview.wss?uid=swg24042605.
Technical Support
Contact IBM Support using SR (http://www.ibm.com/software/support/probsub.html), visit the WebSphere Application Server support web site (http://www.ibm.com/software/webservers/appserv/was/support/), or contact 1-800-IBM-SERV (U.S. only).
Problems (APARS) fixed
Was this topic helpful?
Document Information
Modified date:
15 June 2018
UID
swg24041730