Fix (APAR): PI56377 Status: Fix Release: 7.0.0.39 Operating System: HP-UX,IBM i,Linux,Solaris,Windows Supersedes Fixes: CMVC Defect: xxxxxx Byte size of APAR: 18239 Date: 2016-02-10 Abstract: signature in propagated samltoken sometimes invalid because websphere adds namespace prefixes Description/symptom of problem: 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 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, 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. This problem only exists when all the the following conditions are met: * The SAML token is obtained from the Security header of a JAX-WS web service request. * The WS-Security constraints for the service contains a caller configuration for the SAML token. * The SAML token contains a signature. * The SAML token is not encrypted. * The SAML token to be sent is retrieved from the auth cache or runAs subject. * The receiver of the token will validate the signature. 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: IS02 becomes IS02 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. The fix for this APAR removes the fix for PI32262. This means that a memory leak may occur when both the following conditions are met: * Authentication cache is enabled. * A JAX-WS web service has a WS-Security binding with a caller configuration for a SAML token. This problem will be fixed on future 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 Directions to apply fix: Fix applies to Editions: Release 7.0 _x_ Application Server (Express or BASE) _x_ Network Deployment (ND) __ Edge Components __ Developer Install Fix to all WebSphere installations unless special instructions are included below. Special Instructions: None NOTE: The user must: * Logged in with the same authority level when unpacking a fix, fix pack or refresh pack. * Be at V7.0.0.0 or newer of the Update Installer. Certain iFixes may require a newer version of the Update Installer and the Update Installer will inform you during the installation process if a newer version is required. This can be checked by reviewing the level of the Update Installer in file /updateinstaller/version.txt. The Update Installer can be downloaded from the following link: http://www.ibm.com/support/docview.wss?rs=180&uid=swg21205991 1) If your iFix is delivered as a single file with a .pak extension, Copy the .pak file directly to the maintenance directory. If your iFix is delivered as a single file with a .zip extension, unzip the file into the maintenance directory. 2) Shutdown WebSphere Application Server. Manually execute setupCmdLine.bat in Windows or . ./setupCmdLine.sh in Unix from the WebSphere instance that maintenance is being applied to. 3) For IBM i users, use the update command to install and uninstall the interim fix. The IBM Knowledge Center can provide additional details, if needed, on the use of this command. http://www14.software.ibm.com/webapp/wsbroker/redirect?version=compass&product=was-nd-iseries&topic=rins_update. For non-IBM i users, launch the Update Installer and click the Next button on the Welcome page. 4) Enter the directory path of the installation location of the WebSphere product you want to update, and click the Next button. 5) Select the "Install maintenance package" operation and click the Next button. 6) Enter the directory path of your maintenance directory where you have the maintenance packages (.pak files) and click the Next button. 7) The Available Maintenance Package to Install page should list all maintenance packages (.pak files) that it finds in the directory path provided in the previous step. The Update Installer will select the correct maintenance packages based on your system configuration and will not allow an invalid combination to be installed. Please keep the Update Installer recommendations and click the Next button and continue with the installation of the maintenance package. To determine why some maintenance packages have been identified as not applicable, see description in log found in /logs/tmp*/updatelogs.txt 8) For all platforms except Windows. In pre-install summary panel, use the "verify permission" feature to verify the user has permissions to apply updates to files associated with the selected maintenance. Correct any file permissions before clicking next to start the install. 9) Restart WebSphere Application Server. Directions to remove fix: NOTE: * The user must have Administrative rights in Windows, or be the Actual Root User in a UNIX environments. * FIXES MUST BE REMOVED IN THE ORDER THEY WERE APPLIED * DO NOT REMOVE A FIX UNLESS ALL FIXES APPLIED AFTER IT HAVE FIRST BEEN REMOVED * YOU MAY REAPPLY ANY REMOVED FIX Example: If your system has fix1, fix2, and fix3 applied in that order and fix2 is to be removed, fix3 must be removed first, fix2 removed, and fix3 re-applied. 1) Shutdown WebSphere Application Server. Manually execute setupCmdLine.bat in Windows or . ./setupCmdLine.sh in Unix from the WebSphere instance that uninstall is being run against. 2) Start Update Installer 3) Enter the installation location of the WebSphere product you want to remove the fix. 4) Select "Uninstall maintenance package" operation. 5) Enter the file name of the maintenance package to uninstall (PKxxxxx.pak). 6) UnInstall maintenance package. 7) Restart WebSphere Directions to re-apply fix: 1) Shutdown WebSphere Application Server. 2) Follow the Fix instructions to apply the fix. 3) Restart WebSphere Application Server. Additional Information: