[keycloak-dev] Kerberos, login with different user

Thu Oct 1 04:59:19 EDT 2015

On 1 October 2015 at 10:26, Marek Posolda <mposolda at redhat.com> wrote:

> On 01/10/15 09:13, Stian Thorgersen wrote:
>
> I don't like the query param approach as it requires somehow adding the
> query param to specify what authenticators to skip. This would have to be
> added to applications themselves and with Keycloak the whole idea is that
> applications shouldn't have to worry about authentication semantics.
>
> I thing that some applications care about how was user authenticated :-\
>

Maybe, but that's not the case in this use-case. In this case we simply
want to use another user than the automatically logged-in user. So
skip_auth_mech just becomes a work around/hack rather than a proper solution

>
>
> For example when application wants to reuse Kerberos credential from the
> SPNEGO authentication to call some other thirdparty kerberos-secured
> service, it needs a way to "force" keycloak to authenticate with Kerberos.
> Hence it can skip other authenticators and leave just Kerberos.
>
> Similar case is, when application wants to reuse Facebook access token -
> in this case application wants to enforce login with Facebook. For this
> case, we already have kc_idp_hint parameter, which also requires support on
> the application side . Isn't it similar to the query parameter
> skip_auth_mechanisms ?
>

Those situations are much more advanced than this use-case. In those case
you'd have to have some form of a additional authenticators. For example if
an app needs Facebook token they would need the user to authenticate with
Facebook whether or not the user is already authenticated. This becomes
quite tricky, especially if the user is already logged-in and logs in with
FB as another user. But, that's not what this use case is about and we
haven't had a request for this, so no need to consider it now.

>
> I might be wrong, but maybe some Keycloak users don't care too much about
> SSO. The added value for them is provisioning of users and the fact, that
> they don't need to implement Facebook or Kerberos authentication, but
> Keycloak implements it for them. So they may want some control on the
> application side how is user authenticated.
>

SSO or not, it's still the same concept of moving authentication semantics
away from apps to the authentication server.

>
> We need a generic mechanism to be able to skip any authenticators that
> automatically log in a user. Currently this is only Kerberos, but in the
> future we could add more, including an option to automatically route to
> external IdPs.
>
> For external IdPs, we already have "Authenticate by Default" switch on
> identity providers. We also have kc_idp_hint parameter as I mentioned above.
>
>
> Ignoring implementation semantics for now, but taking Kerberos as the
> example authenticator I can see some options (in the example below replace
> 'Kerberos' with any other authentication method that can automatically
> login a user):
>
> * 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
> * 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
>
> +1 to support "Is this you" screen. However maybe this should be
> configurable as some deployments may not want to display the screen, but
> want to relogin automatically.
>
> Classic example is redhat.com. When I have kerberos ticket, I can never
> see the login screen on saml.redhat.com . If we enforce adding "Is this
> you", some employees may complain "Hey, why there is another splash screen
> I need to click. Why I am not logged automatically" etc. But maybe I am
> wrong here. Maybe good opportunity to ask IT guys on the call today as they
> have experience with the real world scenarios ;-)
>

I don't see why it's a problem that the splash screen is displayed. The
user has decided to log out from the Kerberos session so it makes no sense
whatsoever to automatically log the user in again. That's basically
disabling the log out.

>
>
> Conclusion of my point of view: Add variable support for "Is this you"
> screen and in addition have the support for skip_auth_mechanism Michael
> implemented.
>

If we add is this you screen, then skip_auth_mechanism is not required for
this use case and hence we should not add it unless specifically requested

>
>
> Marek
>
> * Implement account switcher - where a user can login to multiple accounts
> at a time and select which account to use
>
> Other ideas? Points for ideas that requires no hacks in applications ;)
>
> On 30 September 2015 at 15:39, Michael Gerber <gerbermichi at me.com> wrote:
>
>> Hi all,
>>
>> I would like to use kerberos as my standard authentication mechanism, but
>> I also want to have the possibility to log in as an admin over the login
>> form.
>> Therefore, I want to skip the kerberos authenticator after a successful
>> logout.
>> https://issues.jboss.org/browse/KEYCLOAK-1727
>>
>> How would you solve this problem?
>>
>> I've got two solutions, one sets a logout session cookie after a logout
>> and then skips the kerberos authentication and another which allows users
>> to skip any kind of alternative authenticators with a query parameter.
>>
>> Logout Session Cookie
>>
>> https://github.com/gerbermichi/keycloak/commit/f804d9e13573cb666cf6d2eff1407978c9e5e854
>>
>> Query Param
>>
>> https://github.com/gerbermichi/keycloak/commit/abd3bd87f5aa4c28914da677653268c0f44fe6cc
>>
>> Michael
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151001/9b51547c/attachment-0001.html 