Bug in handling user certifications for specific contexts?

[Cantor, Scott]

On 9/9/15, 2:42 PM, "dev on behalf of David Walker" <dev-bounces at shibboleth.net on behalf of dwalker at internet2.edu> wrote:


>
>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.

What is it doing differently if it's not that flow?

>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.

Specifically if the IdPSession contains an active AuthenticationResult containing that Principal, I think.

>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.)

Possibly, but I don't know if that's needed or not.

>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).

It's not a question of what the flow does or doesn't support, it's a function of what Principals are inside the active AuthenticationResult(s) in the IdPSession.

>3. If this is the first request the IdP has gotten in this session, the Password flow prompts for username/password.

I think this all sort of blows up when you factor opt-in scenarios, but I don't know how badly. That's why I think the Duo flow has to drive the process, by recognizing what the user is meant to do.

>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.

Again, "already established AuthenticationResult containing an appropriate Principal".

>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.

Mostly this makes sense to me, it's the opt-in cases where I think it gets weird, but I think coding it this way will be much simpler than the initial-authn + resolved attribute way of trying to control all this. But I guess we may still need to lookup attribute(s) because of opt-in and other cases, so that can be added in. Resolving attributes is a pretty simple thing to wedge into a flow.

I'm willing to code up an example for this once I understand the goal.

-- Scott