Let’s summarize it up:
1. Add a logout cookie after successful logout with the identity token of the user
2. Skip all authenticators with the automaticLogin flag if a logout cookie exists and show
instead the “is this you” page
3 If the user press, “yes this is me” than the login is succeeded, otherwise the next
authenticator will be displayed.
If everyone agrees with this workflow, than I’m going to create a PR for that, if thats
ok?
On 02.10.2015, at 11:58, Stian Thorgersen <sthorger(a)redhat.com>
wrote:
On 2 October 2015 at 11:37, Michael Gerber <gerbermichi(a)me.com
<mailto:gerbermichi@me.com>> wrote:
> On 02.10.2015, at 11:18, Stian Thorgersen <sthorger(a)redhat.com
<mailto:sthorger@redhat.com>> wrote:
>
> For the "Is this you?" mechanism I'd add a cookie at logout that
contains user details and the authenticator that was used. We’d probably need to add an
parameter to authenticators that can flag them as automatic login or not.
So basically you have to add the identity token of the user? Otherwise you can not trust
the content of this cookie, right?
Why do you want to include the authenticator? And which authenticator should that be?
You don’t have to add a flag to the authenticator, you can simply create a helper which
handles the whole “is this you?” stuff and invoke this helper method from each
authenticator (there is currently just one)
It shouldn't be baked into the authenticator itself. It should be a separate thing,
something that can control the flow.
Ok.
>
> Not sure why we would add both. If "Is this you" satisfies your
requirements, there's no one requesting the other one. My concern with adding skip is
that it’s a custom query param we're introducing that may conflict with same
functionality in OIDC, which we would then have to deprecate once we add a similar
mechanism from OIDC.
Yeah I see.
>
> On 2 October 2015 at 10:58, Michael Gerber <gerbermichi(a)me.com
<mailto:gerbermichi@me.com>> wrote:
> Maybe we can introduce both, a logout cookie and a query parameter to skip alternativ
authenticators.
> The logout cookie will be set after a logout through keycloak (Logout URL) and the
SpnegoAuthenticator offers a new configuration where you can configure if the logout
cookie should be ignored or not.
>
> So you don’t have to do something “special” in your application but you also have the
possibility to create a URL for admins where they don’t have to logout first.
>
> How would you determine the user for the “is this you?” Would you use the cookie for
that or would you do a kerberos login?
>
> Michael Gerber
> Software Engineer
>
> Hammerweg 2
> 8304 Wallisellen
>
> Tel. 079 440 23 02
> Mail gerbermichi(a)me.com <mailto:gerbermichi@me.com>
>
>
>
>
>> On 02.10.2015, at 08:37, Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>> wrote:
>>
>> On 01/10/15 20:49, Bill Burke 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.
>>>
>>>> * 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.
>> Yes, it can add the gss_delegation_credential note when Kerberos
>> credential delegation is enabled.
>>
>> Looks that we may also need the non-persistent cookie added during
>> logout, so the "Is this you" screen is not displayed for the first time
>> login?
>>>
>>>
>>>> * 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?".
>>>
>>>> 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?
>>>
>>>
>>>
>> It's quite the same. Both allow application to send something to
>> auth-server . Application can use secured URL with the param (
>>
http://localhost/customer-portal/secured?kc_idp_hint=facebook
<
http://localhost/customer-portal/secured?kc_idp_hint=facebook> or
>>
http://localhost/customer-portal/secured?skip_auth_mechanism=kerberos
<
http://localhost/customer-portal/secured?skip_auth_mechanism=kerberos> ).
>> Adapter then takes care of resend the parameter to auth-server in
>> initial AuthorizationEndpoint request. In both cases, application can
>> either provide the link or user can add the parameters manually.
>>
>> Marek
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<
https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<
https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>