<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Moving up a level or two...<br>
<br>
The initial-authn's purpose is, essentially, to let you get
information about the current user before addressing the SP's
request. This is needed for second factor only authentication like
Duo, but it also helps with user experience by not asking the user
to do something that can't be done (<i>e.g.</i>, authenticate with a
hardware token that hasn't been issued to the user, or an assurance
profile for which the user hasn't been certified), as well as for
implementing special site policies for when certain authentication
methods must be used.<br>
<br>
The problem is that it can cause an extra authentication step, if
the initial-authn doesn't contribute to the first SP's request. As
I understand Marvin's use case, he has three possible types of
authentication, Password, Duo, and X.509. Password authentication
is required for the first two, but it's an extra step for X.509.
I'm also guessing that X.509 satisfies the requirements for a Duo
request, and Duo satisfies the requirements of a Password request (<i>i.e.</i>,
once the user authenticates with X.509, there's no further need to
authenticate during the IdP session, barring a request for forced
re-authentication).<br>
<br>
What if Marvin's Password login screen had a button to invoke X.509
authentication (and was the initial-authn)? People with X.509
tokens could then be trained to use X.509 all the time, rather than
typing a password. It might provide a more consistent user
interface, and probably wouldn't create too much of an extra step
for X.509 token holders.<br>
<br>
I do like the idea of conditional initial-authns, by the way.
Probably something like "use X if the SP requested Y," where X and Y
may or may not be the same, but it gets complicated if the SP
requests more than one context.<br>
<br>
David<br>
<br>
<br>
<div class="moz-cite-prefix">On 07/14/2015 08:05 AM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:8CE3F534-6E91-41D4-B1DF-8E8D59FAC506@osu.edu"
type="cite">
<pre wrap="">On 7/14/15, 10:56 AM, "dev on behalf of Marvin Addison" <a class="moz-txt-link-rfc2396E" href="mailto:dev-bounces@shibboleth.netonbehalfofmarvin.addison@gmail.com"><dev-bounces@shibboleth.net on behalf of marvin.addison@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
That sounds like it would provide flexibility so that Password method of initial-authn is not assumed, which is what we need. I'm unclear what happens on the second pass through the authn subsystem; is there a flag that prevents duplicate processing by the actual auth mech?
</pre>
</blockquote>
<pre wrap="">
SSO kicks in. The initial-authn run is trying to get a Session in place so that when the "real" flow runs, if it's already done what's required to satisfy the request it just falls into the SSO logic and reuses the result.
</pre>
<blockquote type="cite">
<pre wrap="">You mean the case where a flow can't be found due to unsatisfied RequestedPrincipalContext? If that's what you mean, I don't see why it would matter. It would fail on the second round anyway and amount to the same result afaict.
</pre>
</blockquote>
<pre wrap="">
Well, the assumption for the initial-authn case is that you're limiting the set of flows that might be available, otherwise there's not much point in doing it. If you limit the initial set and then apply RequestedPrincipalContext logic to which runs are usable, the assumption I'm making is that the "real" set is larger and so the second run might not fail.
That's an assumption, but it seems like a valid one. I'm sure there could be cases where it won't hold, but I don't understand what they would be. Running initial and "regular" authn with the same set of flows and both honoring the RPC rules would seem to be truly redundant.
The "initial" run seems like it should have to be different in some dimension, either in the flows that are active or in whether the RPC is looked at.
-- Scott
</pre>
</blockquote>
<br>
</body>
</html>