Exception: Unable to find the current binding.
Scott Cline
I have an IdP-first scenario with me as the SP. The IdP uses PingFederate. Some of the IdP users are having issues connecting. Other users are connecting with no problem. The users that fail are getting the exception "Unable to find the current binding." The error messages are below.
simplesamlphp - ERR: [d15e090c65] SimpleSAML_Error_Exception: Error 8 - Undefined index: CONTENT_TYPE
simplesamlphp - ERR: [d15e090c65] Backtrace:
simplesamlphp - ERR: [d15e090c65] 2 /ltsites/simplesamlphp/www/_include.php:56 (SimpleSAML_error_handler)
simplesamlphp - ERR: [d15e090c65] 1 /ltsites/simplesamlphp/modules/saml/www/sp/saml2-acs.php:43 (require)
simplesamlphp - ERR: [d15e090c65] 0 /ltsites/simplesamlphp/www/module.php:135 (N/A)
simplesamlphp - ERR: [d15e090c65] SimpleSAML_Error_Exception: Error 8 - Undefined index: HTTP_REFERER
simplesamlphp - ERR: [d15e090c65] Backtrace:
simplesamlphp - ERR: [d15e090c65] 2 /ltsites/simplesamlphp/www/_include.php:56 (SimpleSAML_error_handler)
simplesamlphp - ERR: [d15e090c65] 1 /ltsites/simplesamlphp/modules/saml/www/sp/saml2-acs.php:46 (require)
simplesamlphp - ERR: [d15e090c65] 0 /ltsites/simplesamlphp/www/module.php:135 (N/A)
simplesamlphp - ERR: [d15e090c65] SimpleSAML_Error_Exception: Error 8 - Undefined index: CONTENT_TYPE
simplesamlphp - ERR: [d15e090c65] Backtrace:
simplesamlphp - ERR: [d15e090c65] 2 /ltsites/simplesamlphp/www/_include.php:56 (SimpleSAML_error_handler)
simplesamlphp - ERR: [d15e090c65] 1 /ltsites/simplesamlphp/modules/saml/www/sp/saml2-acs.php:47 (require)
simplesamlphp - ERR: [d15e090c65] 0 /ltsites/simplesamlphp/www/module.php:135 (N/A)
simplesamlphp - ERR: [d15e090c65] SimpleSAML_Error_Error: UNHANDLEDEXCEPTION
simplesamlphp - ERR: [d15e090c65] Backtrace:
simplesamlphp - ERR: [d15e090c65] 0 /ltsites/simplesamlphp/www/module.php:180 (N/A)
simplesamlphp - ERR: [d15e090c65] Caused by: Exception: Unable to find the current binding.
simplesamlphp - ERR: [d15e090c65] Backtrace:
simplesamlphp - ERR: [d15e090c65] 2 /ltsites/simplesamlphp/lib/SAML2/Binding.php:79 (SAML2_Binding::getCurrentBinding)
simplesamlphp - ERR: [d15e090c65] 1 /ltsites/simplesamlphp/modules/saml/www/sp/saml2-acs.php:61 (require)
simplesamlphp - ERR: [d15e090c65] 0 /ltsites/simplesamlphp/www/module.php:135 (N/A)
simplesamlphp - ERR: [d15e090c65] Error report with id d389db75 generated.
I added some print statements to the saml2-acs.php file and it looks like the HTTP data for the users that fail is missing the $_SERVER['CONTENT_TYPE']. I believe the problem is at the IdP as they're using proxys and VPNs and I think something is changing the POST to a GET or some such thing.
So, my question is how does SimpleSAMLphp determine that it has a valid HTTP POST assertion? Is it using the "Content-Type: application/x-www-form-urlencoded"? Or does it just look for the SAMLResponse in the input data?
Thanks!
--Scott
Olav Morken
> Hello,
>
> I have an IdP-first scenario with me as the SP. The IdP uses PingFederate. Some of the IdP users are having issues connecting. Other users are connecting with no problem. The users that fail are getting the exception "Unable to find the current binding." The error messages are below.
>
> simplesamlphp - ERR: [d15e090c65] SimpleSAML_Error_Exception: Error 8 - Undefined index: CONTENT_TYPE
> simplesamlphp - ERR: [d15e090c65] Backtrace:
> simplesamlphp - ERR: [d15e090c65] 2 /ltsites/simplesamlphp/www/_include.php:56 (SimpleSAML_error_handler)
> simplesamlphp - ERR: [d15e090c65] 1 /ltsites/simplesamlphp/modules/saml/www/sp/saml2-acs.php:43 (require)
> simplesamlphp - ERR: [d15e090c65] 0 /ltsites/simplesamlphp/www/module.php:135 (N/A)
> simplesamlphp - ERR: [d15e090c65] SimpleSAML_Error_Exception: Error 8 - Undefined index: HTTP_REFERER
> simplesamlphp - ERR: [d15e090c65] Backtrace:
> simplesamlphp - ERR: [d15e090c65] 2 /ltsites/simplesamlphp/www/_include.php:56 (SimpleSAML_error_handler)
> simplesamlphp - ERR: [d15e090c65] 1 /ltsites/simplesamlphp/modules/saml/www/sp/saml2-acs.php:46 (require)
> simplesamlphp - ERR: [d15e090c65] 0 /ltsites/simplesamlphp/www/module.php:135 (N/A)
> simplesamlphp - ERR: [d15e090c65] SimpleSAML_Error_Exception: Error 8 - Undefined index: CONTENT_TYPE
> simplesamlphp - ERR: [d15e090c65] Backtrace:
> simplesamlphp - ERR: [d15e090c65] 2 /ltsites/simplesamlphp/www/_include.php:56 (SimpleSAML_error_handler)
> simplesamlphp - ERR: [d15e090c65] 1 /ltsites/simplesamlphp/modules/saml/www/sp/saml2-acs.php:47 (require)
> simplesamlphp - ERR: [d15e090c65] 0 /ltsites/simplesamlphp/www/module.php:135 (N/A)
I believe these three first errors are due to your debugging code.
> simplesamlphp - ERR: [d15e090c65] SimpleSAML_Error_Error: UNHANDLEDEXCEPTION
> simplesamlphp - ERR: [d15e090c65] Backtrace:
> simplesamlphp - ERR: [d15e090c65] 0 /ltsites/simplesamlphp/www/module.php:180 (N/A)
> simplesamlphp - ERR: [d15e090c65] Caused by: Exception: Unable to find the current binding.
> simplesamlphp - ERR: [d15e090c65] Backtrace:
> simplesamlphp - ERR: [d15e090c65] 2 /ltsites/simplesamlphp/lib/SAML2/Binding.php:79 (SAML2_Binding::getCurrentBinding)
> simplesamlphp - ERR: [d15e090c65] 1 /ltsites/simplesamlphp/modules/saml/www/sp/saml2-acs.php:61 (require)
> simplesamlphp - ERR: [d15e090c65] 0 /ltsites/simplesamlphp/www/module.php:135 (N/A)
> simplesamlphp - ERR: [d15e090c65] Error report with id d389db75 generated.
>
> I added some print statements to the saml2-acs.php file and it looks like the HTTP data for the users that fail is missing the $_SERVER['CONTENT_TYPE']. I believe the problem is at the IdP as they're using proxys and VPNs and I think something is changing the POST to a GET or some such thing.
>
> So, my question is how does SimpleSAMLphp determine that it has a valid HTTP POST assertion? Is it using the "Content-Type: application/x-www-form-urlencoded"? Or does it just look for the SAMLResponse in the input data?
Actually, we do not really care about the Content-Type header (so long
as PHP manages to extract the POST-data - I do not know which logic PHP
uses for that though).
The logic for determining the current binding is located in the
getCurrentBinding() function in lib/SAML2/Binding.php. We first check
the request method. If it is a POST request, we look for the
SAMLRequest or SAMLResponse parameters. If we do not find them, we look
at the Content-Type to determine if it is a SOAP request.
Have you examined the REQUEST_METHOD parameter? Is it possible that the
request has been changed to a GET request?
Regards,
Olav Morken
UNINETT / Feide
James Kelly
security boundaries.
The IE Internet zone is set for "Enable Protected Mode", which is
essentially UAC for IE. The Intranet zone has Protected Mode off,
which sets that instance of IE to run in a higher privilege mode.
We have found that if we set IE8 or IE9 to be configured the same way
IE7 was by default (protected mode for both intranet and internet
zones), then the SAML assertion happens the way we expect and
everything works.
Scott Cline
My scenario is IdP-first and I'm the SP. The IdP is sending the SAML assertion to the client browser along with javascript to resend the assertion to the SP (me) as a POST request. However, IE isn't sending the data as standard HTTP POST data in the cross-security boundary case. So, when the SimpleSAMLphp PHP scripts process the request, PHP hasn't put any data into $_POST or $_REQUEST.
I've added some print_r statements at the beginning of modules/saml/www/sp/saml2-acs.php to see what's happening.
For successful connections, PHP variables have these values (and everything works fine):
$_SERVER[REQUEST_METHOD] => POST
$_SERVER[CONTENT_TYPE] => application/x-www-form-urlencoded
$_POST[SAMLResponse] => PHNhbWxw...
$_REQUEST[SAMLResponse] => PHNhbWxw...
For unsuccessful connections, PHP variables have these values (and we get the "Exception: Unable to find the current binding" error):
$_SERVER[REQUEST_METHOD] => POST
$_POST => ()
$_REQUEST => ()
I've added the following code to the beginning of modules/saml/www/sp/saml2-acs.php which does seem to get around this problem. The call to getCurrentBinding() (in lib/SAML2/Binding.php) returns a new SAML2_HTTPPost() and the assertion is processed.
if ( ! array_key_exists( 'SAMLResponse', $_POST ) {
$raw = file_get_contents( 'php://input' );
parse_str( $raw, $newPost );
if ( array_key_exists('SAMLResponse', $newPost ) ) {
foreach ($newPost as $index => $value) {
$_POST["$index"] = $value;
$_REQUEST["$index"] = $value;
}
}
My customer is using PingIdentity for their SSO IdP-first connection to us, the service provider. As I mentioned above, PingIdentity is sending the customer's browser some javascript with the SAML assertion which then causes the browser to send the assertion to us. However, the IE security protocols are not sending the HTTP POST requests as expected in all cases.
Do you think my work-around is a viable long-term fix for this issue? Have other SimpleSAMLphp users had similar issues with IE? Ideally, I'd like the SimpleSAMLphp code to handle this IE issue so I won't have to locally maintain a modification to the package. :-)
Thanks,
Scott
> --
> You received this message because you are subscribed to the Google Groups "simpleSAMLphp" group.
> To post to this group, send email to simple...@googlegroups.com.
> To unsubscribe from this group, send email to simplesamlph...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/simplesamlphp?hl=en.
>
Olav Morken
> Thanks Olav for your earlier response. I have some more information about the issue relating to what James posted (see below).
>
> My scenario is IdP-first and I'm the SP. The IdP is sending the SAML assertion to the client browser along with javascript to resend the assertion to the SP (me) as a POST request. However, IE isn't sending the data as standard HTTP POST data in the cross-security boundary case. So, when the SimpleSAMLphp PHP scripts process the request, PHP hasn't put any data into $_POST or $_REQUEST.
>
> I've added some print_r statements at the beginning of modules/saml/www/sp/saml2-acs.php to see what's happening.
>
> For successful connections, PHP variables have these values (and everything works fine):
>
> $_SERVER[REQUEST_METHOD] => POST
> $_SERVER[CONTENT_TYPE] => application/x-www-form-urlencoded
> $_POST[SAMLResponse] => PHNhbWxw...
> $_REQUEST[SAMLResponse] => PHNhbWxw...
>
> For unsuccessful connections, PHP variables have these values (and we get the "Exception: Unable to find the current binding" error):
>
> $_SERVER[REQUEST_METHOD] => POST
> $_POST => ()
> $_REQUEST => ()
>
> I've added the following code to the beginning of modules/saml/www/sp/saml2-acs.php which does seem to get around this problem. The call to getCurrentBinding() (in lib/SAML2/Binding.php) returns a new SAML2_HTTPPost() and the assertion is processed.
>
> if ( ! array_key_exists( 'SAMLResponse', $_POST ) {
> $raw = file_get_contents( 'php://input' );
> parse_str( $raw, $newPost );
> if ( array_key_exists('SAMLResponse', $newPost ) ) {
> foreach ($newPost as $index => $value) {
> $_POST["$index"] = $value;
> $_REQUEST["$index"] = $value;
> }
> }
>
> My customer is using PingIdentity for their SSO IdP-first connection to us, the service provider. As I mentioned above, PingIdentity is sending the customer's browser some javascript with the SAML assertion which then causes the browser to send the assertion to us. However, the IE security protocols are not sending the HTTP POST requests as expected in all cases.
>
> Do you think my work-around is a viable long-term fix for this issue? Have other SimpleSAMLphp users had similar issues with IE? Ideally, I'd like the SimpleSAMLphp code to handle this IE issue so I won't have to locally maintain a modification to the package. :-)
I think that if this workaround works for you, you don't have the issue
that James describes. In this case, PHP receives the POST data, but
ignores it for some reason. Is it possible that your PHP installation
is configured with some sort of extension that filters data that is
received from the browser? Maybe it has a maximum size that it will
allow?
I know that the Suhosin PHP extension has this capability, and it is
actually creating trouble for GET-requests when using the default
configuration on Debian Squeeze. We have therefore added a check for
that. However, the default POST limit is 1000000 bytes, which should
be more than enough space for a SAML Response.