<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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?)<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. It is not, however, the standard
password flow distributed with Shib.<br>
</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:</li>
<ol>
<li>If there's been a previous SP request for Password, the IdP
applies SSO, and the user is not prompted for authentication.</li>
<li>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).<br>
</li>
<li>If this is the first request the IdP has gotten in this
session, the Password flow prompts for username/password.</li>
</ol>
<li>When an SP requests Duo:</li>
<ol>
<li>If there's been a previous SP request for Duo, SSO takes
over, and the user is not prompted for authentication.</li>
<li>If there's been a previous SP request for Password, the Duo
flow uses the already-established Principal and invokes Duo
Security's API.</li>
<li>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.<br>
</li>
</ol>
</ol>
<br>
David<br>
<br>
<br>
<div class="moz-cite-prefix">On 09/09/2015 08:22 AM, Wessel, Keith
wrote:<br>
</div>
<blockquote
cite="mid:A1EB7EC659FA0F429A55865D5820006D2E33CF70@CITESMBX1.ad.uillinois.edu"
type="cite">
<pre wrap="">I suggested yesterday on the call that I had with the two Davids that it'd be nice if there was some way the IDP could be configured to know that before running Duo (or some other 2nd factor method), it must run password explicitly. Password, of course, could be any other valid first method such as if one wanted to use X509 certs. While we've been able to achieve MFA by setting the initial flows property to Password, this is a bit of a hack and, as is pointed out with the issue described in this thread, becomes a problem.
Is there anything that can be done (or added) to tell a flow to first run another flow to get the needed principal before proceeding?
Keith
-----Original Message-----
From: dev [<a class="moz-txt-link-freetext" href="mailto:dev-bounces@shibboleth.net">mailto:dev-bounces@shibboleth.net</a>] On Behalf Of Cantor, Scott
Sent: Tuesday, September 08, 2015 7:23 PM
To: Shib Dev <a class="moz-txt-link-rfc2396E" href="mailto:dev@shibboleth.net"><dev@shibboleth.net></a>
Subject: Re: Bug in handling user certifications for specific contexts?
On 9/8/15, 8:19 PM, "Cantor, Scott" <a class="moz-txt-link-rfc2396E" href="mailto:cantor.2@osu.edu"><cantor.2@osu.edu></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I think there will be unintended consequences to virtually every change from here on out.
</pre>
</blockquote>
<pre wrap="">
Though of course the only possible consequences here are prompts to login more frequently than intended based on blocking reuse of a result.
-- Scott
</pre>
</blockquote>
<br>
</body>
</html>