Shibcas + Duo

[Justin Andrews]

I guess I'm just wondering how I get that value being returned from
Shibcas...

authCtx =
input.getSubcontext("net.shibboleth.idp.authn.context.AuthenticationContext");
mfaCtx =
authCtx.getSubcontext("net.shibboleth.idp.authn.context.MultiFactorAuthenticationContext");


What function would pull it out of mfaCtx?


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

On Wed, Aug 9, 2017 at 7:28 AM, Justin Andrews <jandrews at uwf.edu> wrote:

> 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.CanonicalUsernam
>> eLookupStrategy
>>
>> --
>> 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/fffe140d/attachment.html>