Bug in handling user certifications for specific contexts?

[David Walker]

Scott and I had a conversation about this earlier today.  How does the
following sound as an approach that obviates the need for an initial
authentication context, at least for many use cases?  (Scott, did I get
all of this reasonably correct?)

 1. There are two Principals, Password and Duo.  They are configured so
    that Duo satisfies the requirements of Password.  (Note that this is
    the "many use cases" mentioned above.")
 2. The Password flow does the usual thing; it prompts for username and
    password.  It is not, however, the standard password flow
    distributed with Shib.
 3. The Duo flow does the following:
     1. If the IdP already has a Password Principal (or whatever kind of
        principle is acceptable, based on institution policy), the Duo
        API is invoked using that Principle.
     2. If the IdP does not already have an acceptable Principal, the
        Password (or whatever) flow is invoked to obtain a Principal,
        and then Duo Security's API is invoked.  (It may be better to
        define a subflow that prompts for username and password and is
        invoked by both Password and Duo.)
 4. When an SP requests Password:
     1. If there's been a previous SP request for Password, the IdP
        applies SSO, and the user is not prompted for authentication.
     2. If there's been a previous SP request for Duo, the IdP applies
        SSO, and the user is not prompted for authentication (because
        Duo satisfies Password).
     3. If this is the first request the IdP has gotten in this session,
        the Password flow prompts for username/password.
 5. When an SP requests Duo:
     1. If there's been a previous SP request for Duo, SSO takes over,
        and the user is not prompted for authentication.
     2. If there's been a previous SP request for Password, the Duo flow
        uses the already-established Principal and invokes Duo
        Security's API.
     3. If this is the first request the IdP has gotten in this session,
        the Duo flow prompts for username/password and invokes Duo
        Security's API.


David


On 09/09/2015 08:22 AM, Wessel, Keith wrote:
> I suggested yesterday on the call that I had with the two Davids that it'd be nice if there was some way the IDP could be configured to know that before running Duo (or some other 2nd factor method), it must run password explicitly. Password, of course, could be any other valid first method such as if one wanted to use X509 certs. While we've been able to achieve MFA by setting the initial flows property to Password, this is a bit of a hack and, as is pointed out with the issue described in this thread, becomes a problem.
>
> Is there anything that can be done (or added) to tell a flow to first run another flow to get the needed principal before proceeding?
>
> Keith
>
>
> -----Original Message-----
> From: dev [mailto:dev-bounces at shibboleth.net] On Behalf Of Cantor, Scott
> Sent: Tuesday, September 08, 2015 7:23 PM
> To: Shib Dev <dev at shibboleth.net>
> Subject: Re: Bug in handling user certifications for specific contexts?
>
> On 9/8/15, 8:19 PM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:
>
>
>
>> I think there will be unintended consequences to virtually every change from here on out.
> Though of course the only possible consequences here are prompts to login more frequently than intended based on blocking reuse of a result.
>
> -- Scott
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20150909/99341778/attachment.html>