IDPv3.3 and programmatically selecting MFA based on attribute

[Scott Koranda]

Hi,

You can try something like this:

logger = Java.type("org.slf4j.LoggerFactory").getLogger("net.shibboleth.idp");

// Determine the username 
usernameLookupStrategyClass = Java.type("net.shibboleth.idp.session.context.navigate.CanonicalUsernameLookupStrategy");
usernameLookupStrategy = new usernameLookupStrategyClass();
username = usernameLookupStrategy.apply(input);
logger.debug("{} username is {}", logPrefix, username);

// Resolve isMemberOf attribute for the authenticated user.
resCtx = input.getSubcontext("net.shibboleth.idp.attribute.resolver.context.AttributeResolutionContext", true);
resCtx.setPrincipal(username);
resCtx.getRequestedIdPAttributeNames().add("isMemberOf");
resCtx.resolveAttributes(custom);

That class to find the username is new in 3.3.

The above assumes Nashorn.

Scott K


> Hmm, close but not entirely there yet.
> 
> I am occasionally, but not consistently, getting the following error:
> 
> java.lang.RuntimeException: javax.script.ScriptException: TypeError: null has
> no such function "getPrincipalName" in <eval> at line number 10
> 
> which corresponds to:
> 
> resCtx.setPrincipal(input.getSubcontext(
>                      
>   "net.shibboleth.idp.authn.context.SubjectCanonicalizationContext").getPrincipalName
> ());
> 
> so the SubjectCanonicalizationContext is coming back as null.  It seems to only
> happen on a second trip through the IDP, when the first trip only used the
> first factor (auth/Password, using the stock JAAS password, backed against Krb5
> if that matters at all).
> 
> The script I am using is exactly the one from the Wiki under "Conditional use
> of two factors" with authn/Password for Flow1, authn/Duo for Flow2, and the
> attribute name and value changed to eduPersonAssurance and
> "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport"
> respectively (my eduPersonAssurance returns either that, or our custom Duo
> contact class of https://login.cmu.edu/duo )
> 
> Any ideas?  Is there a way to do any additional logging from the inline script
> to see why that context would be null?
> 
> -jeaton
> 
> 
>     On Jan 22, 2017, at 9:54 PM, Scott Koranda <skoranda at gmail.com> wrote:
> 
> 
>             Why is it just accepting the previous Password
>             authentication and not checking the attribute (and then
>             upgrading to Duo)?
> 
> 
> 
>         This was covered in the past few days in another thread with
>         the subject "MFA result reuse with Duo". You can find where it
>         begins at
> 
>         http://marc.info/?l=shibboleth-users&m=148476673200662&w=2
> 
>         In short: 
> 
>         Since the SP does not request a "MFA context" and you
>         have not configured an override for that SP that requires an
>         "MFA context", the IdP determines that your active authn/MFA flow
>         result with the Password context satisifes the request. As
>         such it does not re-run the authn/MFA flow and your strategy
>         script never gets the chance to execute a second time for that
>         user.
> 
>         You can change that behavior by setting
> 
>         idp.authn.favorSSO = false
> 
>         in idp.properties and then adding
> 
>         <property name="defaultAuthenticationMethods">
>          <list>
>            <ref bean="MfaPrincipal" />
>            <ref bean="PasswordPrincipal" />
>          </list>
>         </property>
> 
>         to either an override for that particular SP or to the
>         DefaultRelyingParty
>         in relying-party.xml, where
> 
>         <bean id="MfaPrincipal" parent="shibboleth.SAML2AuthnContextClassRef" 
>          c:classRef="https://refeds.org/profile/mfa" />
> 
>         <bean id="PasswordPrincipal" parent=
>         "shibboleth.SAML2AuthnContextClassRef" 
>          c:classRef=
>         "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport" />
> 
>         (replace 'https://refeds.org/profile/mfa' with whatever you have
>         configured your IdP to use as the MFA context).
> 
>         The order above is important--the "MfaPrincipal" must be first.
> 
>         With those changes, the IdP will run the authn/MFA flow if the user
>         only has
>         an active Password result.
> 
> 
> 
>     I have attempted to write this up. On this page
> 
>     https://wiki.shibboleth.net/confluence/display/IDP30/
>     MultiFactorAuthnConfiguration
> 
>     see the section "Reuse of the Entire authn/MFA Flow Result (Or
>     When Is a MFA Next Flow Strategy Executed?)"
> 
>     Note that Scott Cantor has not had a chance to review the text
>     yet.
> 
>     The technical details, however, have been verified by at least
>     one other deployer (Josh O'Dowd) so it should work.
> 
>     If you have any comments on the text please let me know, or
>     feel free to edit it yourself (it is, after all a wiki...)
> 
>     Thanks,
> 
>     Scott K
> 
>