<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Comments below and at the end...<br>
<br>
<div class="moz-cite-prefix">On 09/09/2015 03:23 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:52A079F1-861A-467F-94EE-54CF2BD87810@osu.edu"
type="cite">
<pre wrap="">On 9/9/15, 6:05 PM, "dev on behalf of David Walker" <a class="moz-txt-link-rfc2396E" href="mailto:dev-bounces@shibboleth.netonbehalfofdwalker@internet2.edu"><dev-bounces@shibboleth.net on behalf of dwalker@internet2.edu></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap="">
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.</pre>
</blockquote>
<br>
Dave Langenberg found that this works for "exact" matching, too. I
should have added the following to my earlier configuration snippet:<br>
<br>
<blockquote><tt><util:map
id="shibboleth.AuthnComparisonRules"></tt><br>
<tt> ...</tt><br>
<tt><!-- Exact matching. --></tt><br>
<tt> <entry key-ref="shibboleth.SAMLAuthnMethodExact"
value-ref="shibboleth.BetterClassRefMatchFactory"/></tt><br>
<tt> <entry key-ref="shibboleth.SAMLACClassRefExact"
value-ref="shibboleth.BetterClassRefMatchFactory"/></tt><br>
<tt> <entry key-ref="shibboleth.SAMLACDeclRefExact"
value-ref="shibboleth.BetterClassRefMatchFactory"/></tt><br>
<tt> ...</tt><br>
<tt><!-- Better matching --></tt><br>
<tt> <entry key-ref="shibboleth.SAMLACClassRefBetter"
value-ref="shibboleth.BetterClassRefMatchFactory"/></tt><br>
<tt> <entry key-ref="shibboleth.SAMLACDeclRefBetter"
value-ref="shibboleth.BetterClassRefMatchFactory"/></tt><br>
<tt></util:map></tt><br>
</blockquote>
<br>
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:<br>
<br>
<ul>
<li>What is the IdP's behavior in this case? I'm guessing it
would be necessary to configure the Duo flow to "support"
Password.</li>
<li>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 <a
href="https://spaces.internet2.edu/display/MIPWG/MFA+Interoperability+Profile+Working+Group+Home">MFA
Interoperability Profile Working Group</a>?<br>
</li>
</ul>
<blockquote cite="mid:52A079F1-861A-467F-94EE-54CF2BD87810@osu.edu"
type="cite">
<pre wrap="">
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".
</pre>
<blockquote type="cite">
<pre wrap="">I'm thinking/hoping that it'll just return Password to the SP without prompting for username/password (assuming no forced authN).
</pre>
</blockquote>
<pre wrap="">
Only if the Duo flow produces a result that allows it to. That has to contain Password, or it can't.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">
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
</pre>
</blockquote>
<br>
Yes, I left it out for simplicity, but it's there. Here's a
not-so-simple version:<br>
<br>
<ol>
<li>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.")<br>
</li>
<li>The Password flow does the usual thing; it prompts for
username and password. </li>
<li>The Duo flow does the following:</li>
<ol>
<li>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.</li>
<li>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.)<br>
</li>
</ol>
<li>When an SP requests Password:<br>
</li>
</ol>
<blockquote>
<blockquote>if the user is certified for Password {<br>
</blockquote>
<blockquote>
<ul>
<li>if the user has previously authenticated for Password or
Duo, the IdP applies SSO, and no authentication flow is
invoked.<br>
</li>
<li>Otherwise, the IdP invokes the Password flow.</li>
<li>Assuming no errors, the IdP asserts Password.<br>
</li>
</ul>
} else if the user is certified for Duo {<br>
<ul>
<li>if the user has previously authenticated for Duo, the IdP
applies SSO, and no authentication flow is invoked.</li>
<li>Otherwise, the IdP invokes the Duo flow.</li>
<li>Assuming no errors, the IdP asserts Password.</li>
</ul>
} else error</blockquote>
</blockquote>
<ol start="5">
<li>When an SP requests Duo:</li>
</ol>
<blockquote>
<blockquote>
<p>if the user is certified for Duo {<br>
</p>
<ul>
<li>if the user has previously authenticated for Duo, the IdP
applies SSO, and no authentication flow is invoked.</li>
<li>Otherwise, the IdP invokes the Duo flow.</li>
<li>Assuming no errors, the IdP asserts Duo.</li>
</ul>
} else error<br>
</blockquote>
</blockquote>
<br>
</body>
</html>