Bug in handling user certifications for specific contexts?

[Cantor, Scott]

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

>Right.  So, in this case 4.2, will the IdP invoke the Password flow, under the assumption that something like:
>
><bean id="shibboleth.BetterClassRefMatchFactory"parent="shibboleth.InexactMatchFactory">
>     <property name="matchingRules">
>         <map>
>             <entry key="Password">
>                 <list>
>                     <value>Duo</value>
>                 </list>
>             </entry>
>         </map>     </property>
></bean>
>
>has been configured to indicate that Duo "satisfies" Password?

That only applies if the SP is requesting "better" than Password. That's not the case here. If an SP requests Password, the only way the IdP can respond is if it can obtain an AuthenticationResult containing Password. There is no "same as". It's Password or error. That's a requirement of the standard. If the original login produces such a result, you get SSO. If not, it will try any flow that supports that requested context class.

If you want to get into the other comparison types, that changes the situation. With the above, requesting "better" than Password will allow it to consider an AuthenticationResult containing *only* Duo to satisfy that request.

It's my ill-considered hunch that a Duo flow will probably rarely produce something like that. A result containing only "Duo" would imply that only that factor was used. That seems to be rare at best.

I think the most likely outcome of this kind of composite flow is either "first-factor" or "first factor" and "second factor".

>I'm thinking/hoping that it'll just return Password to the SP without prompting for username/password (assuming no forced authN).

Only if the Duo flow produces a result that allows it to. That has to contain Password, or it can't.

>I'm not sure what you mean by opt-in, but the MCB doesn't consider user opt-in any differently from institution-imposed; it's all in the attribute containing the list of contexts/principals that can be asserted for this user.

That's my point, your examples didn't really consider the use of an attribute like that. And the current use of such an attribute is not really on point to this scenario.

>Sounds great!  This sounds like a pretty good template for handling any second-factor-only authentication scheme, if it could be configured with:
>
>* the list of acceptable Principal types that can be reused for the first factor
>* the first-factor Authentication Flow that will be invoked if no acceptable Principals are available
>* the second-factor subflow 

I think there's a missing piece in there related to the user/attribute, unless that whole use case is left out for the moment, but it seems to be a given from what I'm seeing. I don't yet understand all the impacts of including that.

-- Scott