IDPv3.3 and programmatically selecting MFA based on attribute

[Ho, PeiQuan]

Hi,

  I borrowed this script and have the same issue.  I noticed that when it tries to resolve the attribute during the "checkSecondFactor" step that the values need to resolve my eduPersonAssurance attribute is missing the values that it needs.

I run logic as the value of requestContext.getPeerEntityId(), but during the first attribute resolution, the value is null

2017-03-21 16:07:38,764 - INFO [edu.internet2.middleware.shibboleth.resolver.Script.eduPersonAssurance:13] - Getting eduPersonAssurance for: null -> USER

Any ideas why requestContext.getPeerEntityId() is null during the MFA second flow attribute resolver?

Thanks,
-PQ

-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Jeffrey Eaton
Sent: Sunday, January 22, 2017 8:40 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: IDPv3.3 and programmatically selecting MFA based on attribute

To follow up on my own post, I realized that SP-requested Duo wasn’t working properly because my MFA flow wasn’t stepping up in that case, but I was able to fix that by tweaking the checkSecondFactor script to more closely align with the example from the wiki:

                nextFlow = "authn/Duo"; 

                // Go straight to second factor if we have to, or set up for an attribute lookup first.
                authCtx = input.getSubcontext("net.shibboleth.idp.authn.context.AuthenticationContext");
                mfaCtx = authCtx.getSubcontext("net.shibboleth.idp.authn.context.MultiFactorAuthenticationContext");
                if (mfaCtx.isAcceptable()) {
                    // Attribute check is required to decide if first factor alone is enough.
                    resCtx = input.getSubcontext(
                        "net.shibboleth.idp.attribute.resolver.context.AttributeResolutionContext", true);
                    resCtx.setPrincipal(input.getSubcontext(
                        "net.shibboleth.idp.authn.context.SubjectCanonicalizationContext").getPrincipalName());
                    resCtx.getRequestedIdPAttributeNames().add("eduPersonAssurance");
                    resCtx.resolveAttributes(custom);
                    
                    // Check for an attribute that authorizes use of first factor.
                    attribute = resCtx.getResolvedIdPAttributes().get("eduPersonAssurance");
                    valueType =  Java.type("net.shibboleth.idp.attribute.StringAttributeValue");
                    if (attribute != null && attribute.getValues().contains(new valueType("urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport"))) {
                        nextFlow = null;
                    }
                    
                    input.removeSubcontext(resCtx);   // cleanup
                }
                
                nextFlow;   // pass control to second factor or end with the first

So this works for my cases for when the SP requests Duo by way of using our custom AuthnContextClassRef, but not in the case where there is an exiting Password-only IDP session, and I want the IDP to step-up to Duo based on the attribute lookup.  So close yet so far.

-jeaton
-- 
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net