IdP Initiated SSO: Encrypted Assertion Fails with "Reference Validation Failed"

[Miguel Mendoza]

There are already quite a few topics with this error, but unfortunately none have helped me figure out the issue with my current SSPHP setup. Just for reference, I'm using a saml plugin for my Moodle installation which is uses SSPHP to authenticate via SAML 2. SAML Responses with signed assertions pass all the validation with flying colors and I'm able to authenticate as a Moodle user without issues. The IdP metadata looks like the following:

<?xml version="1.0"?>

<md:EntitiesDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="http://redacted.com/">

  <md:IDPSSODescriptor WantAuthnRequestsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">

    <md:KeyDescriptor use="signing">

      <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

        <ds:X509Data>

          <ds:X509Certificate>redactedcerthere</ds:X509Certificate>

        </ds:X509Data>

      </ds:KeyInfo>

    </md:KeyDescriptor>

    <md:KeyDescriptor use="encryption">

      <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

        <ds:X509Data>

          <ds:X509Certificate>redactedcerthere</ds:X509Certificate>

        </ds:X509Data>

      </ds:KeyInfo>

    </md:KeyDescriptor>

  </md:IDPSSODescriptor>

</md:EntityDescriptor>

</md:EntitiesDescriptor>

Note: I realize the singlelogout & singlesignon elements are missing. They are not needed for this use case.

The certs are correct since the signature validation check is passed and the user is able to login when the response only has a signed assertion. The reference validation failure occurs just prior to this for an encrypted assertion on the digest validation. Why would this fail for the encrypted assertion and not for the response with only a signed assertion?

Some more information from my debugging:

The decrypted assertion just prior to digest calculation:

<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ID="_4abaa651-3c61-4ced-ad34-9aeabaab297e" IssueInstant="2016-06-20T17:06:15Z" Version="2.0">

<saml:Issuer>http://redactedidp.com/</saml:Issuer>

<saml:Subject>

<saml:NameID>1001</saml:NameID>

<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">

<saml:SubjectConfirmationData NotOnOrAfter="2016-06-20T17:08:15Z" Recipient="https://redactedsp.com/auth/saml2/sp/saml2-acs.php/redactedsp.com"></saml:SubjectConfirmationData>

</saml:SubjectConfirmation>

</saml:Subject>

<saml:Conditions NotBefore="2016-06-20T17:06:15Z" NotOnOrAfter="2016-06-20T17:08:15Z"></saml:Conditions>

<saml:AuthnStatement AuthnInstant="2016-06-20T17:06:15Z">

<saml:AuthnContext>

<saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef>

</saml:AuthnContext>

</saml:AuthnStatement>

</saml:Assertion>

Here's the assertion for the response with the signed assertion only (no encryption):

<saml:Assertion Version="2.0" ID="_799ea540-8987-45b0-8806-0602ce602928" IssueInstant="2016-06-21T11:19:46Z" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">

<saml:Issuer>http://redactedidp.com/</saml:Issuer>

<saml:Subject>

<saml:NameID>1001</saml:NameID>

<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">

<saml:SubjectConfirmationData NotOnOrAfter="2016-06-21T11:21:46Z" Recipient="https://redactedsp.com/auth/saml2/sp/saml2-acs.php/redactedsp.com" />

</saml:SubjectConfirmation>

</saml:Subject>

<saml:Conditions NotBefore="2016-06-21T11:19:46Z" NotOnOrAfter="2016-06-21T11:21:46Z" />

<saml:AuthnStatement AuthnInstant="2016-06-21T11:19:46Z">

<saml:AuthnContext>

<saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef>

</saml:AuthnContext>

</saml:AuthnStatement>

</saml:Assertion>

Based on other topics, the issue is likely due to one of the following:

• Incorrect canonicalization at the IdP.
  
• Incorrect canonicalization at the SP.
  
• The message has been changed after it was canonicalized at the IdP.

The IdP in question already initiates SAML 2 authentication with other service providers, so the issue is likely with my SP set up. I've already confirmed that the digest algorithm used by the IdP is also used to recalculate the signature digest value on my end (SP). This is obviously successful with the signed assertion only, but not the encrypted and signed assertion (I've probably said this too much :)).

What other information am I missing that could point me in the right direction? Any feedback is very much appreciated. Thanks in advance!

[Jaime Perez Crespo]

Hi Miguel,

I wouldn’t discard the issue on the IdP side. Do you know what software are they using? If it’s a self-made implementation, it’s likely that there’s something wrong. There could even be a bug, of course. The fact that other SPs work fine indicates that their implementation should be correct, but you’d be surprised by the amount of SPs out there that do not perform signature verification…

In any case, what do you see in the log when validation fails? To be honest, it’s quite difficult to help with a problem like this without being able to debug it properly, so I’m afraid you are pretty much on your own, and you’ll need to attach a debugger there or at least spread some echoes here and there.

There’s one thing that catches my eye, though, that being the elements without content being collapsed (Conditions and SubjectConfirmationData). I don’t recall right now if that’s allowed, but in any case I find it strange that the encrypted+signed assertion and the signed assertion differ, not only in those elements, but also in the order of the attributes of the Assertion element. That might point indeed to an issue in the IdP.

> --
> 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.
> To post to this group, send email to simple...@googlegroups.com.
> Visit this group at https://groups.google.com/group/simplesamlphp.
> For more options, visit https://groups.google.com/d/optout.

--
Jaime Pérez
UNINETT / Feide
mail: jaime...@uninett.no
xmpp: ja...@jabber.uninett.no

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