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