[keycloak-dev] Kerberos, login with different user
Marek Posolda
mposolda at redhat.com
Thu Oct 1 06:11:43 EDT 2015
On 01/10/15 12:04, Stian Thorgersen wrote:
>
>
> On 1 October 2015 at 11:42, Marek Posolda <mposolda at redhat.com
> <mailto:mposolda at redhat.com>> wrote:
>
> 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).
>
>
> I'm not a big fan of kc_idp_hint either ;)
>
> "skip_auth_mech" would be a horrible way to enforce a specific auth
> mechanism. What if you add another mechanism? What if user is already
> logged-in? It's just not something that should be added without
> thinking about the corner cases. Then there are also similar things
> baked into OIDC to consider (acr, amr, id_token_hint, etc..).
>
> As we have loads of things to do and skip_auth_mech is not something
> that anyone has requested, except for in this use-case. Where I'm
> arguing that it's a bad way to do it. We shouldn't add it now as it's
> a work around/hackish solution that we haven't fully considered.
>
>
>
>>
>>> 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 <http://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 <http://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 :-)
>
>
> Really? I just don't see that as a problem. 99.999% of the time the
> user won't see any splash screen as they will just login and that's
> that. For the times when someone logs out I just can't see it being a
> huge problem that they get a "is this you" prompt.
>
> If someone is really that bothered about the splash screen let them
> tell us and we can add an option, but there's no point in filling the
> admin console up with all sorts of unused toggles.
Ok, I agree it's better to add additional toggles just when someone
requests it. I just bet this request will come :-)
Marek
>
>
>
> 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/c91472d0/attachment-0001.html
More information about the keycloak-dev
mailing list