<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">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</div></blockquote><div><br></div><div>In our case it's not only a matter of user experience but policy. We need to run the authn subsystem once to get attributes in order to determine whether the user is a candidate for 2-factor authentication; if not, the user MUST NOT proceed to the Duo login page. I believe our requirements are similar to what David Langenberg posted recently [1].</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    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.</div></blockquote><div><br></div><div>That's correct.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">Password authentication
    is required for the first two, but it's an extra step for X.509.</div></blockquote><div><br></div><div>Correct. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">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></div></blockquote><div><br></div><div>It's actually more complicated than that. Not all X.509 certificates are equal, though for the common case the hierarchy you stated is correct: X.509 > Duo > password.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    What if Marvin's Password login screen had a button to invoke X.509
    authentication (and was the initial-authn)?</div></blockquote><div><br></div><div>That's actually a step backward. The RequestedPrincipalContext machinery works great for driving the user to the proper login process based on SP requirements. That's not to say we can't do what you suggested, but it would trade Duo functionality for a lesser user experience. I'm hopeful we can get the functionality we need without that tradeoff.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    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></div></blockquote><div><br></div><div>Frankly, it makes my head hurt, but I think making initial-authn conditional is what we need. I'm still not clear on the knobs, but I'm willing to go with a straw man, test it, and report back.</div><div><br></div><div>M</div><div><br></div><div>[1] <a href="https://wiki.shibboleth.net/confluence/display/IDP30/Replicating+Multi-Context+Broker+Functionality">https://wiki.shibboleth.net/confluence/display/IDP30/Replicating+Multi-Context+Broker+Functionality</a></div><div><br></div></div></div>