Giving an SP the authnContextClassRef they asked for
kwessel at illinois.edu
Wed Jan 12 21:18:29 UTC 2022
Ah-ha! Perhaps that's why this used to work with the internal authentication but doesn't any more. I'm not including PPT. I've got this entry in my helpers map that's being used to assignt eh authnContextClassRef if the ADFS response contains the claim stating that MFA was performed:
Can I just add a second bean to that list? And if so, is it better to use Password or PasswordProtectedTransport?
From: users <users-bounces at shibboleth.net> On Behalf Of Cantor, Scott
Sent: Wednesday, January 12, 2022 3:09 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: Giving an SP the authnContextClassRef they asked for
On 1/12/22, 3:47 PM, "users on behalf of Wessel, Keith" <users-bounces at shibboleth.net on behalf of kwessel at illinois.edu> wrote:
> Or do I need to create an authnContextTranslationStrategy bean that
> manually maps it back to urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport?
That, or change the shibboleth.IgnoredContexts bean to treat PasswordProtectedContext as ignored. That's a standards violation but that is a hook to do it. But it's global, you can't pick and choose. I have never run into an SP that wasn't Shibboleth that even knew how to check the value but that doesn't mean one doesn't exist.
Note that there's no reason why you shouldn't simply include PPT in your result. It doesn't hurt anything to do that as long as it's accurate, which I'm sure it is. The IdP will automatically use whatever is correct when it responds, it just needs to know that PPT is one of the contexts in the resulting Subject's Principal set.
For Consortium Member technical support, see https://urldefense.com/v3/__https://shibboleth.atlassian.net/wiki/x/ZYEpPw__;!!DZ3fjg!oCbirCTSrIBhFlEwj4C6P4mkQinvVxR4etC6AEyzdIUmBSNghltaNwjCnbJb6aOpVA$
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
More information about the users