Architecture of SPNEGO/Kerberos login flow
Cantor, Scott
cantor.2 at osu.edu
Fri Sep 25 23:39:36 EDT 2015
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
More information about the dev
mailing list