Still having problems trying to (temporarily) get a test working

[o haya]

Hi,

So I am still trying to use the "cloned" instance of SimpleSAMLphp to do a successful test with the IdP.

As mentioned in previous threads, from the IdP logs of requests, I see two differences in the ACS in the request messages:

1) The URL in the ACS uses the IP address instead of FQDN.

2) The end of the URL in the ACS in the request is incorrect (it needs to be "saml1-acs.php" instead of "saml2-acs.php").

So to try to workaround #1, I modify the baseurlpath in config.php to use the IP address.

To workaround #2, I check the metadata from SimpleSAMLphp, and it looks like Binding "urn:oasis:names:tc:SAML:1.0:profiles:browser-post" has the matching ACS URL, so in the authsources.php, I change the 'ProtocolBinding' parameter to:

        'ProtocolBinding' => 'urn:oasis:names:tc:SAML:1.0:profiles:browser-post',

 

Then I restart the Apache and test, but it is acting like before...  I see no logging in the logs/simplesaml.log file and I don't see anything hitting the IdP either.

In the browser I see this:

SimpleSAML_Error_Error: UNHANDLEDEXCEPTION

Backtrace: 1 www/_include.php:45 (SimpleSAML_exception_handler) 0 [builtin] (N/A) Caused by: Exception: Unable to validate Signature Backtrace: 6 vendor/simplesamlphp/saml2/src/SAML2/Utils.php:179 (SAML2\Utils::validateSignature) 5 vendor/simplesamlphp/saml2/src/SAML2/Assertion.php:651 (SAML2\Assertion::validate) 4 modules/saml/lib/Message.php:216 (sspmod_saml_Message::checkSign) 3 modules/saml/lib/Message.php:613 (sspmod_saml_Message::processAssertion) 2 modules/saml/lib/Message.php:578 (sspmod_saml_Message::processResponse) 1 modules/saml/www/sp/saml2-acs.php:129 (require) 0 www/module.php:135 (N/A)

I guess I still don't understand why I am getting this error?  Why is the signature validation failing? 

As I said, I restarted the Apache already (actually several times).  Is there something else that is caching, and I need to clear or restart?

Thanks,

Jim

[o haya]

I was trying to understand that validation error in the first post above, and I found an older thread here (sorry, I cannot find that thread again :( ) saying that the validation error might mean that the IdP metadata that the SP (i.e., in my case, SimpleSAMLphp) has may have the wrong signing key?

So I was reading this:

https://simplesamlphp.org/docs/stable/simplesamlphp-sp#section_4

and because of that, I was looking at metadata/saml20-idp-remote.php

If I understand correctly, in saml20-idp-remote.php, I should be able to see the signing and encryption certs that it got as part of the importing the IdP metadata. 

Is that correct?

So, I pulled the metadata from the IdP now, and that has the signing and encryption certs, but if I compare that to what is in the saml20-idp-remote.php, the one from the saml20-idp-remote.php does not match the IdP metadata that I just pulled from the IdP.

And I gather/think that those certs SHOULD match/be the same.

Is that correct???  Am I understanding correctly?

Would THAT (mismatch) cause the signature validation error I am seeing (and posted in the 1st post)?

If so, it sounds like, not only do we have to export the SP metadata from SimpleSAMLphp and import that into the IdP, BUT we ALSO need to export the IdP's metadata and import that metadata into SimpleSAMLphp???

I mean we have to do both of those exchanges AGAIN now (I had ASSUMED that both exchanges had been done way before this!!), as the metadata that each partner has is not matching.

Please advise.

Thanks,

Jim

[O haya]

Ahh - I found the thread I mentioned:

https://groups.google.com/g/simplesamlphp/c/Biz8WdCCyDs#:~:text=If%20the%20signature%20validation%20fails%20at%20the%20ACS,It%20%28the%20signing%29%20Wrong%2C%20or%20the%20metadata%20you

and it was specifically the message from Peter Schober, where he said:

" If the signature validation fails at the ACS step then SimpleSAMLphp
(acting as SAML SP) wasn't able to validate the IDP's signature on the
SAML Response or Assertion.
I.e., either They're Doing It (the signing) Wrong, or the metadata you
have on record for their IDP is off (esp the key therein).
The decoded and reformatted dump of their POST which you posted later
is useless for debugging signature errors. "

[O haya]

P.S.  I also am thinking that the reason I have problems when I make the change in the config.php and in the authsources.php may be that those changes I make allows the processing to 'go further', and then it gets to the point that SimpleSAMLphp is trying to validate the signature, AND THEN, BANG(!) I get the signature validation error, which then kind of stops everything from going forward.

Does that maybe explain what is happening?

Thanks,

Jim

On Sunday, October 10, 2021 at 6:12:04 PM UTC-4 ohay...@gmail.com wrote:

[Peter Schober]

* O haya <jim...@gmail.com> [2021-10-11 00:18]:

> Does that maybe explain what is happening?

I'm not claiming I can follow your very public stream of conciousness
you're currently dumping on this list, but no. If verifying the
signature fails the most likely explanation is you not having the
right certificate for the IDP configured. It's that simple.

-peter

[Peter Schober]

* o haya <ohay...@gmail.com> [2021-10-10 23:39]:

> As mentioned in previous threads, from the IdP logs of requests, I
> see two differences in the ACS in the request messages:
>
> 1) The URL in the ACS uses the IP address instead of FQDN.

And what is what the prod SP is putting into its authn request (and
the IDP has on record for that SP)?

Note that if the prod SP is generating authn requests with its IP
address in them you won't easily be able to make those responses go to
your test SP instead: The IDP will send a HTML form to your web
browser which would HTTP-POST the SAML response to the SP at the
requested location, i.e., the prod SP, not your test SP.
So if that's the behaviour you want to recreate I don't see how you
could transparently replace use of the prod SP with your test SP.

If OTOH the prod SP uses a host name in its SAML 2.0 authn requests
this is all rather easy and I've already provided you with a complete
write-up on how you'd achieve this.

> 2) The end of the URL in the ACS in the request is incorrect (it needs to
> be "saml1-acs.php" instead of "saml2-acs.php").

The ACS URL from the SP's SAML 2.0 authn request simply tells the IDP
where the SP wants to recieve the SAML Response (or Assertion).
The IDP is required to verify that location before use which is why
the IDP has a copy of the SP's metadata on record detailling the
SP's various endpoints.

The specific endpoint URLs are up to the SP and in the case of
SimpleSAMLphp they differ per SAML protocol version.

Note that SAML 1 did not even have authn requests at all!

> To workaround #2, I check the metadata from SimpleSAMLphp, and it
> looks like Binding
> "urn:oasis:names:tc:SAML:1.0:profiles:browser-post" has the matching
> ACS URL

Well, that's for a different protocol (SAML1 != SAML 2) so is not
appropriate for SAML 2.0 protocol messages. You are using SAML 2.0,
are you not? Does your browser show a SAML 2.0 authn request when you
look at HTTP requests and responses, e.g. using the SAML-tracer
extension?

Since (1) none of this makes any sense and (2) none of this will be of
any use to anyone else on this list (so I claim) I suggest you clone
the prod SP (instead of failing to recreate it) e.g. on the VM or disk
imaging level and be done with that excercise.
Then start your actual work of debugging the problem your prod SP is
seeing.

-peter