Hi Ivan,
thanks for your comments, I completely agree.
2022-09-22 18:38 időpontban Ivan Kanakarakis ezt írta:
> in my setup, SATOSA may listen on multiple
interfaces/ports/vhosts,
> and
> not all are accessible to all users. Therefore when sending the
> authentication response, the IdPs must redirect the users to the
> 'correct' AssertionConsumerServiceURL.
[...]
I wish I could
omit the AssertionConsumerServiceUrl from the request
if
we know that the hostname does not match any of the ACS URLs, but
unfortunately PySaml's `create_auth_request` is not doing me the
favour
to treat `assertion_consumer_service_url=None` the same way as
`hide_assertion_consumer_service` *configuration* parameter was set.
But
in the end the IdP would most likely use the first suitable endpoint
in
this case, so it's not much worse to do the same in the request.
Right now, the fallback in the PR is the old behaviour - use the first
available ACS-URL. I think this is fine, but we could even implement
what you suggest here - fallback to hiding the ACS-URL and binding.
However, if you do this, the IdP will respond to the ACS-URL from the
SP's metadata that is marked with isDefault="true". It will not try to
match the ACS-URL that matches some domain, etc. To make it work, the
IdP should know only about the ACS-URL it should use, and that would
mean that you would be sharing multiple metadata documents for the
same entity (the proxy) - which I do not think is wrong, but not
common.
Do you think this would work some other way?
I don't think that we should encourage the use of supplying different
metadata for a single entity, and I think that falling back to the first
ACS URL is the easiest and a backwards-compatible solution.
In the PR ([1]) you requested that the ACS selection should be
implemented as a plugin call. At first I thought that this was too much
of a generalization, when the choice is between "use the first" or "use
the matching host". But then I realized that what one probably wants is
to prefer some bindings, such as Artifact, when available. But detecting
that the IdP supports Artifacts would require the access to the IdP
metadata (eg. the presence of an ArtifactResolutionService).
So I'm wondering what the right signature for that plugin would be, what
do you think?
Thanks,
Kristof
[1]:
https://github.com/IdentityPython/SATOSA/pull/409