[keycloak-dev] Kerberos, login with different user

[Stian Thorgersen]

I don't think the account chooser is a good option. As you say users that
login with Kerberos (and have enabled Kerberos for the Keycloak domain)
will in 99% cases want to login with Kerberos.

End of the day I don't really like any of these options, and so far Michael
is the only person asking for something like this. With that in mind I
think it's better that Michael would develop something custom on top of the
authenticator spi, rather than us adding this to Keycloak.

On 5 October 2015 at 08:01, Michael Gerber <gerbermichi at me.com> wrote:

> I don't like this approach if the "Account Chooser" page is only
> configurable per realm.
> Because, I think it is a bit annoying if you always have to go over the "Account
> Chooser" page.
> 99% of all uses want to log in with their kerberos credentials, there are
> only a few people which want to switch their account.
>
> But I think your approach is good, if you can enable the "Account Chooser"
> page per client and not only per realm.
>
> Am 02. Oktober 2015 um 16:31 schrieb Bill Burke <bburke at redhat.com>:
>
>
>
> On 10/2/2015 5:26 AM, Stian Thorgersen wrote:
>
>
>
> On 1 October 2015 at 20:49, Bill Burke <bburke at redhat.com
>
> <mailto:bburke at redhat.com>> wrote:
>
>
> Sorry for late reply.
>
>
> On 10/1/2015 3:13 AM, Stian Thorgersen wrote:
>
> > * If a user that was logged in using Kerberos logs out the user should
>
> > not just be automatically logged-in again for the current browser
>
> > session. Instead the user should be displayed with a regular
>
> > username/password field, but also with an option to login with Kerberos
>
>
> Don't like this idea.
>
>
> #1 Users that want to bypass kerberos have to know to logout first so
>
> they can login as a non-kerberos user.
>
>
> #2 username/password screen would have to have knowledge that kerberos
>
> is turned on and that the user was logged in via kerberos. I'm don't
>
> think this is possible with the current SPI.
>
>
>
> Could we not have a selector or something in the authentication flow
>
> that can select which authenticator to use? The selector could even be
>
> allowed to prompt the user for input, so we could implement a "Is this
>
> you" selector.
>
>
>
> > * A variant on the above where if a user has logged-out from Kerberos
>
> > the user would be displayed with a "Is this you?" when login, if the
>
> > user selects yes the Kerberos authenticator would continue, if not the
>
> > regular username/password form would be displayed
>
>
> This one might be easy to do with current SPI although not sure if
>
> kerberos plugin sets some session variables that need to be cleared.
>
>
>
> I was assuming that this option would also require user to logout first.
>
> "Is this you" would only be displayed after a logout.
>
>
>
> I don't like this "logout required" thing and the logout cookie. What
> is the big deal about having a screen "You are already logged in via
> Kerberos. Do you want to continue? Or log in as a different user?"
> This would be something that is optionally turned on and shown after the
> Kerberos/SPNEGO handshake.
>
>
>
>
> > * Implement account switcher - where a user can login to multiple
>
> > accounts at a time and select which account to use
>
> >
>
>
> Not sure how this is different than "Is this you?".
>
>
>
> "Is this you" would simply prompt the user if the user is the user that
>
> previously logged in from that browser.
>
>
> Account switcher would allow a user to be signed-in to Keycloak with
>
> multiple accounts and provide some mechanism for applications to select
>
> which account. Like GMail and others allow you to be logged-in to
>
> multiple accounts at a time.
>
>
>
>
> Again, this is very similar to the "Is this you?". The steps would be:
>
> 1. SPNEGO handshake successful
> 2. Show account switcher page with kerberos user as only choice.
>
> The only need for a logout persistent cookie is to remember successful
> logins.
>
> I would like this approach the best.
>
>
>
> > Other ideas? Points for ideas that requires no hacks in applications ;)
>
> >
>
>
> idp_hint is a much different animal, isn't it? idp_hint is provided by
>
> the application. skip_auth_mechanism would be something the user has to
>
> know about to type in the URL right?
>
>
>
> We should never have added idp_hint in the first place IMO. It leaks
>
> authentication semantics into applications and also only works if user
>
> is not logged in already.
>
>
>
> idp_hint is a good thing. If an app integrates with Facebook, they'll
> need to force the user to login via Facebook so they can obtain a
> Facebook token.
>
> skip_auth_mech could be implemented in applications as well
>
> but my same
>
> point stands here. It requires applications to be aware of
>
> authentication semantics. It seems that what's being proposed here is
>
> that admins manually add it to the login URL though, but that's just a
>
> horrible idea, period.
>
>
>
> skip_auth_mech is the opposite of auth_mechs_required. Something that I
> believe SAML has.
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151005/7e52de25/attachment.html