Shibcas + Duo

Cantor, Scott cantor.2 at osu.edu
Tue Aug 8 16:47:12 EDT 2017


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



More information about the users mailing list