Order of events after a proxied authentication

[Wessel, Keith]

Circling back to this thread one more time.

We're still trying to find the best fix for some authnContextClassRef back-and-forth.

If I pass PPT through from the originating SP to Azure and the user is logged in with WindowsIntegratedAuth, Azure breaks. That's probably an Azure bug. At the least, Microsoft should prompt the user for password auth. Better yet, they might say that WindowsIntegratedAuth is more secure than password and thus also satisfies password, and so they could make everyone happy by returning what was requested.

So, I've taken to stripping requests for PPT (as well as straight password) from the authn request going to Azure using the PrincipalProxyRequestMappings. I was already doing this to translate the Refeds MFA context to nothing so that Microsoft didn't reject it. This fixes the windows integrated auth angle and, as long as the SP requests password and not PPT, doesn't break things for non-domain-joined machines where the user actually is using a password.

Microsoft, amusingly enough, returns password to the IdP when I do this. It won't allow password or PPT in the request to satisfy a condition with a user logged in with windows integrated auth, but it will return it.

But we still have a problem if the SP requests PPT. I'm trying to work around this until Microsoft fixes this (if they ever do). The problem is the IdP gets back password and says that it can't satisfy the request for PPT. We all know that there's seldom a good reason for an SP explicitly requesting PPT, or even password for that matter, but some misguided implementations still do.

So, I'm stuck. I get back password from Azure, but I need to tell the IdP that this satisfies PPT so that it can return PPT to the SP.

Do I need to manually code around this in the authn context translation strategy bean by checking what the SP requested and, if PPT, manually setting the authn context in the response to PPT? Or is there some plumbing somewhere in the IdP that lets me say password and PPT are equivalent, thus letting it automatically do the translation? I'd look at the authnComparisonRules, but of course one of the offending SPs not only requests PPT, but also requests an exact comparison.

Keith

-----Original Message-----
From: Wessel, Keith 
Sent: Friday, August 26, 2022 1:19 PM
To: Cantor, Scott <cantor.2 at osu.edu>; Shib Users <users at shibboleth.net>
Subject: RE: Order of events after a proxied authentication

Thanks, Scott. That helps a lot.

As soon as the beginning o the semester craziness is over, I plan to get us upgraded and take advantage of the bug fixes and enhancements you made to that translation strategy and the other various proxying improvements.

Keith


-----Original Message-----
From: Cantor, Scott <cantor.2 at osu.edu>
Sent: Friday, August 26, 2022 12:31 PM
To: Shib Users <users at shibboleth.net>
Cc: Wessel, Keith <kwessel at illinois.edu>
Subject: Re: Order of events after a proxied authentication

>    Does the principalProxyResponseMappings run first, then my 
> translationstrategy?

No. That map and the function that applies it is a "default" implementation of the original authnContextTranslationStrategy hook.

The one you had me add (the Ex one) runs first and if it adds Principals to the Subject, then the original hook doesn't run.

The order is:

1. Run Ex hook
2. If nothing added, run original hook
3. If nothing added, copy from the Response as a final option

See net.shibboleth.idp.saml.saml2.profile.impl.ValidateSAMLAuthentication, in the populateSubject method.

> And is the principal checked against the list of allowed principals 
> for the MFA flow at the end of that flow, and after all of these 
> mappings happen?

No. The suppotedPrincipals setting has to do with the system deciding whether to run flows, and it only comes into play otherwise when those "auto-add supported Principals" flags are set, which would not be the case here.

-- Scott