PI56581: SIGNATURE IN PROPAGATED SAML TOKEN MAY NOT BE VALID DUE TO ADDED NAMESPACE DECLARATIONS

Fixes are available

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.

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 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
JAX-WS web service request.
2. The WS-Security constraints for the service contains a
caller configuration for the SAML token.
3. The SAML token contains a signature.
4. The SAML token is not encrypted.
5. The SAML token to be sent is retrieved from the auth cache
or runAs subject.
6. 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.

A new cloning mechanism is added to ensure that all tokens are
cloned in a way that their XML remains unchanged.  Previously,
only LTPA and SAML token token types were cloned before being
added to the runAs subject. To reduce the risk of memory
leaks for all token types, the implementation for this APAR
will clone all tokens before they are added to the runAs
subject.

When the following JVM System property is set to
true, only LTPA tokens will be cloned before being put on the
runAs Subject:

com.ibm.ws.wssecurity.useOldCloneCriteria=true

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

Use one of types of SAML tokens that are not affected:

* Encrypted SAML tokens
* Unsigned SAML tokens

Comments

APAR Information

APAR number
PI56581
Reported component name
WEBS APP SERV N
Reported component ID
5724H8800
Reported release
700
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2016-02-03
Closed date
2016-06-27
Last modified date
2016-08-10

APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:

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

[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"7.0","Line of Business":{"code":"LOB45","label":"Automation"}}]

Document Information

Modified date:
27 April 2022

Tips

PI56581: SIGNATURE IN PROPAGATED SAML TOKEN MAY NOT BE VALID DUE TO ADDED NAMESPACE DECLARATIONS

Fixes are available

Subscribe

APAR status

Closed as program error.

Error description

Local fix

Problem summary

Problem conclusion

Temporary fix

Comments

APAR Information

APAR number

Reported component name

Reported component ID

Reported release

Status

PE

HIPER

Special Attention

Submitted date

Closed date

Last modified date

APAR is sysrouted FROM one or more of the following:

APAR is sysrouted TO one or more of the following:

Fix information

Fixed component name

Fixed component ID

Applicable component levels

R700 PSY

R800 PSY

R850 PSY

Document Information

Share your feedback

Need support?