3:31 p.m.
Hi all,
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. The problem is that the SAML2
backend always selects the first ACS address in the request
(src/satosa/backends/saml2.py:289).
I'd like to select the ACS URL based on the host name of the request
(context["http_headers"]["HTTP_HOST"] specifically). What do you think
about it? Would you consider such a pull request?
I'm still not entirely sure what to do if there's no match. I guess
Shibboleth SP used to specify the ACS URL in the AuthnRequest using
information from HTTP_HOST(?), since I remember seeing error messages on
IdPs when no AssertionConsumerServiceURLs in the metadata matched the
request. Even if I remember right, this might not be the best approach,
because I could think that it'd be more user friendly if SATOSA could
signal the error instead of the IdP, but this might be use case
dependent.
Thanks,
Kristof
6:08 p.m.
2022-09-06 15:31 időpontban Kristof Bajnok ezt írta:
I'd like to select the ACS URL based on the host
name of the request
(context["http_headers"]["HTTP_HOST"] specifically). What do you
think
about it? Would you consider such a pull request?
I'm still not entirely sure what to do if there's no match. I guess
Shibboleth SP used to specify the ACS URL in the AuthnRequest using
information from HTTP_HOST(?), since I remember seeing error messages
on IdPs when no AssertionConsumerServiceURLs in the metadata matched
the request. Even if I remember right, this might not be the best
approach, because I could think that it'd be more user friendly if
SATOSA could signal the error instead of the IdP, but this might be
use case dependent.
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.
Kristof
6:38 p.m.
Hello Kristof,
for those that haven't noticed, there is a PR about this here:
https://github.com/IdentityPython/SATOSA/pull/409
On Tue, 6 Sept 2022 at 16:31, Kristof Bajnok <kristof(a)bajnok.hu> wrote:
Hi all,
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. The problem is that the SAML2
backend always selects the first ACS address in the request
(src/satosa/backends/saml2.py:289).
I'd like to select the ACS URL based on the host name of the request
(context["http_headers"]["HTTP_HOST"] specifically). What do you
think
about it? Would you consider such a pull request?
I think this is interesting. I feel that, in a way, this is
approaching a lightweight/shared "multi-tenant" setup. The entityID
and probably the internal processing are shared, but then you are
separating what entities can use the endpoints based on the
domain/netloc.
I'm still not entirely sure what to do if
there's no match. I guess
Shibboleth SP used to specify the ACS URL in the AuthnRequest using
information from HTTP_HOST(?), since I remember seeing error messages on
IdPs when no AssertionConsumerServiceURLs in the metadata matched the
request. Even if I remember right, this might not be the best approach,
because I could think that it'd be more user friendly if SATOSA could
signal the error instead of the IdP, but this might be use case
dependent.
The IdP must ensure that the AssertionConsumerServiceURL actually
belongs to the SP. There is no one way to do this. One way of doing
it, is by comparing the value to the metadata of the SP. Another way
is to trust the given value because the AuthnRequest is signed with
the SP's key.. etc.
On Wed, 7 Sept 2022 at 19:08, Kristof Bajnok <kristof(a)bajnok.hu> wrote:
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?
Cheers,
--
Ivan c00kiemon5ter Kanakarakis >:3
3:26 p.m.
Hi Ivan,
thanks for your comments, I completely agree.
2022-09-22 18:38 időpontban Ivan Kanakarakis ezt írta:
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
> 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?
12:12 a.m.
Hello,
On Fri, 23 Sept 2022 at 16:26, Kristof Bajnok <kristof(a)bajnok.hu> wrote:
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?
I have not thought about it much, but it will definitely need access to
- the context (context) to access headers and any other runtime state
- the backend config (self.config) to access any other configuration it may need
- the entityid of the issuer (entity_id) to base decisions on that
- and then probably the sp or the sp-configuration, through which you
can query the metadata (with self.sp.metadata or
self.sp.config.metadata)
- and it should return the chosen binding
So, this hook/plugin will have plenty of information to pick the right
binding. Given the passed objects are mutable, it could also mess with
the internals but hopefully people will nudge us to add more hooks
specifically for what they need instead of abusing this hook.
Cheers,
--
Ivan c00kiemon5ter Kanakarakis >:3
901
days inactive
918
days old
4 comments
2 participants
participants (2)
-
Ivan Kanakarakis -
Kristof Bajnok