MFA result reuse with Duo.
O'Dowd, Josh
Josh.O'Dowd at mso.umt.edu
Wed Jan 18 17:22:51 EST 2017
> configuring a relying party for a particular SP to "request"
"MFA" OR "Password" (in that order!) ...
Can this be done for a CAS RP in a RelyingPartyOverride? If so can you give a quick example snippet?
Josh
-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Scott Koranda
Sent: Wednesday, January 18, 2017 3:03 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: MFA result reuse with Duo.
> On 1/18/17, 4:46 PM, "users on behalf of Scott Koranda" <users-bounces at shibboleth.net on behalf of skoranda at gmail.com> wrote:
>
> > So you are suggesting that by setting
> >
> > idp.authn.favorSSO=false
> >
> > AND
> >
> > configuring a relying party for a particular SP to "request"
> > "MFA" OR "Password" (in that order!) then the IdP will see it has
> > an active "Password" but because idp.authn.favorSSO=false it will go
> > ahead and run the MFA flow?
>
> I was using Password and MFA as stand ins for context classes
> corresponding to the Password and Duo flows, but otherwise yes, I
> think so.
Understood, yes.
> The 2.x IdP had a semi-incorrect behavior such that it would
> prioritize SSO over processing the requested classes in order, which
> is technically not SAML compliant. 3.x doesn't promise to be totally
> strict but it does have this option to turn off that priority rule
> since I decided we should try and be more correct at least optionally.
>
> So what it does is check each requested Principal in sequence, and
> determine if it can be satisfied. If not, it looks for a flow to run
> that supports it. So I think it will run the MFA flow (which will
> support both/all of course) in such cases before it sees the second
> Principal and decides to reuse the old result.
So yes, the MFA flow is running and yes, the script logic in my "next flow strategy" script is executing, but I see
java.lang.RuntimeException: javax.script.ScriptException:
TypeError: null has no such function "getPrincipalName" in <eval> at line number 59
for this line in the script
username = input.getSubcontext("net.shibboleth.idp.authn.context.SubjectCanonicalizationContext").getPrincipalName();
So presumably the SubjectCanonicalizationContext is not available for some reason?
Can I walk the context tree and find another context from which to pull the principal tree? (I assume yes...)
Thanks,
Scott K
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
More information about the users
mailing list