<p dir="ltr">The solution I use to this problem is pretty simple modify the 401 error response to redirect or just be the failover auth mechanism.   If the browser can't do spnego it'll render the error page.<br>
Issues<br>
1) there is at least one off mobile browsers which can't do this so you still need exclusions based on useragent  (thursby browser) <br>
2) IE must have the DNS range in its intranet sites list and auto login in intranet zone or users will be prompted anyway and if they can't reach a DC the prompt will fail. So you need to push some configuration to your clients and still have ip restrictions for those off site.<br>
3) IE logged into a different AD domain unrelated to the shib will prompt in a way that can't succeed. (Ip restrictions needed)<br>
4) you need to include conversation key in the error redirect or all is lost which is sometimes difficult if you try to do this in the webserver or app server assumes a static error page URL.</p>
<p dir="ltr">I implemented crude rules engine which would let me select auth types by level of assurance of each of the auth types,  ip, useragent, SP, cookie contents (for user customized configs) and requested auth type which simplified the selection process greatly and at the end just shows a menu of what's left.   I needed a rules engine (or server side JavaScript based config would have worked too) rather than just a simple config because the each of the combinations of requirements greatly overlap by themselves and so would have required 10+ complicated if-then-else type config statements.  </p>
<p dir="ltr">So because of the amount of work required to do it right I recommend putting selection criteria in a higher level meta auth type selector rather than in a specific auth type itself so every auth selection process can benefit.</p>
<p dir="ltr">Slightly off topic but the rules engine approach is also awesome to use as an authz plugin so any selected auth types can also be enforced before handing out saml assertions.   The simplicity of this solution is why I advocate some level of authorization being native to the idp because expecting non homogenous SP's to re-implement the complicated logic for enforcement is crazy.</p>
<p dir="ltr">Topher<br>
</p>
<div class="gmail_quot<blockquote class=" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 9/16/15, 1:50 PM, "dev on behalf of Daniel Lutz" <<a href="mailto:dev-bounces@shibboleth.net">dev-bounces@shibboleth.net</a> on behalf of <a href="mailto:daniel.lutz@switch.ch">daniel.lutz@switch.ch</a>> wrote:<br>
<br>
>Do you see a possibility to implement a flow that calls<br>
>the SPNEGO/Kerberos flow as a subflow instead of merging<br>
>two flows?<br>
<br>
Per IDP-821, I think I have a good start on a solution to this problem. I'll write up some general information on it, but the basics are as we discussed on the dev call. The Password flow can be configured to offer "extended" login methods and the login view has been extended to control what to offer.<br>
<br>
Error handling should be possible to recover control and fall back to the password form. I haven't finished testing, but a successful use of the extended flow should be transparent, should look identical to using it directly.<br>
<br>
Obviously this doesn't include any of the cookie magic for opt-in that's in your current combined flow, but I'm hoping we can do some of that in the view template and the rest in the stand-alone flow so that the Password flow doesn't really need to know about it. Might need some creativity but the win should be substantial to be able to combine the flows unmodified.<br>
<br>
-- Scott<br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:dev-unsubscribe@shibboleth.net">dev-unsubscribe@shibboleth.net</a><br>
</div>