Failed to decrypt element after months of working correctly

[Chris Ford]

What are you trying to do?

After two months of my SimpleSAMLphp SP working correctly with another party's ADFS IdP, the process stopped working suddenly.

What have you done?

• Dumped several vars in the path of the stacktrace, below, only to find that all information looks proper (keys, decryption providers, etc)
  
• Checked the log files which suddenly stopped working too
• Verified that the X509 certs match on the SP and IdP
  
• Received "Valid" return for XML to Schema test via samltools.com
  
• Received "Valid" return for AuthN Request test via samltools.com
  
• Received "Invalid" return for SAML Response test via samltools.com
  
• Verified that the X509 certs match on the SP and IdP
  
• Re-digested and replaced saml20-sp-remote and saml20-idp-remote
  
• Had the IdP re-run the ADFS SP wizard
  

Is there anything wrong?

I'm getting the "Failed to decrypt element" message in this stacktrace

SimpleSAML_Error_Error: UNHANDLEDEXCEPTION

/home/webapps/sso/simplesamlphp/www/module.php:180 (N/A) Caused by: Exception: Failed to decrypt XML element

/home/webapps/sso/simplesamlphp/vendor/simplesamlphp/saml2/src/SAML2/Utils.php:536 (SAML2_Utils::decryptElement)

/home/webapps/sso/simplesamlphp/vendor/simplesamlphp/saml2/src/SAML2/EncryptedAssertion.php:88 (SAML2_EncryptedAssertion::getAssertion) /home/webapps/sso/simplesamlphp/modules/saml/lib/Message.php:371 (sspmod_saml_Message::decryptAssertion) 3 /home/webapps/sso/simplesamlphp/modules/saml/lib/Message.php:550 (sspmod_saml_Message::processAssertion) 2 /home/webapps/sso/simplesamlphp/modules/saml/lib/Message.php:524 (sspmod_saml_Message::processResponse) /home/webapps/sso/simplesamlphp/modules/saml/www/sp/saml2-acs.php:120 (require)

/home/webapps/sso/simplesamlphp/www/module.php:137 (N/A)

Is there anything you don't understand?

I'm not sure how to continue troubleshooting this issue. However, I feel like it's some configuration on the IdP side.

[Jaime Perez Crespo]

Hi Chris,

If it was working fine, and then it stopped working overnight without you changing anything, then it’s likely that the IdP changed their key. Make sure you have their metadata updated with their up-to-date signing key.

--
Jaime Pérez
UNINETT / Feide

jaime...@uninett.no
jaime...@protonmail.com
9A08 EA20 E062 70B4 616B 43E3 562A FE3A 6293 62C2

"Two roads diverged in a wood, and I, I took the one less traveled by, and that has made all the difference."
- Robert Frost

[Chris Ford]

I requested a newly generated metadata file. It's exactly the same as the one I had on record for them. They contacted Microsoft and of course they are pointing the finger at our SimpleSAMLphp installation. I've reinstalled SimpleSAMLphp in a completely different place with updates and re-added metadata outputs. I'm still receiving the exact same "Failed to decrypt XML element" error.

[Peter Schober]

* Jaime Perez Crespo <jaime...@uninett.no> [2017-09-12 15:42]:

> If it was working fine, and then it stopped working overnight
> without you changing anything, then it’s likely that the IdP changed
> their key.

"Their key" meaning the SP's. Since the decryption of an encrypted
assertion fails that would be the IDP encrypting the assertion with a
key the SP doesn't have configured.
-peter

[Chris Ford]

Is there any way for me to verify this? I have their automated metadata URL, which from what I understand regenerates the XML upon request in case anything has changed. Both keys within the metadata are in my saml20-sp-remote and saml20-idp-remove metadata files as parsed by the SimpleSAMLphp interface. Also, they are saying that they have several other SP's that are working fine.

[Jaime Perez Crespo]

Thanks Peter! That's right, I was somehow thinking this was a signature validation error, don't ask me why.

Chris, make sure they also have your metadata updated. If they are encrypting the response, that's done with *your* key, so it could be that they messed up your key somehow...

--
Jaime

> --
> This is a mailing list for users of SimpleSAMLphp, not a support service. If you are willing to buy commercial support, please take a look here:
>
> https://simplesamlphp.org/support
>
> Before sending your question, make sure it is related to SimpleSAMLphp, and not your web server's configuration or any other third-party software. This mailing list cannot help with software that uses SimpleSAMLphp, only regarding SimpleSAMLphp itself.
>
> Make sure to read the documentation:
>
> https://simplesamlphp.org/docs/stable/
>
> If you have an issue with SimpleSAMLphp that you cannot resolve and reading the documentation doesn't help, you are more than welcome to ask here for help. Subscribe to the list and send an email with your question. However, you will be expected to comply with some minimum, common sense standards in your questions. Please read this carefully:
>
> http://catb.org/~esr/faqs/smart-questions.html
> ---
> You received this message because you are subscribed to the Google Groups "SimpleSAMLphp" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to simplesamlph...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Chris Ford]

We have exchanged metadata several times reinstalling over and over with files that are the exact same. Could their metadata URL somehow be giving us the wrong keys or vice versa?

[Peter Schober]

* Chris Ford <chris...@vcreativeinc.com> [2017-09-12 18:33]:

> Is there any way for me to verify this? I have their automated
> metadata URL, which from what I understand regenerates the XML upon
> request in case anything has changed.

The issue is with the key the IDP has for your SP, and the IDP
wouldn't publish your public key as part of its own metadata.

> Both keys within the metadata are in my saml20-sp-remote and
> saml20-idp-remove metadata files as parsed by the SimpleSAMLphp
> interface.

What "both keys"? And why would you have a saml20-sp-remote.php file
for a SAML SP? The SP would only look at saml20-idp-remote.php for IDP
metadata.

> Also, they are saying that they have several other SP's that are
> working fine.

So what do you want us to say? These are the facts, from your own log:

1. The IDP sent an encrypted SAML Assertion to your SP.
2. Your SP cannot decrypt it with the key pair(s) it has available.

You can but the blame wherever you want, but the above needs to change
if you want this to work.
Whether that's the IDP having the "wrong" certificate for your SP on
record, or whether your SP has the "wrong" key pair configured locally.
There's no "wrong" key here, of course, the only "right" is when both
parties have the same key configured.

If you have configured your SP exactly according to the documentation at
https://simplesamlphp.org/docs/stable/simplesamlphp-sp#section_1_1
you will have a file named "saml.crt" in your simplesamlphp/cert/
directory, and that key pair should also be referenced in your
simplesamlphp/config/authsources.php (as documented, ibid.).
If both these statements are true then "saml.crt" is what the IDP
needs to configure for your SAML SP.

If that's all the case and correct maybe we're overlooking something
else in the logs. (Not that I think that's the case.)
-peter

[Chris Ford]

Thank you for all of the info Jamie and Peter, and I apologize for my unfamiliarity with SSO and its inner-workings. I will ensure that the IdP has the proper key now that I know exactly where it is and that they needed it. However, I don't remember ever sharing it with them in the first place. Anyway, thanks again and take care.

[Peter Schober]

* Chris Ford <chris...@vcreativeinc.com> [2017-09-13 16:20]:

> Thank you for all of the info Jamie and Peter, and I apologize for my
> unfamiliarity with SSO and its inner-workings. I will ensure that the IdP
> has the proper key now that I know exactly where it is and that they needed
> it. However, I don't remember ever sharing it with them in the first place.
> Anyway, thanks again and take care.

If you did not give the IDP the cert manually you possibly gave it to
them via SAML Metadata, or the IDP pulled SAML Metadata from your
webserver (using SimpleSAMLphp's endpoint for that).
If that's also not the case I have no idea what public key the IDP
encrypts the Assertion to.
-peter

[harshap...@gmail.com]

Hey Chris, even I got the same issue. Did you got it working again?