Bug in handling user certifications for specific contexts?

[David Walker]

Comments below and at the end...

On 09/09/2015 03:23 PM, Cantor, Scott wrote:
> 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.

Dave Langenberg found that this works for "exact" matching, too.  I
should have added the following to my earlier configuration snippet:

    <util:map id="shibboleth.AuthnComparisonRules">
       ...
    <!-- Exact matching. -->
        <entry key-ref="shibboleth.SAMLAuthnMethodExact"
    value-ref="shibboleth.BetterClassRefMatchFactory"/>
        <entry key-ref="shibboleth.SAMLACClassRefExact"
    value-ref="shibboleth.BetterClassRefMatchFactory"/>
        <entry key-ref="shibboleth.SAMLACDeclRefExact"
    value-ref="shibboleth.BetterClassRefMatchFactory"/>
       ...
    <!-- Better matching -->
        <entry key-ref="shibboleth.SAMLACClassRefBetter"
    value-ref="shibboleth.BetterClassRefMatchFactory"/>
        <entry key-ref="shibboleth.SAMLACDeclRefBetter"
    value-ref="shibboleth.BetterClassRefMatchFactory"/>
    </util:map>


My presumption has been that the IdP would assert Password when using
these rules, though, even if the Duo flow had been invoked, which raises
some interesting issues:

  * What is the IdP's behavior in this case?  I'm guessing it would be
    necessary to configure the Duo flow to "support" Password.
  * Even more interesting (and, perhaps, for a different list)... I
    think many of us have been thinking that it's OK for an IdP to
    satisfy a request for a password context with something stronger. 
    Some contexts, like InCommon Silver and Bronze, define which is
    stronger, but others, like PasswordProtectedTransport or
    SmartcardPKI, do not.  Ultimately, this determination is made by the
    IdP, but do we need some community guidance/standards?  Should IdPs
    be encouraged not to use the PasswordProtectedTransport context,
    unless they explicitly mean that and only that?  Do we need a
    "Password or better" context as a companion to the MFA context
    that's being discussed in the current MFA Interoperability Profile
    Working Group
    <https://spaces.internet2.edu/display/MIPWG/MFA+Interoperability+Profile+Working+Group+Home>?

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

Yes, I left it out for simplicity, but it's there.  Here's a
not-so-simple version:

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

        if the user is certified for Password {

          * if the user has previously authenticated for Password or
            Duo, the IdP applies SSO, and no authentication flow is invoked.
          * Otherwise, the IdP invokes the Password flow.
          * Assuming no errors, the IdP asserts Password.

        } else if the user is certified for Duo {

          * if the user has previously authenticated for Duo, the IdP
            applies SSO, and no authentication flow is invoked.
          * Otherwise, the IdP invokes the Duo flow.
          * Assuming no errors, the IdP asserts Password.

        } else error

 5. When an SP requests Duo:

        if the user is certified for Duo {

          * if the user has previously authenticated for Duo, the IdP
            applies SSO, and no authentication flow is invoked.
          * Otherwise, the IdP invokes the Duo flow.
          * Assuming no errors, the IdP asserts Duo.

        } else error


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20150910/9f9b1216/attachment-0001.html>