Giving an SP the authnContextClassRef they asked for

[Wessel, Keith]

You're referring to this from the SAML2.SSO default configuration?

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

Seems like I could just make a new map then override the defaultAuthenticationMethodsLookupStrategy for this specific RP using the same class but passing in my map as a parameter. Is that the idea?

Doesn't look like a job for a metadata-driven configuration, mind you, but still pretty straightforward.

I still think you're right that dealing with any explicit request for PPT in a global manner isn't a bad idea.

Keith

-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Cantor, Scott
Sent: Thursday, January 13, 2022 3:19 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: Giving an SP the authnContextClassRef they asked for

On 1/13/22, 4:06 PM, "users on behalf of Wessel, Keith" <users-bounces at shibboleth.net on behalf of kwessel at illinois.edu> wrote:

>    Before, you mentioned shibboleth.principalProxyRequestMappings map 
> which applies globally. I'm still not clear if there's something I 
> could apply to a specific relying party. Can that map be overridden for a specific RP? Sorry if you said this and I'm missing it.

What I posted earilier is the bean that is defaulted into the SAML2.SSO bean to determine the defaultAuthenticationMethods setting that everybody inherits from.

That class does nothing for non-proxied uses. It only produces something when proxying happens, and the defaultAuthenticationMethods setting is what gets queried when proxying to determine the outbound RequestedAuthnContext element.

If you define a copy of that to inject into a specific relying party child of the SAML2.SSO profile bean that injects a different map bean into that strategy property, that's a custom mapping that just shares the same Java implementation to perform the mapping logic but would use a different map.

So yes, you can do it, it just isn't talked about or documented particularly and I never thought about it. The class itself is in the API, I checked, so it's not going to break without some kind of warning.

-- Scott


--
For Consortium Member technical support, see https://urldefense.com/v3/__https://shibboleth.atlassian.net/wiki/x/ZYEpPw__;!!DZ3fjg!sWle6oRPekYupY2w_1Mmn3bB20bnw6udyb0u1t_wWdPBCk1HyKAOWivufYGnFPhGHg$
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net