<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Comments below...<br>
<br>
David<br>
<br>
<br>
<div class="moz-cite-prefix">On 07/09/2015 07:16 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:FAB0B538-A2A0-4891-9103-D35AE1DE36C7@osu.edu"
type="cite">
<pre wrap="">On 7/9/15, 4:17 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="">I've posted a DRAFT document describing conversion from the Multi-Context Broker (MCB) to IdPv3 at
<a class="moz-txt-link-freetext" href="https://wiki.shibboleth.net/confluence/x/oAEzAQ">https://wiki.shibboleth.net/confluence/x/oAEzAQ</a>. It's not yet complete, and I'm sure it has errors, so I'd appreciate a glance from some more knowledgeable eyes than mine. You'll see some comments
in red that are open issues right now.
</pre>
</blockquote>
<pre wrap="">
I have vacation days and SP matters to deal with so it will be a while before I have time to review it.
</pre>
</blockquote>
<br>
Thanks, Scott.<br>
<br>
<blockquote cite="mid:FAB0B538-A2A0-4891-9103-D35AE1DE36C7@osu.edu"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">* I believe IdPv3 bypasses the processing of authnContexts if the SP does not request any contexts. Since one of the use cases is to allow institutions to require that certain people use multi-factor authentication (or allow users to opt-in to such a requirement),
</pre>
</blockquote>
<pre wrap="">
My assumption was that that would involve filtering login flows based on an attribute. Users that require MFA would only carry that flow ID in the attribute, so it would prevent use of auth/Password. That was the reason for the "initial authentication" stuff, to get the user ID so the attribute can be resolved.
</pre>
</blockquote>
<br>
Yes, exactly.<br>
<br>
<blockquote cite="mid:FAB0B538-A2A0-4891-9103-D35AE1DE36C7@osu.edu"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">I'm looking for a way to force that processing? For example, is it possible to define a default relying party that "requests" the institution's lowest-level authnContext?
</pre>
</blockquote>
<pre wrap="">
Profile configuration beans that involve authentication (i.e. the SSO profiles) have two properties:
authenticationFlows (Set<String>)
defaultAuthenticationMethods (List<Principal>)
The former will specifically turn on and off login flows by flow ID directly. The latter is analagous to the defaultAuthenticationMethod in V2 and acts as a pseudo-RequestedAuthnContext. That's closer to what you're driving at. It acts as if the SP sent a request for an exact match to one of the custom Principals specified. It's slightly stronger in meaning than that V2 setting was because it really does require the authentication result end up with a matching Principal, as if an SP requested it.
But that's not user-aware, only relying party aware.</pre>
</blockquote>
<br>
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.)<br>
<br>
<blockquote cite="mid:FAB0B538-A2A0-4891-9103-D35AE1DE36C7@osu.edu"
type="cite">
<blockquote type="cite">
<pre wrap="">* You'll notice that a number of the red comments are related to the MCB's ability to present the end user with a choice of feasible authentication methods, rather than picking one at random. Scott, I have a memory that you said there was a hook that could be used to implement that choice mechanism; can you point me in the right direction?
</pre>
</blockquote>
<pre wrap="">
A custom login flow that doesn't actually do much itself, and just renders a view-state with links/buttons that signal what flow to run next, which I documented the mechanism for in the wiki page on authentication.
The flow would I guess be the first one listed in the descriptor list and would carry every possible supportedPrincipal needed so that any request for any method would route into it. That was and is all hand waving. I don't know how much work it would be to figure out which options to present the user because I don't really know what the inputs to that decision would be.
</pre>
<blockquote type="cite">
<pre wrap="">I'm thinking it would be a "choice" flow that could be invoked after the IdP had determined the feasible flows that can be used, based on the SP's request and the user's allowable contexts. The "choice" flow would then select which of the feasible flows to invoke, based on prompting the user or any other policy the site might want to implement.
</pre>
</blockquote>
<pre wrap="">
Yes, basically. That's why I implemented a mechanism for a login flow to signal for another one to run.
"Magic happens" and that view has to be rendered with enough logic to make all those determinations based on what's in the context tree, which is full of all kinds of information. Might need to be a JSP view to be palatable to code it. Velocity isn't that great for doing a lot of logic.</pre>
</blockquote>
<br>
OK, I think I've got the basic idea. I assume the "feasible" flows
would be available in the context tree?<br>
<br>
<blockquote cite="mid:FAB0B538-A2A0-4891-9103-D35AE1DE36C7@osu.edu"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">* Related to my previous question, does anyone have a use for presenting such a choice? I thought it was important when spec'ing the MCB, but I've found that many sites go to lengths to turn it off.
</pre>
</blockquote>
<pre wrap="">
Personally, I think it's better for the user to route to actual usable login interfaces and give them buttons to transfer to others than to force a list up front. Particularly if there's an 80% or 90% case anyway, which seems likely. As other people have done, you can drop cookies to record choices and change which one is used for a user by default the next time.</pre>
</blockquote>
<br>
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 (<i>e.g.</i>,
requiring MFA at certain times of the day or at certain IP
addresses), so knowing how to do it is still important.<br>
<br>
<blockquote cite="mid:FAB0B538-A2A0-4891-9103-D35AE1DE36C7@osu.edu"
type="cite">
<pre wrap="">
-- Scott
</pre>
</blockquote>
<br>
</body>
</html>