How do I validate signed data?

[John Taylor]

I am brand new to SAML 2.0 and simpleSAMLphp.  We have downloaded and configured and all seems good.  We have compared our XML response to the SP and it even looks good.  They are telling us that the document doesn't validate.  Below is what we are sending.  Can someone tell us how to validate this?

This is my third attempt to post this question.  I believe I need to attach the document so here it is again, with document attached.

Thanks for your help,

John

[Jeffrey Krug]

You will need to elaborate on your partner.  It's unlikely the issue is actually a xml validation issue, although that might be possible.  More likely it's a requirement of the SAML consuming product/library they are using that needs something different in the SAML assertion that you are sending.  

--
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 http://groups.google.com/group/simplesamlphp.
For more options, visit https://groups.google.com/d/optout.

[Peter Schober]

* John Taylor <johnta...@gmail.com> [2015-11-10 21:59]:
> <?xml version="1.0" encoding="UTF-8"?><samlp:Response xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Destination="https://den-signoff09.castlighthealth.com/sessions/assertion_consumer_service" ID="_8bfe87b2d9324c08761f514748a6cff56882000516" IssueInstant="2015-11-10T14:00:46Z" Version="2.0">
> <saml:Issuer>https://den-signoff09.castlighthealth.com/sessions/assertion_consumer_service</saml:Issuer>

If
"https://den-signoff09.castlighthealth.com/sessions/assertion_consumer_service"
is the ACS URL of the SAML SP, why is
"https://den-signoff09.castlighthealth.com/sessions/assertion_consumer_service"
also the Issuer of the SAML response? That can't be right.
Did you name your SAML IDP the same as a protocol endpoint of a SAML
SP you're trying to federate with? Why?

> <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
> SPNameQualifier="den-signoff09.castlighthealth.com:saml2.0">
[..]
> <saml:AudienceRestriction>
> <saml:Audience>den-signoff09.castlighthealth.com:saml2.0</saml:Audience>
> </saml:AudienceRestriction>

"den-signoff09.castlighthealth.com:saml2.0" is the entityID of the
SAML SP in question? Note that that's not a legal value, as entityIDs
are of type anyURI, and a URI at least needs a (registered) schema.
(Not that this will trip up anything in practice, it's just a mistake
on their end.)
-peter

[John Taylor]

Thank you Jeffrey and Peter for your responses.

I am being told this "the digital signature you are sending is NOT validating against your key. ".  

The person also provided an example of a document he signed with our private key which he says does validate  (attached) .

Also, I found a PHP program (I think one of you might have provided it in a prior post) to try to validate the signature (also attached), but I'm confused on what data is being validated, the whole document or only a certain section of it.

Thank you for your help.

John

-----

"If "https://den-signoff09.castlighthealth.com/sessions/assertion_consumer_service" is the ACS URL of the SAML SP, why is "https://den-signoff09.castlighthealth.com/sessions/assertion_consumer_service" also the Issuer of the SAML response? That can't be right. Did you name your SAML IDP the same as a protocol endpoint of a SAML SP you're trying to federate with? Why? "

Peter, being new to this I wasn't sure what went where.  I think I know where to change this and will work on that too.  Thank you for pointing this out.

[Peter Schober]

* John Taylor <johnta...@gmail.com> [2015-11-11 15:14]:

> The person also provided an example of a document he signed with our
> private key which he says does validate (attached) .

"He signed with our private key"?!

Gives a new meaning to "private [key]", at least.

> Also, I found a PHP program (I think one of you might have provided
> it in a prior post) to try to validate the signature (also
> attached), but I'm confused on what data is being validated, the
> whole document or only a certain section of it.

Given the level of detail provided here (I found what? where? doing
what specifically?) there's not much to say.
-peter

[John Taylor]

Peter,  It is test data.  We will be changing the keys once we have connectivity.  All I'm trying to do is confirm what he is saying is true.  If true, I need to set up a test bed for me to troubleshoot what is wrong on my end.

[Jeffrey Krug]

Typically one checks the signature with a Service Provider.  There are some tools out there you can use to try and check from the command-line, but they are not that easy to setup, so if your SP partner says the signature is not valid, it make sense to look for a problem with your configuration.  One thing you may want to verify is that the certificate and private key you are using are indeed a public/private keypair.  Here is a page you can review to determine this:

https://kb.wisc.edu/middleware/page.php?id=4064

Specifically you want to look at this section of saml20-idp-hosted.php:

        'privatekey' => 'idp-key.pem',

        'certificate' => 'idp.crt',

If the key and certificate specified in this part of simplesamlphp are not a keypair, then your signatures will never be valid.

On Tue, Nov 10, 2015 at 2:53 PM, John Taylor <johnta...@gmail.com> wrote:

I'm brand new to SAML 2.0 and simpleSAMLphp but I thought I had it all figured out because I've provided the XML exactly as they have requested.  I'm being told that it does not validate.  If someone could help me with this I would greatly appreciate it.

This is the document that is being sent to the SP.  Can someone tell me how I can validate this or help me understand why it is not validating?

<?xml version="1.0" encoding="UTF-8"?><samlp:Response xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Destination="https://den-signoff09.whitedout.com/sessions/assertion_consumer_service" ID="_8bfe87b2d9324c08761f514748a6cff56882000516" IssueInstant="2015-11-10T14:00:46Z" Version="2.0">

    <saml:Issuer>https://den-signoff09.whitedout.com/sessions/assertion_consumer_service</saml:Issuer>

    <samlp:Status>

        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>

    </samlp:Status>

    <saml:Assertion xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ID="_bed29332b96243f30796107ee826cf7c3bc735216a" IssueInstant="2015-11-10T14:00:46Z" Version="2.0">

        <saml:Issuer>https://den-signoff09.whitedout.com/sessions/assertion_consumer_service</saml:Issuer>

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

<ds:SignedInfo>

                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>

<ds:Reference URI="#_bed29332b96243f30796107ee826cf7c3bc735216a">

                    <ds:Transforms>

                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>

                        <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

                    </ds:Transforms>

                    <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>

                    <ds:DigestValue>LvGrytBUNawUj64Irctwm0rs4Lo=</ds:DigestValue>

                </ds:Reference>

            </ds:SignedInfo>

            <ds:SignatureValue>Rbk8eEmkcvgL5azqn8Jlm5ZMGy0V3xdLWbcZCkMDcsik9FNb230YJpntjNwJZ1SYYkmTrsu3qT46vbEw6ZSTX/VW090fIqSp6QoOo1+NxQ2di48Fi7MVVXgqGjE3MQzHuIZwLXYDNY0NoQ3jHsq8lhvPEjtIXnmDKLVcDC6XtmhjUsWttZTtHUdbc+Jsbbu5aOsRNX0GW5Uue9UgyJuMuCg7gBJOZPhgokzxG/ZenelIJ73tWeS2i0nzMwDPnjm/3Bb9vmRpk2XJdtJV12XjoUuSybVjO3atsSXycq3VVD7roiqx8x9SHk32GDlnfRoBnJkN+nVyc7rrPXrvCNzJuw==</ds:SignatureValue>

<ds:KeyInfo>

                <ds:X509Data>

                    <ds:X509Certificate>MIIFMzCCBBugAwIBAgIJANwuZLBC70cYMA0GCSqGSIb3DQEBBQUAMIHBMQswCQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxNzA1BgNVBAoTLlVuaW9uIFBhY2lmaWMgUmFpbHJvYWQgRW1wbG95ZXMgSGVhbHRoIFN5c3RlbXMxFjAUBgNVBAsTDUlTIERlcGFydG1lbnQxFDASBgNVBAMTC0JyYWQgUG9ydGVyMSMwIQYJKoZIhvcNAQkBFhRicG9ydGVyQHVwaGVhbHRoLmNvbTAeFw0xNTExMDYxODMyMjZaFw0yNTExMDUxODMyMjZaMIHBMQswCQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxNzA1BgNVBAoTLlVuaW9uIFBhY2lmaWMgUmFpbHJvYWQgRW1wbG95ZXMgSGVhbHRoIFN5c3RlbXMxFjAUBgNVBAsTDUlTIERlcGFydG1lbnQxFDASBgNVBAMTC0JyYWQgUG9ydGVyMSMwIQYJKoZIhvcNAQkBFhRicG9ydGVyQHVwaGVhbHRoLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMa7qogRaJL4u0rT4/75EQwGcUOWptxNvClMkbVeEiATiey6EWHN+HeiJKKPSdHUgryC4y6UdzX/LOhOOZUP6WmWlAyMKrX3qAk6IuCoMcU67JqfYGCPij4S8QslFfmHqrg25kOApahNLk1cEUBbfh3hFyhhZwwnCWEd63xLKjJSeFJdTDtgtExEG273cM6Xoy0sFQIFIUoXCuzBPofdehzdsykJj37MRIuy8EK5UqVlvQdIeKKRq0P1uKYVXD7qLo7WNGgv+sbZHp5+NyfEuh6XSXTXJQgFRRkqo5VnG2y+ub4cSjWzEd+lhYk3igq+SUQYy6Pi96oM0N3dzPLmqKcCAwEAAaOCASowggEmMB0GA1UdDgQWBBQOGdtF5OnSGa6HPPHIrmTbdGdp9TCB9gYDVR0jBIHuMIHrgBQOGdtF5OnSGa6HPPHIrmTbdGdp9aGBx6SBxDCBwTELMAkGA1UEBhMCVVMxDTALBgNVBAgTBFV0YWgxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MTcwNQYDVQQKEy5VbmlvbiBQYWNpZmljIFJhaWxyb2FkIEVtcGxveWVzIEhlYWx0aCBTeXN0ZW1zMRYwFAYDVQQLEw1JUyBEZXBhcnRtZW50MRQwEgYDVQQDEwtCcmFkIFBvcnRlcjEjMCEGCSqGSIb3DQEJARYUYnBvcnRlckB1cGhlYWx0aC5jb22CCQDcLmSwQu9HGDAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQBsWzXTEpbKRigFc4KmoGQm67mzwp1ESq1sXttcMalYEK/Tx+JIPQc4+8zVSW23ZXgqYbU5QZmy0Cc6cDAm2KU2Mmp8NCL6+HrZ9ATwPdvxt0BhdJ0fWqTNKx6DDrwwIFQoonyd8e/lUJjyNbiaXRSaHOX6M4h1h7kMgXN84wUqhdL9xdnNf4dTWRqW+/4f14/P21bNIB3J5Mdm/TsCY4ebAzSNblAe4TdHqqmx14m3gRu0VVtybOI/DnG88GtNuwnYVykdroiJnfAJmzdf8weMzpPkLyhFOB5XBBHeJQ4sHISbQClcTxlEoPfQxrzrkVw7ImK2dWEc32I9xUM0/r/6</ds:X509Certificate>

                </ds:X509Data>

            </ds:KeyInfo>

        </ds:Signature>

        <saml:Subject>

            <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" SPNameQualifier="den-signoff09.whitedout.com:saml2.0">_9d6e7acad08753bbe0701175ee34b0fa77ccc69616</saml:NameID>

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

                <saml:SubjectConfirmationData NotOnOrAfter="2015-11-10T14:05:46Z" Recipient="https://den-signoff09.whitedout.com/sessions/assertion_consumer_service"/>

            </saml:SubjectConfirmation>

        </saml:Subject>

        <saml:Conditions NotBefore="2015-11-10T14:00:16Z" NotOnOrAfter="2015-11-10T14:05:46Z">

            <saml:AudienceRestriction>

                <saml:Audience>den-signoff09.whitedout.com:saml2.0</saml:Audience>

            </saml:AudienceRestriction>

        </saml:Conditions>

        <saml:AuthnStatement AuthnInstant="2015-11-10T14:00:46Z" SessionIndex="_aa23865583499b6a1c934e21f0388cd304bc08b722" SessionNotOnOrAfter="2015-11-10T22:00:46Z">

            <saml:AuthnContext>

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

            </saml:AuthnContext>

        </saml:AuthnStatement>

        <saml:AttributeStatement>

            <saml:Attribute Name="CLIENTID" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">

                <saml:AttributeValue xsi:type="xs:string">dXByZWhz</saml:AttributeValue>

            </saml:Attribute>

            <saml:Attribute Name="FIRSTNAME" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">

                <saml:AttributeValue xsi:type="xs:string">RnJlZA==</saml:AttributeValue>

            </saml:Attribute>

            <saml:Attribute Name="LASTNAME" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">

                <saml:AttributeValue xsi:type="xs:string">RmxpbnRzdG9uZQ==</saml:AttributeValue>

            </saml:Attribute>

            <saml:Attribute Name="DATEOFBIRTH" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">

                <saml:AttributeValue xsi:type="xs:string">MTk2MDAyMjg=</saml:AttributeValue>

            </saml:Attribute>

            <saml:Attribute Name="ZIPCODE" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">

                <saml:AttributeValue xsi:type="xs:string">ODQxMTY=</saml:AttributeValue>

            </saml:Attribute>

            <saml:Attribute Name="GUID" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">

                <saml:AttributeValue xsi:type="xs:string">VFNUOTk5OTk5OTk5</saml:AttributeValue>

            </saml:Attribute>

            <saml:Attribute Name="preferredLanguage" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">

                <saml:AttributeValue xsi:type="xs:string">ZW4=</saml:AttributeValue>

            </saml:Attribute>

        </saml:AttributeStatement>

    </saml:Assertion>

</samlp:Response>

[John Taylor]

Jeffrey,  Thank you for your input.  I was able to crack the problem last Friday.  For future searches here is what I did.  This may be the long way but it worked for me.  

1. I downloaded a utility from http://www.chalesproxy.com that gives you the ability to see the SAMLRespose.  In the response there is an element <input type="hidden" name="SAMLResponse" value="PHNh......T4=" />.  This is a very long value and is base64 encoded.  It needs to be decoded to validate.
   
2. To decode the SAMLResponse I used an online utility at https://rnd.feide.no/simplesaml/module.php/saml2debug/debug.php.  You copy and paste the base64 encoded value from SAMLResponse and decods the response.  (I think this utility is in your simpleSAMLphp download.  I couldn't get my copy to work)
3. Now to validate the signed data I then used another utility at https://www.samltool.com/validate_xml.php.  You copy and paste the XML response as decoded in number 2, select SAML Response as XSD Schema and it validates (or not).

All of this gave me the control environment I needed to troubleshoot what the SP was saying.  Shortly after discovering how to validate the SAMLResponse I then found a posting, that I can't dig up now, which fixed my invalid signature.  The problem was in the XMLSECLIBS.php program.  Line 796 of the old code was:

     if ($node instanceof DOMNode && $node->ownerDocument !== NULL && $node->isSameNode($node->ownerDocument->documentElement)) {.  

While line 732 of the new code is:         

     if ($node->isSameNode($node->ownerDocument->documentElement)) {

As soon as I updated the XMLSECLIBS program we validated.  I believe this has been corrected in the simpleSAMLphp download.  Change logs note that it is corrected in version 1.14.0.  I'm on 1.13.0 (Stable version).

Thanks again,

John

[Peter Schober]

* John Taylor <johnta...@gmail.com> [2015-11-16 16:47]:
> 1. I downloaded a utility from http://www.chalesproxy.com that gives you

> the ability to see the SAMLRespose. In the response there is an
> element <input type="hidden" name="SAMLResponse" value="PHNh......T4=" />.
> This is a very long value and is base64 encoded. It needs to be decoded
> to validate.

> 2. To decode the SAMLResponse I used an online utility at

> https://rnd.feide.no/simplesaml/module.php/saml2debug/debug.php. You copy
> and paste the base64 encoded value from SAMLResponse and decods the
> response. (I think this utility is in your simpleSAMLphp download. I
> couldn't get my copy to work)

> 3. Now to validate the signed data I then used another utility

> at https://www.samltool.com/validate_xml.php. You copy and paste the XML
> response as decoded in number 2, select SAML Response as XSD Schema and it
> validates (or not).

None of that does signature validation, of course.
As for 1, you can simply deactivate JavaScript temporatily and the IDP
will show you that same HTML form with the encoded SAMLResponse.
For 2 there's plenty of choice and many OSs likely have tools built-in
for base64 encoding and decoding.
For 3 there's also xmllint or XmlSecTool, neither of which requires
that you post your data to some online service.

> As soon as I updated the XMLSECLIBS program we validated. I believe
> this has been corrected in the simpleSAMLphp download. Change logs
> note that it is corrected in version 1.14.0. I'm on 1.13.0 (Stable
> version).

Maybe the change you're referring to is needed for the SP
implementation you're trying to use but I'm not aware that SSP up
until 1.13 has issued with generated xmldsig signatures?
-peter

[Jaime Perez Crespo]

Hi,

> On 17 Nov 2015, at 15:49 PM, Peter Schober <peter....@univie.ac.at> wrote:
>> As soon as I updated the XMLSECLIBS program we validated. I believe
>> this has been corrected in the simpleSAMLphp download. Change logs
>> note that it is corrected in version 1.14.0. I'm on 1.13.0 (Stable
>> version).
>
> Maybe the change you're referring to is needed for the SP
> implementation you're trying to use but I'm not aware that SSP up
> until 1.13 has issued with generated xmldsig signatures?

There was an issue reported by Stefan Winter, but that was related to the use of SHA-512 for the digest calculation in the signatures. This is the fix reported in the changelog for 1.14.0.

I can’t recall any other issues with signatures other than that (nor I can see others in the repository), but of course I could be missing it since I’m just an user of the library myself :-)

--
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

[Peter Schober]

* Jaime Perez Crespo <jaime...@uninett.no> [2015-11-17 16:11]:

> There was an issue reported by Stefan Winter, but that was related
> to the use of SHA-512 for the digest calculation in the
> signatures. This is the fix reported in the changelog for 1.14.0.
>
> I can’t recall any other issues with signatures other than that (nor
> I can see others in the repository), but of course I could be
> missing it since I’m just an user of the library myself :-)

Thanks. I do prefer people using their own software. ;)
-peter