IDPv3.3 and programmatically selecting MFA based on attribute

[Jeffrey Eaton]

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/3a797056/attachment-0001.html>