Data connector resolutionPhases
Pierre SAGNE
pierre.sagne at ac-orleans-tours.fr
Fri Oct 4 14:24:49 UTC 2024
Ok,
Thank you for the clarification.
So for now, there no case where it would work as intended, i guess.
Even if it doesn't work, though, can you give some examples of the step
names that were meant to be used inside these "resolutionPhases" parameters?
And although, is that the resolutionPhases filtering of data connectors
which doesn't work ? Or the whole activationConditionRef mechanism for
Data Connectors? Which would mean that excludeRelyingParties would not
work either?
Pierre Sagne.
Le 04/10/2024 à 14:40, Cantor, Scott a écrit :
>
> > I'm trying to figure what I should pass to the
>
> > resolutionPhases or excludeResolutionPhases parameter to
>
> > achieve this.
>
> This feature doesn't really work right because of some bugs and
> complexity due to the information needed to actually locate the
> information at runtime to enforce it.
>
> It only works for now if the AttributeResolutionContext is created in
> the place the IdP puts it, but oftentimes “special” cases need to
> stick it elsewhere to avoid collisions, and that breaks it right now.
> 5.2 should fix that limitation.
>
> If you wanted to use it for your MFA flow, then you’d have to make
> sure to create the resolution context directly under the PRC (and of
> course remove it to clean up) and you could set it to whatever you
> wanted really, and that would work ok to depend on it in your
> resolution and to exclude it in the IdP’s standard ones.
>
> I'm not likely to go in and adjust it all and define consistent rules
> for the labels until a major version change to V6 because of the
> potential to disrupt people’s systems. At that point I’ll get it
> defined every time we run the service and define the values used
> internally, which will typically be flow IDs, yes. I would probably
> use the fully qualified ones.
>
> I realize it’s a nice feature, and I’d like to fix it sooner, but I
> think stability of upgrades has to trump anything else.
>
> -- Scott
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20241004/fbc567e4/attachment.htm>
More information about the users
mailing list