[keycloak-dev] Kerberos, login with different user
Bill Burke
bburke at redhat.com
Mon Oct 5 09:17:31 EDT 2015
I think you can just specify a query param in the auth server URL in the
adapter config:
"http://server.com/auth?skip_auth_mech=asdfasdf"
It looks like the code uses UriBuilder to create the endpoint urls so
the query param should stick around.
On 10/5/2015 8:41 AM, Michael Gerber wrote:
> Ok, I see.
> Is there a way to pass an url query parameter through the wildfly
> adapter into an authenticator?
>
> Am 05. Oktober 2015 um 09:39 schrieb Stian Thorgersen <sthorger at redhat.com>:
>
>> I don't think the account chooser is a good option. As you say users
>> that login with Kerberos (and have enabled Kerberos for the Keycloak
>> domain) will in 99% cases want to login with Kerberos.
>>
>> End of the day I don't really like any of these options, and so far
>> Michael is the only person asking for something like this. With that
>> in mind I think it's better that Michael would develop something
>> custom on top of the authenticator spi, rather than us adding this to
>> Keycloak.
>>
>> On 5 October 2015 at 08:01, Michael Gerber <gerbermichi at me.com
>> <mailto:gerbermichi at me.com>> wrote:
>>
>> I don't like this approach if the "Account Chooser" page is only
>> configurable per realm.
>> Because, I think it is a bit annoying if you always have to go
>> over the "Account Chooser" page.
>> 99% of all uses want to log in with their kerberos credentials,
>> there are only a few people which want to switch their account.
>>
>> But I think your approach is good, if you can enable the "Account
>> Chooser" page per client and not only per realm.
>>
>> Am 02. Oktober 2015 um 16:31 schrieb Bill Burke <bburke at redhat.com
>> <mailto:bburke at redhat.com>>:
>>
>>>
>>>
>>> On 10/2/2015 5:26 AM, Stian Thorgersen wrote:
>>>>
>>>>
>>>> On 1 October 2015 at 20:49, Bill Burke <bburke at redhat.com
>>>> <mailto:bburke at redhat.com>
>>>> <mailto:bburke at redhat.com <mailto:bburke at redhat.com>>> 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.
>>>>
>>>>
>>>> Could we not have a selector or something in the authentication flow
>>>> that can select which authenticator to use? The selector could
>>>> even be
>>>> allowed to prompt the user for input, so we could implement a
>>>> "Is this
>>>> you" selector.
>>>>
>>>>
>>>> > * 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.
>>>>
>>>>
>>>> I was assuming that this option would also require user to
>>>> logout first.
>>>> "Is this you" would only be displayed after a logout.
>>>>
>>>
>>> I don't like this "logout required" thing and the logout cookie.
>>> What
>>> is the big deal about having a screen "You are already logged in via
>>> Kerberos. Do you want to continue? Or log in as a different user?"
>>> This would be something that is optionally turned on and shown
>>> after the
>>> Kerberos/SPNEGO handshake.
>>>
>>>
>>>>
>>>>
>>>> > * 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?".
>>>>
>>>>
>>>> "Is this you" would simply prompt the user if the user is the
>>>> user that
>>>> previously logged in from that browser.
>>>>
>>>> Account switcher would allow a user to be signed-in to Keycloak with
>>>> multiple accounts and provide some mechanism for applications to
>>>> select
>>>> which account. Like GMail and others allow you to be logged-in to
>>>> multiple accounts at a time.
>>>>
>>>
>>>
>>> Again, this is very similar to the "Is this you?". The steps
>>> would be:
>>>
>>> 1. SPNEGO handshake successful
>>> 2. Show account switcher page with kerberos user as only choice.
>>>
>>> The only need for a logout persistent cookie is to remember
>>> successful
>>> logins.
>>>
>>> I would like this approach the best.
>>>
>>>
>>>>
>>>> > 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?
>>>>
>>>>
>>>> We should never have added idp_hint in the first place IMO. It leaks
>>>> authentication semantics into applications and also only works
>>>> if user
>>>> is not logged in already.
>>>>
>>>
>>> idp_hint is a good thing. If an app integrates with Facebook,
>>> they'll
>>> need to force the user to login via Facebook so they can obtain a
>>> Facebook token.
>>>
>>>> skip_auth_mech could be implemented in applications as well
>>>> but my same
>>>> point stands here. It requires applications to be aware of
>>>> authentication semantics. It seems that what's being proposed
>>>> here is
>>>> that admins manually add it to the login URL though, but that's
>>>> just a
>>>> horrible idea, period.
>>>>
>>>
>>> skip_auth_mech is the opposite of auth_mechs_required. Something
>>> that I
>>> believe SAML has.
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>> _______________________________________________
>>> 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
>>
>>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
More information about the keycloak-dev
mailing list