Unable to process the SAML WebSSO request : Unable to build SAML2 Logout Response Redirect URL : Failed to load SecretKeyEntry or
Hi,
We are using SP initiated SSO flow with SAML2.0 in Pega 8.6.1 with OpenAM as IdP. The IdP requires us to send a signed SAML request. When we clear the checkbox "Disable Request Signing" on the Service Provider (SP) settings section of the Authentication Service data instance, even though we have a valid signing certificate and referred that through a Keystore, the attempt to authenticate fails with the error - "Unable to process the SAML WebSSO request : Unable to build SAML2 Logout Response Redirect URL : Failed to load SecretKeyEntry or PrivateKeyEntry"
The SAML request never reaches the IdP. We have enabled debug logs on the class "com.pega.pegarules.integration.engine.internal.util.PRSAMLv2Utils " but the only useful information we see in the log is "RelayStateID - Caught Exception while building SAML2 Logout Response Redirect URL com.pega.pegarules.pub.PRRuntimeException: Failed to load SecretKeyEntry or PrivateKeyEntry"
Have anyone faced this issue and know how to resolve this ?
Thanks in advance
***Edited by Moderator Marije to add Capability tags***
Accepted Solution
Updated: 17 Mar 2022 15:21 EDT
Pegasystems Inc.
NL
Hi @trina_r, please verify the Authentication Service configuration with regards to your signing certificate. Likely the alias, passwords or keystore rule are incorrect configured. This information is used to construct the redirect url, not only for the logout scenario.
Kind regards,
Eric
Pegasystems Inc.
GB
Please check if the below suggestions help you.
Looping Issue between IDP and Pega has been known to get resolved after pointing the rest service in the authentication service rule to version 2.
The login URL is auto populated in the authentications service. Once the request is able to reach the server (node specific/load balancer) the engine checks for the appropriate auth service and executes accordingly.
Regarding app alias which was introduced from 8.4 please refer the following link
And since we are making use of PRAuth servlet we don’t need to make any changes in the web.xml file. However, if you want to modify the name “Prauth” there are some steps to be performed to modify accordingly.
There is no explicit documentation present as we create a new auth service in pega 8x it by default points to version 2 of the rest service. Perhaps the issue is that you modified this explicitly in last call?
Also try checking "Disable request signing" from okta service profile. The error can also occur if users are using "Request signing" option whilst the corresponding configuration at the IDP side is missing. Then use the SAML Authentication rule without the Request signing option.
Please check if the below suggestions help you.
Looping Issue between IDP and Pega has been known to get resolved after pointing the rest service in the authentication service rule to version 2.
The login URL is auto populated in the authentications service. Once the request is able to reach the server (node specific/load balancer) the engine checks for the appropriate auth service and executes accordingly.
Regarding app alias which was introduced from 8.4 please refer the following link
And since we are making use of PRAuth servlet we don’t need to make any changes in the web.xml file. However, if you want to modify the name “Prauth” there are some steps to be performed to modify accordingly.
There is no explicit documentation present as we create a new auth service in pega 8x it by default points to version 2 of the rest service. Perhaps the issue is that you modified this explicitly in last call?
Also try checking "Disable request signing" from okta service profile. The error can also occur if users are using "Request signing" option whilst the corresponding configuration at the IDP side is missing. Then use the SAML Authentication rule without the Request signing option.
Accepted Solution
Updated: 17 Mar 2022 15:21 EDT
Pegasystems Inc.
NL
Hi @trina_r, please verify the Authentication Service configuration with regards to your signing certificate. Likely the alias, passwords or keystore rule are incorrect configured. This information is used to construct the redirect url, not only for the logout scenario.
Kind regards,
Eric
Updated: 18 Mar 2022 10:58 EDT
TD
CA
@Eric Rietveld Thanks Eric, this indeed was a certificate issue. Our underlying JBOSS server has been upgraded from 7.0 to 7.3 and in the signing certificate's Keystore entry, it was referring to an outdated file path. After updating the keystore with the correct information, the issue is resolved and SP is able to send a signed SAML request to the IdP.