IDPv3.3 and programmatically selecting MFA based on attribute

[Jeffrey Eaton]

Ah, great.  I just found the reference to CanonicalUsernameLookupStrategy in another thread but was struggling with the syntax on how to call it from within the script.  I've updated my script and I believe that I have everything working properly now.

I also went ahead and updated the Wiki example on https://wiki.shibboleth.net/confluence/display/IDP30/MultiFactorAuthnConfiguration under "Programmatically Selecting Flows" to use this lookup method instead of the previous SubjectCanonicalizationContext method to hopefully save someone else in the future.

-jeaton

On Jan 24, 2017, at 9:04 AM, Scott Koranda <skoranda at gmail.com<mailto:skoranda at gmail.com>> wrote:

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<mailto: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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170124/1ac44456/attachment-0001.html>