Need help setting up Shibboleth 4.1 for MFA support for REFEDS/NIH

[Cantor, Scott]

On 7/28/21, 2:52 PM, "users on behalf of Murphy, Patrick" <users-bounces at shibboleth.net on behalf of murphyp1 at msu.edu> wrote:

>    We are installing a new Shibboleth 4.1.2 IdP.  We have it working with some of our existing sites that were
> migrated from V2.  I need to figure out how to setup the MFA component to convert the MFA attributes
> supplied by our Okta SSO solution into the required ones for REFEDS/NIH.  I am new to Shibboleth and the
> whole Spring beans configuration mechanism, so any pointers would be appreciated.

Normally the answer is that you would have to be using the SAML proxy support in 4.1 and then there's a feature to map AuthnContextClassRef values from the proxied IdP across the proxy boundary into some other value.

But Okta is not SAML compliant because they're misusing Attributes to carry information about the authentication step instead of AuthnContext. ADFS generally has a similar bug I believe. The IdP doesn't have any built-in code to support translating that. It requires Spring and Java expertise to build the code to do the mapping and plug it into the proxying layer to paper over the problem.

There's an extension point that was added in 4.1 to address this sort of need, but this is not "routine" stuff. You would need help building the logic to do this, and I don't know if there's anybody that's done an Attribute -> AuthnContext bridge yet who has code to share for that.

There's also the other direction...you'd have to be able to signal to Okta that you need MFA to happen if the SP asks. The only way you can avoid that is if the user population is always doing MFA regardless. But if that's true, you don't have as big a problem to begin with...you could just always ensure that every Okta result was mapped into the right value. So I doubt that's the case here.

And in that case...is there some reason to believe Okta even supports the standard sufficiently to honor those requests properly? I have no reason to think so. Few commercial products do.

On top of all this...are you actually using the proxying support at all? If you're doing something less functional like trying to use the RemoteUser or External login flows to integrate Okta, then there's a pretty good chance you can't do the request signaling at all.

This is way, way outside the free support boundary. I'm just trying to give you some of the general outlines of how difficult a problem this is. You're starting with Shibboleth 101 and asking about something that would take me time to work out how to deal with in conjunction with a lot of knowledge of the vendor system.

When you run two IdPs, you don't solve too many problems, you just create a new one.

Note that the HowTo I wrote that John mentioned isn't relevant, really. That's for people running Shibboleth alone, not people trying to use something else as the IdP and just running Shibboleth incidentally. I'll add something about that to it if it's not there now.

-- Scott