Architecture of SPNEGO/Kerberos login flow

[cneberg]

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.
Issues
1) there is at least one off mobile browsers which can't do this so you
still need exclusions based on useragent  (thursby browser)
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.
3) IE logged into a different AD domain unrelated to the shib will prompt
in a way that can't succeed. (Ip restrictions needed)
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.

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.

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.

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.

Topher
On 9/16/15, 1:50 PM, "dev on behalf of Daniel Lutz" <
dev-bounces at shibboleth.net on behalf of daniel.lutz at switch.ch> wrote:

>Do you see a possibility to implement a flow that calls
>the SPNEGO/Kerberos flow as a subflow instead of merging
>two flows?

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.

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.

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.

-- Scott

--
To unsubscribe from this list send an email to
dev-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20150926/dc1a4050/attachment.html>