Giving an SP the authnContextClassRef they asked for

Cantor, Scott cantor.2 at
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 on behalf of kwessel at> 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:

        <property name="defaultAuthenticationMethodsLookupStrategy">
            <bean class="net.shibboleth.idp.saml.saml2.profile.config.navigate.ProxyAwareDefaultAuthenticationMethodsLookupFunction"
                p:mappings="#{getObject('shibboleth.PrincipalProxyRequestMappings')}" />        

Do that but with a different p:mappings source and you get per-RP mappings.

-- Scott

More information about the users mailing list