[keycloak-dev] Kerberos, login with different user

Bill Burke bburke at redhat.com
Fri Oct 2 10:31:06 EDT 2015



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


More information about the keycloak-dev mailing list