Fixes are available
PI56377:Signature in propagated SAML token may not be valid because added namespace declarations
PI56581:Signature in propagated SAML token may not be valid due to added namespace declarations
8.5.5.10: WebSphere Application Server V8.5.5 Fix Pack 10
8.5.5.11: WebSphere Application Server V8.5.5 Fix Pack 11
8.0.0.13: WebSphere Application Server V8.0 Fix Pack 13
7.0.0.43: WebSphere Application Server V7.0 Fix Pack 43
8.5.5.12: WebSphere Application Server V8.5.5 Fix Pack 12
8.0.0.14: WebSphere Application Server V8.0 Fix Pack 14
8.5.5.13: WebSphere Application Server V8.5.5 Fix Pack 13
7.0.0.45: WebSphere Application Server V7.0 Fix Pack 45
8.0.0.15: WebSphere Application Server V8.0 Fix Pack 15
7.0.0.45: Java SDK 1.6 SR16 FP60 Cumulative Fix for WebSphere Application Server
7.0.0.43: Java SDK 1.6 SR16 FP41 Cumulative Fix for WebSphere Application Server
8.5.5.14: WebSphere Application Server V8.5.5 Fix Pack 14
8.5.5.15: WebSphere Application Server V8.5.5 Fix Pack 15
8.5.5.17: WebSphere Application Server V8.5.5 Fix Pack 17
8.5.5.20: WebSphere Application Server V8.5.5.20
8.5.5.18: WebSphere Application Server V8.5.5 Fix Pack 18
8.5.5.19: WebSphere Application Server V8.5.5 Fix Pack 19
8.5.5.16: WebSphere Application Server V8.5.5 Fix Pack 16
8.5.5.21: WebSphere Application Server V8.5.5.21
APAR status
Closed as program error.
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 fails signature validation. This behavior happens after installing fix packs 7.0.0.39, 8.0.0.11 or 8.5.5.7.
Local fix
n/a
Problem summary
**************************************************************** * USERS AFFECTED: IBM WebSphere Application Server * * administrators of WS-Security enabled * * JAX-WS applications and SAML * **************************************************************** * PROBLEM DESCRIPTION: SAML token may fail signature * * validation after being propagated by * * WS-Security * **************************************************************** * RECOMMENDATION: Install a fix pack or interim fix that * * contains this APAR. * **************************************************************** 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, 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. . 1. The SAML token is obtained from the Security header of a 2. JAX-WS web service request. 3. The WS-Security constraints for the service contains a caller configuration for the SAML token. 4. The SAML token contains a signature. 5. The SAML token is not encrypted. 6. The SAML token to be sent is retrieved from the auth cache or runAs subject. 7. The receiver of the token will validate the signature. . A SAML token may fail signature validation after being propagated by WS-Security. 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> . becomes . <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">IS02</saml2: Issuer> . The following SAML token types are not affected: * 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.
Problem conclusion
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, 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. This APAR is superseded by APAR PI56581. 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 SAMLWSSEC
Temporary fix
Comments
APAR Information
APAR number
PI56377
Reported component name
WEBS APP SERV N
Reported component ID
5724H8800
Reported release
850
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2016-02-01
Closed date
2016-02-09
Last modified date
2016-08-09
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
PI56885
Fix information
Fixed component name
WEBS APP SERV N
Fixed component ID
5724H8800
Applicable component levels
R700 PSY
UP
R800 PSY
UP
R850 PSY
UP
Document Information
Modified date:
28 April 2022