<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 07/10/2015 11:49 AM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:23E707CA-503A-405A-AB25-009187A4A66C@osu.edu"
type="cite">
<pre wrap="">On 7/10/15, 12:02 PM, "users on behalf of David Walker" <a class="moz-txt-link-rfc2396E" href="mailto:users-bounces@shibboleth.netonbehalfofdhwprof@gmail.com"><users-bounces@shibboleth.net on behalf of dhwprof@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Right, so if the attributeResolverID were also configured, it would be considered in conjunction with defaultAuthenticationMethod when selecting feasible flows? (By "feasible," by the way, I mean the flows that meet, as determined by IdPv3's existing logic, the needs of 1) the SP's request, and 2) how the user has been allowed to authenticate from the attributeResolverID.)
</pre>
</blockquote>
<pre wrap="">
Yes, provided you're willing to force people to login in a specific way first, and that's the part I think falls down pretty hard in all this work. Marvin already identified the problem with that. It works fine for sites that essentially have two methods, password and something that supplements a password. If you add certificates or true MFA to the mix, I think it falls down.
</pre>
</blockquote>
<br>
Yeah, I was never happy with the solution, either. When we found
out how Duo works, we already had the initial authentication concept
(because some people didn't want to reveal information about other
authentication methods until <i>some</i> form of authentication had
been done), and we realized that it could address the common Duo use
case while making SSO work as expected.<br>
<br>
You can, of course, specific multiple possible initial
authentication methods, like password and true MFA, but that gets
you back to having your users make decisions. As I said before, I
think a better solution would be to have some way for a second
factor only flow like Duo specify in its configuration that some
other predecessor authentication flow must be run first. Of course,
that could all be put into the Duo flow, but then it would be hard
to make SSO for that predecessor flow work.<br>
<br>
<blockquote cite="mid:23E707CA-503A-405A-AB25-009187A4A66C@osu.edu"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">OK, I think I've got the basic idea. I assume the "feasible" flows would be available in the context tree?
</pre>
</blockquote>
<pre wrap="">
Yes, the AuthenticationContext (ours, not SAML's, the name conflict is unfortunate) contains the list of flow descriptors that haven't been filtered out.
</pre>
</blockquote>
<br>
Thanks.<br>
<br>
<blockquote cite="mid:23E707CA-503A-405A-AB25-009187A4A66C@osu.edu"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Yeah, I'm coming to that conclusion, too, although I could see the potential for providing choices in the future, for example, at a time that a site is migrating from one MFA product to another. I've seen examples of the more general case, though, of applying site policy to the list of feasible authentication methods (e.g., requiring MFA at certain times of the day or at certain IP addresses), so knowing how to do it is still important.
</pre>
</blockquote>
<pre wrap="">
We can add more extensible "filtering" to the login flow set if we need to. It can be done now, it's just more invasive to system files. Of course, you can also implement that sort of logic in the attribute resolver when you resolve an attribute for the user to use to filter flows.
</pre>
</blockquote>
<br>
Yeah, using the attribute resolver is a popular way to do it, and it
does handle many use cases. I think, though, that wouldn't allow a
filtering policy that's based on the SP, as well as the user. (<i>E.g.</i>,
user X is required to use MFA only when accessing SP A or B, if I
remember Scott Koranda's use case right) If you squint at it, the
choice menu is also a form of filtering, so I saw this as way to
handle the broader set of use cases.<br>
<br>
<blockquote cite="mid:23E707CA-503A-405A-AB25-009187A4A66C@osu.edu"
type="cite">
<pre wrap="">
-- Scott
</pre>
</blockquote>
<br>
</body>
</html>