SigAlg and Signature being sent with HTTP-Redirect, but not with HTTP-POST
2,242 views
Skip to first unread message
Neil Davis
Sep 18, 2015, 10:34:52 AM9/18/15
to SimpleSAMLphp
We have a client that we're implementing SSO using SimpleSAMLphp using SAML 2.0.
The client requires that we post our fields to them. They were returning a "No Signature!" error when POSTING, and indeed the fields weren't being sent.
To rule out a problem with the configuration, I switched to HTTP-Redirect:
'SingleSignOnService' => array(
array(
'Location' => 'https://xxxxxxxxxxxxx/xxxxxxxx',
'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect',
),
),
and the request looked like:
This is exactly what they're looking for, but it has to be POST.
So I changed to HTTP-POST:
'SingleSignOnService' => array(
array(
'Location' => 'https://xxxxxxxxxxxxx/xxxxxxxx',
'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST',
),
),
And the SigAlg as well as the Signature parameters disappear and it seems to be encrypting the SAML request differently:
The _only_ simplesamlphp configuration difference between these requests is the choice of binding in IdP remote. Literally the only difference is what's bolded in my SingleSignOnService['Binding'] Parameter.
Is something broken here?
Where should I look in the SimpleSAMLPhp source to find out why this is happening. I'll submit a bugfix if someone can point me in the right general direction. Grepping code now to figure out where this happens...
thx,
Neil
Jeffrey Krug
Sep 18, 2015, 10:43:39 AM9/18/15
to simple...@googlegroups.com
It sounds like the bug is on their end. There are many products that do not understand the difference between the SAML Redirect binding and POST binding as specified within the SAML specifications. When using POST, SAML is supposed to include the signature within the XML and there should not be SigAlg/Signature parameters in the URL. Those parameters are only used as part of the SAML Redirect Binding.
This is specified in this SAML spec:
Section 3.4 and 3.5
--
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.
Neil Davis
Sep 18, 2015, 10:50:51 AM9/18/15
to SimpleSAMLphp
I did some more investigation....
SimpleSamlPHP is putting the Signature and SigAlg parameters into the xml before encrypting instead of sending them as POST parameters. Here is the unencrypted SAMLRequest message from the log using HTTP-Redirect:
Sep 18 14:47:32 simplesamlphp DEBUG [e59ce4cf99] <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_9043bde857073020801f53edd30368edff56f8dda8" Version="2.0" IssueInstant="2015-09-18T14:47:32Z" Destination="https://www-qa.accessaudi.com/samljct" ForceAuthn="true" AssertionConsumerServiceURL="http://simplesamlphp.cgproto.com/module.php/saml/sp/saml2-acs.php/www-qa.vwhub.com" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST">
Sep 18 14:47:32 simplesamlphp DEBUG [e59ce4cf99] <saml:Issuer>www-qa.vwhub.com</saml:Issuer>
Sep 18 14:47:32 simplesamlphp DEBUG [e59ce4cf99] <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" AllowCreate="true"/>
Sep 18 14:47:32 simplesamlphp DEBUG [e59ce4cf99] </samlp:AuthnRequest>
And here it is using HTTP-POST:
Sep 18 14:46:00 simplesamlphp DEBUG [e59ce4cf99] <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_6643ed6332c314b801864cf1c27f8ff7f2b5a80658" Version="2.0" IssueInstant="2015-09-18T14:46:00Z" Destination="https://www-qa.accessaudi.com/samljct" ForceAuthn="true" AssertionConsumerServiceURL="http://simplesamlphp.cgproto.com/module.php/saml/sp/saml2-acs.php/www-qa.vwhub.com" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST">
Sep 18 14:46:00 simplesamlphp DEBUG [e59ce4cf99] <saml:Issuer>www-qa.vwhub.com</saml:Issuer>
Sep 18 14:46:00 simplesamlphp DEBUG [e59ce4cf99] <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
Sep 18 14:46:00 simplesamlphp DEBUG [e59ce4cf99] <ds:SignedInfo>
Sep 18 14:46:00 simplesamlphp DEBUG [e59ce4cf99] <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
Sep 18 14:46:00 simplesamlphp DEBUG [e59ce4cf99] <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
Sep 18 14:46:00 simplesamlphp DEBUG [e59ce4cf99] <ds:Reference URI="#_6643ed6332c314b801864cf1c27f8ff7f2b5a80658">
Sep 18 14:46:00 simplesamlphp DEBUG [e59ce4cf99] <ds:Transforms>
Sep 18 14:46:00 simplesamlphp DEBUG [e59ce4cf99] <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
Sep 18 14:46:00 simplesamlphp DEBUG [e59ce4cf99] <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
Sep 18 14:46:00 simplesamlphp DEBUG [e59ce4cf99] </ds:Transforms>
Sep 18 14:46:00 simplesamlphp DEBUG [e59ce4cf99] <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
Sep 18 14:46:00 simplesamlphp DEBUG [e59ce4cf99] <ds:DigestValue>LXWIcR2XxBnVcTWPoNKLksa8j9o=</ds:DigestValue>
Sep 18 14:46:00 simplesamlphp DEBUG [e59ce4cf99] </ds:Reference>
Sep 18 14:46:00 simplesamlphp DEBUG [e59ce4cf99] </ds:SignedInfo>
Sep 18 14:46:00 simplesamlphp DEBUG [e59ce4cf99] <ds:SignatureValue>Y11he5LF+wLDmWpplVHRE72fGn3zZeYORqiyyD8T+H0L7SYcwfYjcxESfgccKgJkpqDrmccSfdD4mgdivH4Ifvs+mASG3ULWqz3yAencQ332SGe9UdVn8oMsgYcziDJeLz83vEjJW0l1WC0LYOwX4nn1R69UmZm3mdKOAoNKHOq+z0o5LUOgRqjGCJPq1WfDC5FZ2X0/0cvPsdhvi5ROVvCh+j0Wrl250rkAL5jGVpD7YfSnylxE3ac/HAPNhEtD8aWomMNpwjccxwmy8G63oHL5odvJ1zRG/EFkHkbSkAzyOX6IXjE6ZU/1lHJ3eyVJorWc9mPcPn6n75EATriRsQ==</ds:SignatureValue>
Sep 18 14:46:00 simplesamlphp DEBUG [e59ce4cf99] <ds:KeyInfo>
Sep 18 14:46:00 simplesamlphp DEBUG [e59ce4cf99] <ds:X509Data>
Sep 18 14:46:00 simplesamlphp DEBUG [e59ce4cf99] <ds:X509Certificate>MIIEmzCCA4OgAwIBAgIEEmleYTANBgkqhkiG9w0BAQUFADCBjjELMAkGA1UEBhMCVVMxETAPBgNVBAgTCE1pY2hpZ2FuMRUwEwYDVQQHEwxBdWJ1cm4gSGlsbHMxJDAiBgNVBAoTG1ZvbGtzd2FnZW4gR3JvdXAgb2YgQW1lcmljYTENMAsGA1UECxMESVRQTzEgMB4GA1UEAxMXc2FtbC1zc28tcWEudndvYS5uYS52d2cwHhcNMTEwODI1MTI1NDAwWhcNMTcwMjE0MTI1NDAwWjCBjjELMAkGA1UEBhMCVVMxETAPBgNVBAgTCE1pY2hpZ2FuMRUwEwYDVQQHEwxBdWJ1cm4gSGlsbHMxJDAiBgNVBAoTG1ZvbGtzd2FnZW4gR3JvdXAgb2YgQW1lcmljYTENMAsGA1UECxMESVRQTzEgMB4GA1UEAxMXc2FtbC1zc28tcWEudndvYS5uYS52d2cwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCn/zJQ1RyV5qLPC425D1Sl4azgffTv7rK5E3bUfyzY0f7/Fyve/4peEg8PCpTW7XNyEDVlaN5WkwVGzbyg7SUkb5UXfzdTQEQFO8k6t7U48+5LLUhq2tA+SzNebqsJIXSe8O4YuJYqnYRLfaF8s4YJiD4L9eLFAvupsr1T9tc5m+m/fFDTWPKqdHu872TVAkVT6bu1X51ZrE4NfnOC3gqrD8TFbeMyLOr1dGtx1P2nICDZCZjrWREoxyIpqNkP+fVyVrVKbd9xBNCgAO6pWLJ6ZtljOb63QnzcQQ9tg6Oblp8tMj1MTQtojfwHsn4EfRMNzd9a1jCUD3KIIwBled9xAgMBAAGjgf4wgfswDAYDVR0TBAUwAwEB/zAdBgNVHQ4EFgQUulb6Kjp2d1nF/Vvr6kYN6tr240Qwgb4GA1UdIwSBtjCBs4AUulb6Kjp2d1nF/Vvr6kYN6tr240ShgZSkgZEwgY4xCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhNaWNoaWdhbjEVMBMGA1UEBxMMQXVidXJuIEhpbGxzMSQwIgYDVQQKExtWb2xrc3dhZ2VuIEdyb3VwIG9mIEFtZXJpY2ExDTALBgNVBAsTBElUUE8xIDAeBgNVBAMTF3NhbWwtc3NvLXFhLnZ3b2EubmEudndnggQSaV5hMAsGA1UdDwQEAwICvDANBgkqhkiG9w0BAQUFAAOCAQEAcDHhbluvv2/P2GPt1i7pzOlbK4hBJGbycv4iToMmrpqdR4rsUmHwH4yw1t6fydL7JiyDEH0x//AJJcla7EmAu3/HfKZh7SVzNlL+fVpJax8C6xI9v/w+tS5ZcYVtwlCpGLG6DpA+71v5kG8g+uNKeB6EfXlto+jXL3QTXKQDDOsQyZ5k/dDOIVRXmTCY7/t1KyE4VNRLsWySSEozMAWH4TUeqdpQUlbIcRfoIIODnA77ZJ6jqQ2MapQbTadnIK8FqnW8epQdDtTxnOhSbg/LAm4QTtd2TEAWCf7TZuHRB03FfNogq4Q0Hgmq1N0/mLH/IvBx0MJ+s56yKcn+gon7zg==</ds:X509Certificate>
Sep 18 14:46:00 simplesamlphp DEBUG [e59ce4cf99] </ds:X509Data>
Sep 18 14:46:00 simplesamlphp DEBUG [e59ce4cf99] </ds:KeyInfo>
Sep 18 14:46:00 simplesamlphp DEBUG [e59ce4cf99] </ds:Signature>
Sep 18 14:46:00 simplesamlphp DEBUG [e59ce4cf99] <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" AllowCreate="true"/>
Sep 18 14:46:00 simplesamlphp DEBUG [e59ce4cf99] </samlp:AuthnRequest>
Peter Schober
Sep 18, 2015, 11:47:39 AM9/18/15
to SimpleSAMLphp
* Neil Davis <nda...@cantongroup.com> [2015-09-18 16:50]:
(Doing this not according to the specs would hardly have gone
unnoticed for many years.)
-peter
> I did some more investigation....
Save yourself the trouble. SSP does it correctly.
(Doing this not according to the specs would hardly have gone
unnoticed for many years.)
-peter
Neil Davis
Sep 18, 2015, 11:52:49 AM9/18/15
to SimpleSAMLphp
You are exactly correct! But I was asking why the sig parameters weren't in the POST request. I'd never assume that a POST request has url parameters. Why not just send all fields in POST? but I digress.
Sorry for not reading the spec more closely.
It's kind of odd the designers of the spec didn't just use the same set of fields for GET and POST. I know that GET arguments have a smaller size limit and splitting up the parameters helps reduce size, but there's no downside to having a a few more arguments in a POST request. It would simplify everyone's code.
I wonder why?..... I bet this isn't the first auth provider to make that same mistake.
thx,
Neil
Neil Davis
Sep 18, 2015, 12:05:03 PM9/18/15
to SimpleSAMLphp, peter....@univie.ac.at
You're absolutely right. It just looked odd that you'd use a different set of parameters for GET than you would for POST.
The main purpose of using SSP is so you don't need to write your own SAML library and pore over the spec line by line to get your code right. When a client sends you a spec that's 150 pages long and keeps telling you to make your code SAML 2.0 compliant, you start to doubt yourself and the code you are using when things aren't working and their developer is telling you to fix your code on the conference calls.
When I started debugging this issue I just saw this in the logs and it looked a little weird to me that the set of parameters and the SAML message looked different from GET to POST.
Usually, when using the HTTP/S protocols there is the same set of parameters being sent when you flip an option and switch methods from GET to POST.
Usually, when using the HTTP/S protocols there is the same set of parameters being sent when you flip an option and switch methods from GET to POST.
Next time I will read the spec when encountering broken implementations and figure out which side is broken first :)
Jeffrey Krug
Sep 18, 2015, 12:12:58 PM9/18/15
to simple...@googlegroups.com, peter....@univie.ac.at
The differences are much more profound than just the arguments. The encoding is different as well; Redirect deflate encodes the parameters to further reduce their size, where as POST is just base64 encoded version of the XML. Also with redirect, there are specific rules about how the signing happens, where as with POST the signature has all the flexibility afforded by XML-Dsig. I suspect the size limitations were the major factor in the original design decisions that went into the SAML Spec, and while 10 years of general progress might afford different decisions at this point, it does not really matter anymore as that was the decision made 10 years ago.
It is a common bug with vendor implementations sadly, and it can be a frustrating battle to get them to understand what they have done wrong I have fought that battle several times myself and it can be exhausting.
--
Peter Schober
Sep 18, 2015, 12:23:46 PM9/18/15
to SimpleSAMLphp
* Neil Davis <nda...@cantongroup.com> [2015-09-18 18:05]:
<saml...@lists.oasis-open.org> (esp if you don't mind reading specs,
which will be a likely reply), which will be quicker than going though
SAML core, bindings and profiles (and even non-SAML specs, like
xmldsig) next time something like this comes up.
-peter
> Next time I will read the spec when encountering broken
> implementations and figure out which side is broken first :)
You could also ask for pointers or guidance at
> implementations and figure out which side is broken first :)
<saml...@lists.oasis-open.org> (esp if you don't mind reading specs,
which will be a likely reply), which will be quicker than going though
SAML core, bindings and profiles (and even non-SAML specs, like
xmldsig) next time something like this comes up.
-peter
Reply all
Reply to author
Forward
0 new messages