Duo OIDC plugin Issue

[Cantor, Scott]

On 3/16/22, 12:12 PM, "users on behalf of Jason Rotunno via users" <users-bounces at shibboleth.net on behalf of users at shibboleth.net> wrote:
>  If anyone wants to point me to where I can read up to get a better handle on it, it would be appreciated.

Primarily you need to read the standard and understand what an AuthnContext and an AuthnContextClassReference are, and how they're used to request and respond regarding specific authentication requirements.

OIDC's version of the same thing is the acr claim (that's nothing to do with the OIDC underneath Duo's UP, I'm just saying most protocols have the concept).

Shibboleth uses the Java Principal abstraction, which is very generic, to model all this by attaching subclasses of Principal to things. The supportedPrincipals settings scattered all over the configuration are what teaches the software what it's supposed to do when it gets requests for specific values.

These values are identifiers. You don't make them up or change them randomly, they mean what they mean and they apply only when they apply. If your Duo deployment supports the REFEDS MFA profile, then its identifier is a supported or supportable Principal value, and if an SP requests it, it will work.

If your deployment didn't support the profile, you MUST NOT claim that it does. Fortunately, there's so little at present in the profile that it's hard not to support it. That may or may not always be true.

An IdP's most important outward facing job is to tell the truth. Failure is not untrue if it's warranted. If somebody requests X.509 authentication and your IdP is supporting password and Duo authentication, you don't just make it work by randomly adding a value. You fail. That's extremely important.

-- Scott