[keycloak-dev] Kerberos, login with different user

Thu Oct 1 05:42:19 EDT 2015

On 01/10/15 10:59, Stian Thorgersen wrote:
>
>
> On 1 October 2015 at 10:26, Marek Posolda <mposolda at redhat.com 
> <mailto: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.
TBH I am still not seeing why kc_idp_hint parameter support is ok, but 
skip_auth_mech is not. In both cases, it's the application which wants 
to control the behaviour somehow. Skip_auth_mech can be used to skip 
some mechanism, but also to enforce login with some mechanism (skip all 
other mechanisms besides the one required).

>
>>     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 <http://redhat.com>. When I have
>     kerberos ticket, I can never see the login screen on
>     saml.redhat.com <http://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.
I imagine I have 10 tabs opened in my browser. I want to close the tab 
with mojo.redhat.com and before that, I automatically click on "logout" 
. After few minutes, I want again to do something different for example 
in calendar. redhat.com and now I will see the splash screen when I want 
to relogin.

For me, splash screen is not an issue. Not sure about all other 
employees...

Maybe we can add splash screen automatically and add support for a flag 
to not display splash screen just when someone requests it. Again, I can 
be wrong, but I bet this request will come earlier or later :-)

Marek
>
>
>
>     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
>>     <mailto: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
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>>
>>     _______________________________________________
>>     keycloak-dev mailing list
>>     keycloak-dev at lists.jboss.org <mailto: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/20151001/b858e89c/attachment.html 