<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Comments below...<br>
<br>
<div class="moz-cite-prefix">On 09/09/2015 01:09 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:0BA80F62-4B4A-4301-9FF5-0022163B17E5@osu.edu"
type="cite">
<pre wrap="">On 9/9/15, 2:42 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="">
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.
</pre>
</blockquote>
<pre wrap="">
What is it doing differently if it's not that flow?
</pre>
</blockquote>
<br>
I think you're right that it can be the distributed password flow.
I had something a little different in my head when I started writing
that changed by the time I finished.<br>
<br>
<blockquote cite="mid:0BA80F62-4B4A-4301-9FF5-0022163B17E5@osu.edu"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
Specifically if the IdPSession contains an active AuthenticationResult containing that Principal, I think.
</pre>
<blockquote type="cite">
<pre wrap="">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.)
</pre>
</blockquote>
<pre wrap="">
Possibly, but I don't know if that's needed or not.
</pre>
<blockquote type="cite">
<pre wrap="">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).
</pre>
</blockquote>
<pre wrap="">
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.</pre>
</blockquote>
<br>
Right. So, in this case 4.2, will the IdP invoke the Password flow,
under the assumption that something like:<br>
<br>
<div class="container" title="Hint: double-click to select code">
<blockquote>
<div class="line number1 index0 alt2"><code class="java plain"><bean
id=</code><code class="java string">"shibboleth.BetterClassRefMatchFactory"</code>
<code class="java plain">parent=</code><code class="java
string">"shibboleth.InexactMatchFactory"</code><code
class="java plain">></code></div>
<div class="line number2 index1 alt1"><code class="java spaces"> </code><code
class="java plain"><property name=</code><code
class="java string">"matchingRules"</code><code class="java
plain">></code></div>
<div class="line number3 index2 alt2"><code class="java spaces"> </code><code
class="java plain"><map></code></div>
<div class="line number4 index3 alt1"><code class="java spaces"> </code><code
class="java plain"><entry key=</code><code class="java
string">"Password"</code><code class="java plain">></code></div>
<div class="line number5 index4 alt2"><code class="java spaces"> </code><code
class="java plain"><list></code></div>
<div class="line number7 index6 alt2"><code class="java spaces"> </code><code
class="java plain"><value>Duo</code><code class="java
comments"></value></code></div>
<div class="line number8 index7 alt1"><code class="java spaces"> </code><code
class="java plain"></list></code></div>
<div class="line number9 index8 alt2"><code class="java spaces"> </code><code
class="java plain"></entry></code></div>
<code class="java spaces"> </code><code class="java
plain"></map></code>
<div class="line number16 index15 alt1"><code class="java
spaces"> </code><code class="java plain"></property></code></div>
<code class="java spaces"></code><code class="java plain"></bean></code><br>
<code class="java plain"></code></blockquote>
<div class="line number17 index16 alt2"><code class="java plain"><br>
has been configured to indicate that Duo "satisfies"
Password? I'm thinking/hoping that it'll just return Password
to the SP without prompting for username/password (assuming no
forced authN).<br>
</code></div>
</div>
<br>
<blockquote cite="mid:0BA80F62-4B4A-4301-9FF5-0022163B17E5@osu.edu"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">3. If this is the first request the IdP has gotten in this session, the Password flow prompts for username/password.
</pre>
</blockquote>
<pre wrap="">
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.</pre>
</blockquote>
<br>
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.<br>
<br>
<blockquote cite="mid:0BA80F62-4B4A-4301-9FF5-0022163B17E5@osu.edu"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
Again, "already established AuthenticationResult containing an appropriate Principal".
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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.</pre>
</blockquote>
<br>
Sounds great! This sounds like a pretty good template for handling
any second-factor-only authentication scheme, if it could be
configured with:<br>
<br>
<ul>
<li>the list of acceptable Principal types that can be reused for
the first factor</li>
<li>the first-factor Authentication Flow that will be invoked if
no acceptable Principals are available</li>
<li>the second-factor subflow</li>
</ul>
<p><br>
Thanks, Scott.<br>
</p>
<blockquote cite="mid:0BA80F62-4B4A-4301-9FF5-0022163B17E5@osu.edu"
type="cite">
<pre wrap="">
-- Scott
</pre>
</blockquote>
<br>
</body>
</html>