Giving an SP the authnContextClassRef they asked for

[Cantor, Scott]

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:

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

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

-- Scott