MFA result reuse with Duo.
Jim Fox
fox at washington.edu
Wed Jan 18 16:16:19 EST 2017
We have something related at UW. We have an SP that requests Password
authn, but for certain users (identified by group membership) they want us
to require Duo as well. I have no control over this requirement.
My solution was to replicate MFA, into 'wdmfa' (that's easier than you'd
think) and assign 'wdmfa' to that SP. Essentially they get their own
'Password'.
Jim
On Wed, 18 Jan 2017, Cantor, Scott wrote:
> Date: Wed, 18 Jan 2017 13:08:24
> From: "Cantor, Scott" <cantor.2 at osu.edu>
> To: Shib Users <users at shibboleth.net>
> Reply-To: Shib Users <users at shibboleth.net>
> Subject: Re: MFA result reuse with Duo.
>
> On 1/18/17, 3:56 PM, "users on behalf of O'Dowd, Josh" <users-bounces at shibboleth.net on behalf of Josh.O'Dowd at mso.umt.edu> wrote:
>
>> Yes, sorry, at the time, we were very early in talks with Duo and getting Demo set up. At that time I didn't have the
>> current requirements that I am trying to satisfy today. We are still in the demo/decision stages with Duo but they are
>> getting close to a commitment, so I am getting a clearer picture of our initial use case.
>
> It's not like the use case is novel but not having it in front of me to work through I didn't realize there was a gap. I don't know how best to solve at this stage, but I think it boils down to more control over reuse/SSO.
>
> Right now SSO is linked to remembering previous results, but if the system tracked the results but didn't impose its own reuse logic, that might work. Even a basic "SSO or not" flag independent of the enabling of the session layer might be enough to solve it.
>
> -- Scott
>
>
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
>
More information about the users
mailing list