[keycloak-dev] Kerberos, login with different user

[Stian Thorgersen]

On 2 October 2015 at 11:37, Michael Gerber <gerbermichi at me.com> wrote:

>
>
> On 02.10.2015, at 11:18, Stian Thorgersen <sthorger at 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.


> 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 at 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 at me.com
>>
>>
>>
>>
>> On 02.10.2015, at 08:37, Marek Posolda <mposolda at 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 or
>> 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> 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/20151002/d946b9a9/attachment.html