[keycloak-dev] Kerberos, login with different user

Michael Gerber gerbermichi at me.com
Fri Oct 2 05:37:04 EDT 2015



> 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)
> 
> 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 <mailto: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 <mailto:gerbermichi at me.com> 
> 
> 
> 
> 
>> On 02.10.2015, at 08:37, Marek Posolda <mposolda at redhat.com <mailto: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 <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 at lists.jboss.org <mailto:keycloak-dev at 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 at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev <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/ad8317fa/attachment-0001.html 


More information about the keycloak-dev mailing list