How does SimpleSAMLphp get the AssertionConsumerServiceURL that it sends to IdP?
511 views
Skip to first unread message
o haya
Oct 10, 2021, 4:26:38 AM10/10/21
to SimpleSAMLphp
Hi,
We are having a problem where it appears that the AssertionConsumerServiceURL (ACS) in the SP metadata that the IdP has has a URL with an IP address in it. I have not been working with SimpleSAMLphp for long, so I am not quite sure how that happened, and we don't have the actual SP metadata file that was imported into the IdP at this point.
So I have been testing using our "official" SimpleSAMLphp instance, and when I test, I can see the requests in the IdP side logging, and the ACS in the request has an FQDN/hostname.
So I was wondering, how does SimpleSAML formulate the value that it puts into the request to the IdP??
I worked with SimpleSAMLphp for a very short time, awhile ago, and I vaguely recall that at least PART of the ACS value is from the actual hostname where SimpleSAMLphp is running.
Is that true?
What about the rest of the ACS URL? Where (which config file, etc.) does that come from??
The main reason that I stood up the "new" test SimpleSAMLphp instance that I just stood up (see 2 threads before this one) was because I was hoping I could test what would happen if I changed the ACS coming from SimpleSAMLphp (we cannot change the original SimpleSAMLphp config "officially" until we know the fix, for sure), BUT, this new instance is running on a different machine, which has a different hostname, so when I look at the requests received by the IdP, the ACS in those requests have the hostname of my new machine :(... so maybe standing up the new instance is not going to be useful for testing?
The thing that REALLY puzzles me at this point is if I look at the /var/simplesamlphp/config/authsources.php, in that "CI" configuration, the ACS value has an IP address in it rather than a hostname:
- In request to IdP:
AssertionConsumerServiceURL="https://cisaml.XXX.com/simplesaml/module.php/saml/sp/saml2-acs.php/CI"
- But what is in the authsources.php:
'AssertionConsumerService' => 'https://192.168.xx.yyy/simplesaml/module.php/saml/sp/saml2-acs.php/CI'
AssertionConsumerServiceURL="https://cisaml.XXX.com/simplesaml/module.php/saml/sp/saml2-acs.php/CI"
- But what is in the authsources.php:
'AssertionConsumerService' => 'https://192.168.xx.yyy/simplesaml/module.php/saml/sp/saml2-acs.php/CI'
Doesn't the information in the authsources.php control the requests that SimpleSAMLphp sends out to the IdP??
Is there some way that the ACS in the actual request could be different than what is authsources.php??
Thanks,
Jim
Peter Schober
Oct 10, 2021, 6:29:43 AM10/10/21
to SimpleSAMLphp
* o haya <ohay...@gmail.com> [2021-10-10 10:26]:
> What about the rest of the ACS URL? Where (which config file, etc.)
> does that come from??
You mean the simplesaml/module.php/... part?
The endpoints are what they are and come from the code.
There should be no need to ever change them.
> The main reason that I stood up the "new" test SimpleSAMLphp instance that
> I just stood up (see 2 threads before this one) was because I was hoping I
> could test what would happen if I changed the ACS coming from SimpleSAMLphp
> (we cannot change the original SimpleSAMLphp config "officially" until we
> know the fix, for sure), BUT, this new instance is running on a different
> machine, which has a different hostname, so when I look at the requests
> received by the IdP, the ACS in those requests have the hostname of my new
> machine :(... so maybe standing up the new instance is not going to be
> useful for testing?
Here's one way to do that:
Configure the test instance identically to the prod instance, e.g. by
cloning the whole VM or otherwise by making sure all the relevant
parameters are the same, including using the prod instance's host name
in SSP's 'baseurlpath', its key material used for SAML (when you're
encrypting SAML to the SP[1]), possibly its TLS web server key pair
(in case you can't get around certificate warnings/errors in your web
browser when using an invalid TLS certificate instead), and likely
also as ServerName or ServerAlias in your Apache httpd configuration.
Then put the IP address of the test instance into your own PC's hosts
file -- see https://en.wikipedia.org/wiki/Hosts_(file) -- but with the
prod instance's host name.
That way the web browser on your own machine would always access the
test instance when you'd enter (or be redirected) to the prod
instance.
(Of course while that "DNS override" in your host file is
active/present you can't access the real prod instance from that same
PC. So you can easily confuse yourself that way. Probably best to
change the theme/design on the test instance to make it very, very
clear visually that this is not in fact the prod IDP, even if URL and
certificate all say it is.)
> The thing that REALLY puzzles me at this point is if I look at the
> /var/simplesamlphp/config/authsources.php, in that "CI" configuration, the
> ACS value has an IP address in it rather than a hostname:
I see from the documentation that having 'AssertionConsumerService'
configuration parameters in authsources.php is allowed:
https://simplesamlphp.org/docs/stable/saml:sp#section_4
but I've never had a need to use those. Why would you have those there?
> Is there some way that the ACS in the actual request could be
> different than what is authsources.php??
Not sure that's what you're asking or want to hear but unless you have
told the IDP that SAML authn requests from the prod) SP will always be
signed (which is unlikely and usually also isn't a good idea) you can
send anything you want to the IDP, using any method you want, from
anywhere you want, including not involving the SP at all.
It's just a piece of XML you send to the IDP (encoded as required by
the specification) via any of the IDP's accepted protocol bindings
(HTTP-Redirect or HTTP-POST).
-peter
[1] https://simplesamlphp.org/docs/stable/simplesamlphp-sp#section_1_1
> I worked with SimpleSAMLphp for a very short time, awhile ago, and I
> vaguely recall that at least PART of the ACS value is from the actual
> hostname where SimpleSAMLphp is running.
See 'baseurlpath' in SSP's config.php and the comments above.
> vaguely recall that at least PART of the ACS value is from the actual
> hostname where SimpleSAMLphp is running.
> What about the rest of the ACS URL? Where (which config file, etc.)
> does that come from??
The endpoints are what they are and come from the code.
There should be no need to ever change them.
> The main reason that I stood up the "new" test SimpleSAMLphp instance that
> I just stood up (see 2 threads before this one) was because I was hoping I
> could test what would happen if I changed the ACS coming from SimpleSAMLphp
> (we cannot change the original SimpleSAMLphp config "officially" until we
> know the fix, for sure), BUT, this new instance is running on a different
> machine, which has a different hostname, so when I look at the requests
> received by the IdP, the ACS in those requests have the hostname of my new
> machine :(... so maybe standing up the new instance is not going to be
> useful for testing?
Configure the test instance identically to the prod instance, e.g. by
cloning the whole VM or otherwise by making sure all the relevant
parameters are the same, including using the prod instance's host name
in SSP's 'baseurlpath', its key material used for SAML (when you're
encrypting SAML to the SP[1]), possibly its TLS web server key pair
(in case you can't get around certificate warnings/errors in your web
browser when using an invalid TLS certificate instead), and likely
also as ServerName or ServerAlias in your Apache httpd configuration.
Then put the IP address of the test instance into your own PC's hosts
file -- see https://en.wikipedia.org/wiki/Hosts_(file) -- but with the
prod instance's host name.
That way the web browser on your own machine would always access the
test instance when you'd enter (or be redirected) to the prod
instance.
(Of course while that "DNS override" in your host file is
active/present you can't access the real prod instance from that same
PC. So you can easily confuse yourself that way. Probably best to
change the theme/design on the test instance to make it very, very
clear visually that this is not in fact the prod IDP, even if URL and
certificate all say it is.)
> The thing that REALLY puzzles me at this point is if I look at the
> /var/simplesamlphp/config/authsources.php, in that "CI" configuration, the
> ACS value has an IP address in it rather than a hostname:
configuration parameters in authsources.php is allowed:
https://simplesamlphp.org/docs/stable/saml:sp#section_4
but I've never had a need to use those. Why would you have those there?
> Is there some way that the ACS in the actual request could be
> different than what is authsources.php??
told the IDP that SAML authn requests from the prod) SP will always be
signed (which is unlikely and usually also isn't a good idea) you can
send anything you want to the IDP, using any method you want, from
anywhere you want, including not involving the SP at all.
It's just a piece of XML you send to the IDP (encoded as required by
the specification) via any of the IDP's accepted protocol bindings
(HTTP-Redirect or HTTP-POST).
-peter
[1] https://simplesamlphp.org/docs/stable/simplesamlphp-sp#section_1_1
o haya
Oct 10, 2021, 11:12:12 AM10/10/21
to SimpleSAMLphp
On Sunday, October 10, 2021 at 6:29:43 AM UTC-4 Peter Schober wrote:
* o haya [2021-10-10 10:26]:
> I worked with SimpleSAMLphp for a very short time, awhile ago, and I
> vaguely recall that at least PART of the ACS value is from the actual
> hostname where SimpleSAMLphp is running.
See 'baseurlpath' in SSP's config.php and the comments above.
By the above did you mean in the "/var/simplesamlphp/config/config.php" file?
If so, this is what is currently in there:
/*
* Setup the following parameters to match your installation.
* See the user manual for more details.
*/
/*
* baseurlpath is a *URL path* (not a filesystem path).
* A valid format for 'baseurlpath' is:
* [(http|https)://(hostname|fqdn)[:port]]/[path/to/simplesaml/]
*
* The full url format is useful if your SimpleSAMLphp setup is hosted behind
* a reverse proxy. In that case you can specify the external url here.
*
* Please note that SimpleSAMLphp will then redirect all queries to the
* external url, no matter where you come from (direct access or via the
* reverse proxy).
*/
'baseurlpath' => '/simplesaml/',
// Changed the above 20180322 from 'simplesaml/' to '/simplesaml/'
/*
* The 'application' configuration array groups a set configuration options
* relative to an application protected by SimpleSAMLphp.
*/
//'application' => array(
/*
* The 'baseURL' configuration option allows you to specify a protocol,
* host and optionally a port that serves as the canonical base for all
* your application's URLs. This is useful when the environment
* observed in the server differs from the one observed by end users,
* for example, when using a load balancer to offload TLS.
*
* Note that this configuration option does not allow setting a path as
* part of the URL. If your setup involves URL rewriting or any other
* tricks that would result in SimpleSAMLphp observing a URL for your
* application's scripts different than the canonical one, you will
* need to compute the right URLs yourself and pass them dynamically
* to SimpleSAMLphp's API.
*/
//'baseURL' => 'https://example.com'
//),
so that setting is JUST:
* Setup the following parameters to match your installation.
* See the user manual for more details.
*/
/*
* baseurlpath is a *URL path* (not a filesystem path).
* A valid format for 'baseurlpath' is:
* [(http|https)://(hostname|fqdn)[:port]]/[path/to/simplesaml/]
*
* The full url format is useful if your SimpleSAMLphp setup is hosted behind
* a reverse proxy. In that case you can specify the external url here.
*
* Please note that SimpleSAMLphp will then redirect all queries to the
* external url, no matter where you come from (direct access or via the
* reverse proxy).
*/
'baseurlpath' => '/simplesaml/',
// Changed the above 20180322 from 'simplesaml/' to '/simplesaml/'
/*
* The 'application' configuration array groups a set configuration options
* relative to an application protected by SimpleSAMLphp.
*/
//'application' => array(
/*
* The 'baseURL' configuration option allows you to specify a protocol,
* host and optionally a port that serves as the canonical base for all
* your application's URLs. This is useful when the environment
* observed in the server differs from the one observed by end users,
* for example, when using a load balancer to offload TLS.
*
* Note that this configuration option does not allow setting a path as
* part of the URL. If your setup involves URL rewriting or any other
* tricks that would result in SimpleSAMLphp observing a URL for your
* application's scripts different than the canonical one, you will
* need to compute the right URLs yourself and pass them dynamically
* to SimpleSAMLphp's API.
*/
//'baseURL' => 'https://example.com'
//),
so that setting is JUST:
'baseurlpath' => '/simplesaml/',
What I was asking about/am puzzled about, is that, in the authsources.php, for that 'CI' part of the configuration, there is this:
'AssertionConsumerService' => 'https://192.168.xx.yy/simplesaml/module.php/saml/sp/saml2-acs.php/CI',
But when I look at the logging on the IdP server side, I see that the IdP is RECEIVING something different in the incoming request that it is getting from (I think) SimpleSAMLphp:
AssertionConsumerServiceURL="https://cisaml.zzzz.com/simplesaml/module.php/saml/sp/saml2-acs.php/CI"
I am trying to understand WHY what is in the ACS in the request that the IdP is apparently receiving is DIFFERENT than what is configured in the SimpleSAMLphp "authsources.php"?
Where (in which config file, etc.) in the SimpleSAMLphp configuration is causing the ACS in the request that is being actually sent to the IdP to have the IP address in the ACS?
Earlier in this message (above this) you had mentioned the baseurlpath parameter in the config.php. As I responded above, that parameter is currently:
'baseurlpath' => '/simplesaml/',
Is that because that 'baseurlpath' is only including the URI part ("
/simplesaml/
"), and not including the "https:" part and the hostname and port parts, so then SimpleSAMLphp is then defaulting to using the '"https:" + <FQDN hostname of the machine>' on which SimpleSAMLphp is running in the ACS in the request that SimpleSAMLphp is sending to the "CI" IdP?
-peter
[1] https://simplesamlphp.org/docs/stable/simplesamlphp-sp#section_1_1
o haya
Oct 10, 2021, 12:22:14 PM10/10/21
to SimpleSAMLphp
Hi,
I think I was able to figure out:
- It looks like if the baseurlpath in the config.php has just the URI part, then SimpleSAMLphp is using the FQDN/hostname of the machine that is hosting the SimpleSAMLphp in the address in the ACS URL.
- I have been able to cause the ACS in the request to use the IP, by using that/hardcoding that in the baseurlpath
That made the ACS in the request ALMOST match the expected one in the IdP, but it looks like the ending part is different :(!!!
(don't ask ME why, I did not setup this thing in the first place ;)!! ).
Am trying to figure out what to do about that. I am guessing I could fix/hack that in the config.php also, but I am not 100% sure that doing that is the "correct" fix... This one may need to wait until tomorrow until I can talk to the "owner" of this problem to get more information about what they think SHOULD be happening...
Thanks,
Jim
o haya
Oct 10, 2021, 1:08:05 PM10/10/21
to SimpleSAMLphp
Hi,
I went ahead and tried to change the AssertionConsumerServiceURL in the authsources.php from the "saml2-acs.php" to "saml1-acs.php", and restarted the Apache, but that didn't seem to fix the problem.
HOWEVER, then I put the
AssertionConsumerServiceURL in the authsources.php back to original and restarted Apache again, but NOW, it looks like I am not getting any logging at all in the SimpleSAML "log/simplesamlphp.log" file.
I am also not seeing any msgs on the IdP server side that have AssertionConsumer in them :(...
Also, I think that in the browser I am seeing an Unhandled Exception page:
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 have restarted the Apache multiple times but still nothing in the simplesamlphp.log anymore :(!!
Jim
o haya
Oct 10, 2021, 1:15:24 PM10/10/21
to SimpleSAMLphp
BTW, I checked/tested with the original SimpleSAMLphp machine and when I test using that one, I do see msgs with the ACS in them still.
So there is something wrong only with MY SimpleSAMLphp instance now :(...
Tim van Dijen
Oct 10, 2021, 1:28:02 PM10/10/21
to simple...@googlegroups.com
Any changes to the authsources.php will not have any effect until you exchange metadata with your IDP again...
I really wonder why you're making this so hard for yourself with compiling Apache, running on a non-default user, installing in non-default locations, non-default HTTPS-port when you already said yourself you don't have much experience...
- Tim
Op 10-10-2021 om 19:08 schreef o haya:
--
This is a mailing list for users of SimpleSAMLphp, not a support service. If you are willing to buy commercial support, please take a look here:
https://simplesamlphp.org/support
Before sending your question, make sure it is related to SimpleSAMLphp, and not your web server's configuration or any other third-party software. This mailing list cannot help with software that uses SimpleSAMLphp, only regarding SimpleSAMLphp itself.
Make sure to read the documentation:
https://simplesamlphp.org/docs/stable/
If you have an issue with SimpleSAMLphp that you cannot resolve and reading the documentation doesn't help, you are more than welcome to ask here for help. Subscribe to the list and send an email with your question. However, you will be expected to comply with some minimum, common sense standards in your questions. Please read this carefully:
http://catb.org/~esr/faqs/smart-questions.html
---
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 view this discussion on the web visit https://groups.google.com/d/msgid/simplesamlphp/ef0f2207-32f1-4149-bca9-0c8c9d97bd47n%40googlegroups.com.
o haya
Oct 10, 2021, 1:29:36 PM10/10/21
to SimpleSAMLphp
Also, I just did an md5sum on the authsources.php on both the original machine and my new cloned machine and both had the same md5sum, so I am 100% sure that the authsources.php on my machine has not change from the original, so what could be causing my SimpleSAMLphp instance to no longer be logging to log/simplesamlphp.log?
:(...
Jim
Tim van Dijen
Oct 10, 2021, 1:49:00 PM10/10/21
to simple...@googlegroups.com
It's not logging because you're hitting a PHP fatal error which
is only logged on Apache-level..
You can probably find it back in /var/log/messages.
- Tim
Op 10-10-2021 om 19:29 schreef o haya:
--
This is a mailing list for users of SimpleSAMLphp, not a support service. If you are willing to buy commercial support, please take a look here:
https://simplesamlphp.org/support
Before sending your question, make sure it is related to SimpleSAMLphp, and not your web server's configuration or any other third-party software. This mailing list cannot help with software that uses SimpleSAMLphp, only regarding SimpleSAMLphp itself.
Make sure to read the documentation:
https://simplesamlphp.org/docs/stable/
If you have an issue with SimpleSAMLphp that you cannot resolve and reading the documentation doesn't help, you are more than welcome to ask here for help. Subscribe to the list and send an email with your question. However, you will be expected to comply with some minimum, common sense standards in your questions. Please read this carefully:
http://catb.org/~esr/faqs/smart-questions.html
---
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 view this discussion on the web visit https://groups.google.com/d/msgid/simplesamlphp/99de242f-11d7-44b0-881e-a274f3bd38can%40googlegroups.com.
o haya
Oct 10, 2021, 2:08:22 PM10/10/21
to SimpleSAMLphp
Hi Tim et al,
I was just able to get it back to the state before and it is logging again now.
What I did that got it working again, was to undo the change that I had made in the config/config.php to the "baseurlpath", where I had made the baseurlpath like "https://192.168.xx.yy/simplesaml" rather the original "/simplesaml/".
Why would that have fixed it?
Also it is weird that it WAS working for awhile AFTER I had change that to the URL with the 'https://.../simplesaml", then suddenly stopped logging. It was like it was caching the old signature or something???
Also, if changing the baseurlpath in config.php causes the signature error, then how can I change the baseurlpath without getting the signature error problem?
Thanks,
Jim
Tim van Dijen
Oct 10, 2021, 2:20:49 PM10/10/21
to SimpleSAMLphp
Changing the baseurl is not causing the signature validation error... I really don't see how..
It's more likely that messing with the ACS-url in authsources.php causes this and I'm still unsure what you're trying to achieve there..
- tim
Op zondag 10 oktober 2021 om 20:08:22 UTC+2 schreef ohay...@gmail.com:
o haya
Oct 10, 2021, 2:35:22 PM10/10/21
to SimpleSAMLphp
Hi Tim,
When I look at what is being sent to the IdP, the ending part of the ACS URL in that request was different than the SP metadata that the IdP has for the SimpleSAMLphp SP. The reason why I was trying to change the AssertionConsumerService param in the authsources.php was to try to get the ACS URL in the request to match the SP metadata that the IdP has.
NOTE THAT THIS WAS JUST SO THAT I COULD *TEMPORARILY* TEST "my theory" about the problem that we've been having.
And, for AWHILE at least it seemed like changing the "authsources.php" DID change the ending part, until I started getting that signature error.
So that is what I asked about just above here... is there another way to test temporarily adjust that ending part so it matches SP metadata in the IdP?
I do think that the CORRECT solution is to re-export the SP metadata from SimpleSAMLphp, and then import that new SP metadata into the IdP, but I asked for that from the IdP system "owner" late last week, but haven't heard back yet, so, meanwhile, I wanted to do as much as I could to confirm that that (export and then import) was the CORRECT solution.
Thanks,
Jim
Tim van Dijen
Oct 10, 2021, 2:42:40 PM10/10/21
to simple...@googlegroups.com
Ah, yeah that should be fine to work around and test your
theory..
The thing that triggered me earlier was something you said about
changing the saml2-acs.php to saml1-acs.php and that made zero
sense to me..
- Tim
Op 10-10-2021 om 20:35 schreef o haya:
To view this discussion on the web visit https://groups.google.com/d/msgid/simplesamlphp/b8fe2c88-3c77-4862-93f8-0c315e3c178en%40googlegroups.com.
Peter Schober
Oct 11, 2021, 3:26:34 AM10/11/21
to SimpleSAMLphp
* Peter Schober <peter....@univie.ac.at> [2021-10-10 12:29]:
Since *all* of your problems so far seem to stem from being unable to
re-create the snowflake that is your current prod server:
Have you tried the above suggestion of cloning the complete prod
server and then doing whatever you're actually trying to do (which is
NOT learning how to rebuild the prod server, AFAIK, but debug some
problem the prod server is having) on that clone?
(The only change on a cloned VM might be the IP address and possibly
the MAC address on the relevant ethernet interface.)
-peter
> Configure the test instance identically to the prod instance, e.g. by
> cloning the whole VM or otherwise by making sure all the relevant
> parameters are the same [...]
> cloning the whole VM or otherwise by making sure all the relevant
Since *all* of your problems so far seem to stem from being unable to
re-create the snowflake that is your current prod server:
Have you tried the above suggestion of cloning the complete prod
server and then doing whatever you're actually trying to do (which is
NOT learning how to rebuild the prod server, AFAIK, but debug some
problem the prod server is having) on that clone?
(The only change on a cloned VM might be the IP address and possibly
the MAC address on the relevant ethernet interface.)
-peter
Reply all
Reply to author
Forward
0 new messages