You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In my use case I am attempting to have WordPress consume a signed and encrypted assertion.
Unfortunately, when I turn on encryption (by checking Reject Unencrypted Assertions checkbox via the onelogin_saml_configuration settings - this triggers our IdP to then encrypt assertions as the SP metadata then includes an encryption certificate) the the assertions fail due to failed signature validation:
Signature validation failed. SAML Response rejected
There was at least one error processing the SAML Response: invalid_response
Contact the administrator
I believe I've managed to track down what I believe is the issue:
It appears that the default "else" case is what is causing the problem. Could the "else" case just "do nothing" instead of re-namespacing the assertion element?
Capturing the decrypted assertion via logs prior to the code above results in the following:
More importantly is the <SignedInfo> element. With the above mentioned lines the <SignedInfo> element receives a new prefix namespace "default" transforming it to the following:
What "possible issue with saml namespace" are those lines attempting to correct? This only appears to break encrypted assertions. Signed assertions left "in the clear" (unencrypted) are unaffected (and also do no have their <SignedInfo> element replaced with <default:SignedInfo>.
The text was updated successfully, but these errors were encountered:
lwg-galuise
changed the title
Encryption is breaking Assertion Signatures
Decryption is breaking Encrypted Assertion Signatures
Jun 28, 2022
The Issue
Hi,
In my use case I am attempting to have WordPress consume a signed and encrypted assertion.
Unfortunately, when I turn on encryption (by checking Reject Unencrypted Assertions checkbox via the onelogin_saml_configuration settings - this triggers our IdP to then encrypt assertions as the SP metadata then includes an encryption certificate) the the assertions fail due to failed signature validation:
I believe I've managed to track down what I believe is the issue:
It appears that in php/lib/Saml2/Response.php lines 1175-1190 some manipulation of XML namespaces is made in an attempt to "Fix (a) possible issue with saml namespace": https://github.com/onelogin/wordpress-saml/blob/e0e1e68dea4ba100f380efcd7c2331d379376867/onelogin-saml-sso/php/lib/Saml2/Response.php#L1175-L1190
It appears that the default "else" case is what is causing the problem. Could the "else" case just "do nothing" instead of re-namespacing the assertion element?
Capturing the decrypted assertion via logs prior to the code above results in the following:
More importantly is the
<SignedInfo>
element. With the above mentioned lines the<SignedInfo>
element receives a new prefix namespace "default" transforming it to the following:This of course "breaks" (or invalidates) said signature/digest and thus causes the SAML Assertion to be rejected.
Configuration details
The site is running on Pressable.
WordPress version: 6.0
php Version: 7.4
The IdP in question is an in-house developed IdP and we are using the following .NET SAML library: https://github.com/ITfoxtec/ITfoxtec.Identity.Saml2
What "possible issue with saml namespace" are those lines attempting to correct? This only appears to break encrypted assertions. Signed assertions left "in the clear" (unencrypted) are unaffected (and also do no have their
<SignedInfo>
element replaced with<default:SignedInfo>
.The text was updated successfully, but these errors were encountered: