Giving an SP the authnContextClassRef they asked for
cantor.2 at osu.edu
Thu Jan 13 19:01:55 UTC 2022
My point is....what big problem do you create by treating any SP requesting this as a request for MFA? How many SPs are requesting PPT and when would that NOT be a bug? I think you're solving for a non-problem really.
On 1/13/22, 1:47 PM, "users on behalf of Wessel, Keith" <users-bounces at shibboleth.net on behalf of kwessel at illinois.edu> wrote:
> Now that I'm no longer using a second factor script, that's no longer an option.
You could re-add such a script into the steps you're following.
> Is there any way to work around this until the vendor gets a clue? Can I map acrs for a specific relying party?
> Or can I create a translation strategy bean and associate it with this SP to essentially translate requests of PPT
> into MFA?
You could instantiate a dedicated copy of the class that's used internally with the map structure and inject a dedicated map into that copy. Then inject that bean into the slot in the relying party override. That's wiring, but no custom code.
The default wiring is:
Do that but with a different p:mappings source and you get per-RP mappings.
More information about the users