Order of events after a proxied authentication

Wessel, Keith kwessel at illinois.edu
Thu Aug 25 22:37:17 UTC 2022

Hi, all, but mostly Scott,

We've got Microsoft handing back an acr of Unspecified (yes, with an upper-case U instead of the usual lower case, never mind that they're handing back Unspecified at all) in certain cases where users are domain-joined and thus not doing password authentication. This is causing problems in the rest of our IdP's plumbing, resulting in an UnsupportedRequest exception.

I'd like to know what order things are being evaluated in inside the IdP so I can see if I'm shooting myself in the foot..

I've got the SAML flow running as part of the MFA flow. I've added the urn:oasis:tc:SAML:2.0:ac:classes:Unspecified principal as an allowed principal for the MFA flow.

I've also attempted to add an entry to the shibboleth.PrincipalProxyResponseMappings map that maps Unspecified to password.

And I've got a translation strategy bean running to translate the claim that signals MFA was performed, if set, to the refeds MFA context. That part's working. We're only running into this error in specific cases for when MFA wasn't done. That bean, however, also copies the incoming acr from the proxy into the response if MFA wasn't performed. I think you made that no longer necessary in 4.2, if I recall. For now, though, we're doing this if the claim that signals MFA wasn't set in the incoming response:

                    if (samlCtx != null) {
                        var authnStatement = samlCtx.getAuthnStatement();

                        if (authnStatement != null) {
                            var Collections = Java.type("java.util.Collections");
                            var classRef = Java.type("net.shibboleth.idp.saml.authn.principal.AuthnContextClassRefPrincipal");

                            var acrObj = new classRef(authnStatement.getAuthnContext().getAuthnContextClassRef().getURI(
                            acr = Collections.singletonList(acrObj);

I'm wondering the order of events and if that last part is overwriting the work of the shibboleth.PrincipalProxyResponseMappings. Even if it is, the fact that I've added Unspecified to the allowed principals from the MFA flow should still be letting it through, albeit asserting Unspecified from my IdP which I'm not too keen on.

Does the principalProxyResponseMappings run first, then my translationstrategy? 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?

And I know you don't know the specifics of my increasingly complex IdP to make this proxying work, but if you can think of any other spots that I might be missing that are allowing Unspecified through, I'd welcome that.


More information about the users mailing list