Shibcas + Duo

[Justin Andrews]

Thank you Scott. Either the number of username value could work for Duo.
I'll look into including a net.shibboleth.idp.session.context.navigate.
CanonicalUsernameLookupStrategy - any examples appreciate. Thank you.

Justin Andrews
Enterprise Systems Integrator
Information Technology Services
University of West Florida

On Tue, Aug 8, 2017 at 4:47 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 8/8/17, 4:10 PM, "users on behalf of Justin Andrews" <
> users-bounces at shibboleth.net on behalf of jandrews at uwf.edu> wrote:
>
> > I'm troubleshooting the username being used in the Duo flow - any way to
> dial this into DEBUG logging?
>
> That means that the Shibcas flow is not up to date with the requirements
> of a 3.3 login flow, which I wouldn't really be expecting given that it was
> older. I don't intend to look at it to tell you why, but it likely involves
> it not invoking the subject c14n step at the end of its work to spit back a
> "final" answer. That is a requirement in order for the Duo flow to run with
> the default configuration and all the flows we ship were updated to do this.
>
> If it's doing something along the lines of what other flows shipped with
> the IdP did prior to 3.3, they left behind an AuthenticationResult
> containing a Subject that probably contains a UsernamePrincipal object with
> whatever username they validated.
>
> > I worry since the nameid returned by our CAS is a user's
> employee/student number instead of their username.
>
> What it is or isn't doesn't cause the problem, it isn't *anything*
> "official" at present. It hasn't finalized its results in the form required
> by the software's default behavior.
>
> What is the value space you require Duo to consume? The username or the
> number? And aside from that, you can't really fix this unless you know
> where the data is, and that would depend on the internals of the
> non-compliant login flow that has left the system in the partially
> completed state though my supposition on that above is probably close.
>
> > I'm assuming I'm going to have to tinker with leveraging
> shibboleth.authn.Duo.UsernameLookupStrategy but don't want to
> > jeopardize security. Any working examples of that bean?
>
> You cannot avoid overriding it if you have a non-compliant first factor.
> The best example is the class/function it's using by default [1]. In a case
> like this, the "partial" result from the other flow is going to be stored
> off inside the MultiFactorAuthenticationContext object in the tree, which
> is two layers down, PRC -> AuthenticationContext -> MFAContext.
>
> -- Scott
>
> [1] net.shibboleth.idp.session.context.navigate.
> CanonicalUsernameLookupStrategy
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170809/1105bcba/attachment.html>