Giving an SP the authnContextClassRef they asked for
kwessel at illinois.edu
Thu Jan 13 22:30:48 UTC 2022
You're referring to this from the SAML2.SSO default configuration?
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.
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.
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
More information about the users