SimpleSAMLPhp Exception with no message when using AD FS 2.0

553 views
Skip to first unread message

Glenn

unread,
Jun 25, 2014, 9:03:07 AM6/25/14
to simple...@googlegroups.com
I am currently trying to implement simpleSAMLphp with AD FS 2.0. I can now login with an AD FS 2.0 identity, but after logging in, simpleSAMLphp throws an exception. Unfortunately, it doesn't give me any other information.

Exception during login:
sspmod_saml_Error: Responder
Backtrace:
3 /var/www/cw/vendor/simplesamlphp/simplesamlphp/modules/saml/lib/Message.php:386 (sspmod_saml_Message::getResponseError)
2 /var/www/cw/vendor/simplesamlphp/simplesamlphp/modules/saml/lib/Message.php:493 (sspmod_saml_Message::processResponse)
1 /var/www/cw/vendor/simplesamlphp/simplesamlphp/modules/saml/www/sp/saml2-acs.php:96 (require)
0 /var/www/cw/vendor/simplesamlphp/simplesamlphp/www/module.php:135 (N/A)

I gather that after "Responder" I'm supposed to see a message of some kind. I decoded the response, but didn't find anything in the responder tag. Which seemed odd.

One possible culprit was the SHA versions used for signing. It was already set to SHA-256 on the AD FS server, but I hadn't set anything in the simpleSAMLphp config. I added the line to enable SHA-256, but it made no difference. In fact, changing the setting on both sides made no difference, which seemed odd - not even an error saying that the signature was invalid.

Here's the response, decoded, associated with the above exception. Does anyone have any ideas?

<?xml version="1.0" encoding="UTF-8"?>
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="_794a778e-7fce-4371-a2e2-f6b34c052598" Version="2.0" IssueInstant="2014-06-25T11:07:14.839Z" Destination="https://[SP domain redacted]/saml/module.php/saml/sp/saml2-acs.php/crowdauth" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" InResponseTo="_07372894a5b71fefefcc2397195bc2c36aa18e4d81">
   <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">https://[IdP domain redacted]/adfs/services/trust</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/2001/04/xmldsig-more#rsa-sha256" />
         <ds:Reference URI="#_794a778e-7fce-4371-a2e2-f6b34c052598">
            <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/2001/04/xmlenc#sha256" />
            <ds:DigestValue>4WhoStCVFVtvNyzknyTDOo0BvwM4IDrvp8BlXqehsn4=</ds:DigestValue>
         </ds:Reference>
      </ds:SignedInfo>
      <ds:SignatureValue>R3K0QFEBN3f8gbSKgDSGzDP2dhc5OU8qTiZtEBUIRiiBcE/xctlW8QgyHPF0NftjNeSs+uyNX7d6lpCK8MSxwfhtr1Qr+TC3Cwk1Fn4MyP0xBXCxTk36CzOMQ084HSPEFZOUUTriNvsgR+b7K7O/F2YDbog2ouPAczdt0F6B2uscGQulp8TYDs0AQN7wskEH8rIQIxdKHiHTZyw8618nYxMvDxE80dzybtesKU5tPGA8ibGglFZ9RsO+6fa5SltsJ0gX2rJ0+DM6uaAknzq0PopOzg+OgRlnDQlmVaOso35h9a2nrt0++ZRjxLnQnM64FYsFAquLpwCOanIB0YeIJw==</ds:SignatureValue>
      <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
         <ds:X509Data>
            <ds:X509Certificate>[Cert redacted]</ds:X509Certificate>
         </ds:X509Data>
      </KeyInfo>
   </ds:Signature>
   <samlp:Status>
      <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder" />
   </samlp:Status>
</samlp:Response>

Peter Schober

unread,
Jun 25, 2014, 10:11:48 AM6/25/14
to simple...@googlegroups.com
* Glenn <glenn....@crowdicity.com> [2014-06-25 15:03]:
> <samlp:Status>
> <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder" />
> </samlp:Status></samlp:Response>

Well, that's all MS-ADFS sent, then.
Nothing the recieving end (the SimpleSAMLphp SP) can do about it.
-peter

ste...@middlebury.edu

unread,
Jan 24, 2017, 5:07:33 PM1/24/17
to SimpleSAMLphp, peter....@univie.ac.at
This post was from a long time ago, however this is exactly what I'm encountering, but only when entering credentials for the first time. The authentication is successful, but the request cookies are not being set when posting back after authentication. Returning to the application and logging in again bypasses credentials and works fine. Test login on /simplesaml works fine after entering credentials. SHA-256 is used by signing on both sides. Has this been encountered by anyone else?

Jaime Perez Crespo

unread,
Jan 30, 2017, 5:23:36 AM1/30/17
to simple...@googlegroups.com
Hi,

On 24 Jan 2017, at 22:56 PM, ste...@middlebury.edu wrote:
> This post was from a long time ago, however this is exactly what I'm encountering, but only when entering credentials for the first time. The authentication is successful, but the request cookies are not being set when posting back after authentication. Returning to the application and logging in again bypasses credentials and works fine. Test login on /simplesaml works fine after entering credentials. SHA-256 is used by signing on both sides. Has this been encountered by anyone else?

If everything works fine when you are testing authentication directly from SimpleSAMLphp, but fails when starting authentication from your application, this looks likely to be an issue with your application’s session and SimpleSAMLphp’s. If you are using PHP sessions in both of them, make sure they have different names, and/or try using a different session backend in SimpleSAMLphp (e.g. memcache).

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

Reply all
Reply to author
Forward
0 new messages