Issue 

After updating to the Pega platform version 26.1.0, SAML SSO integration with SSO stopped working. 

Below are two issues that were identified due to openSAML library update: 

 
Issue 1: Error during URL signing process: Could not derive JCA algorithm identifier from algorithm URI  

Issue 2: SAML login fails with error "Unable to process the SAML WebSSO request: Illegal base64 character d" after updating to Pega Infinity 26.1.0. 

Symptoms and impact  

Users cannot log in via SAML SSO in Infinity 26; error message displayed; login attempts fail for all users using the affected SAML provider. 

Issue 1: SAML HTTP-Redirect (Login / Log off) failing to create signed request URL due to the in availability of the algorithm. 
 
Error Observed:  
Message Unable to build SAML2 Logout Request Redirect URL: Unable to sign URL query string. 
Error during URL signing process: Could not derive JCA algorithm identifier from algorithm URI. 

This is specific to one configuration where we configure SLO in Authentication service and allow Request Signing. 

 

Issue 2: During login, the SAML Response received from an IDP cannot be unmarshalled and converted to SAMLObject 

The SAML response contains characters that cause base64 decoding to fail, resulting in illegal character error and preventing successful login. 
 
Error Observed:

Unable to process the SAML WebSSO request: Illegal base64 character d  

Steps to reproduce:  

Attempt to log in to the updated Platform ‘26.x release using SAML SSO; login fails with the specified error. 

Root Cause 

Product defect in SAML response handling introduced in 26.1.0. release. 

 
Issue 1:  SAML HTTP-Redirect (Login / Log off) failing to create signed request URL due to the in availability of the algorithm  

The issue is caused by a regression in Platform version 26.1.0 related to the SAML Request signing mechanism when a Signing Certificate is configured. The updated SAML library introduced a compatibility issue that prevented the proper derivation of the JCA algorithm identifier from the configured algorithm URI, resulting in the signing failure. 
 
Issue 2: This can happen with some IDPs that use different CLRF in response encodings.         

When an IdP wraps the base64 payload with CRLF (a MIME convention allowed by OASIS SAML 2.0 Bindings § 3.5.4), the embedded CR byte ( 0x0D) is not in the RFC 4648 alphabet, so the decoder throws IllegalArgumentException: Illegal base64 character d (the string "d" in the message is the hex representation of 0x0D, not the literal character) 

The IDP's listed below can be prone to this issue. Note this is not an exhaustive list, other IDPs may be affected:  

• Oracle OAM Federation, 

• Oracle Access Manager, 

• IBM Tivoli / SecurityVerify Access (ISAM), 

• IBM Security Verify, 

• CA/Broadcom SiteMinder Federation,  

• Ping Federate, 

• RSA SecurID Access,  

• Shibboleth IdP,  

• NetIQ Access Manager. 

Solution 

The issue was identified as a product bug and resolved by applying the following hotfixes: 

• HFIX-D2771 for 26.1.0  

• HFIX-D3336 for 26.1.1 

The hotfixes correct the SAML response processing to handle base64 decoding and HTTP redirection properly.