10:02 a.m.
We are considering implementing this feature.
The feature requires Keycloak to allow the user to logon as another user even if Kerberos
works.
The user scenario is two fold:
* Have an admin hold two accounts (normal with Kerberos and elevated using
username/pass) and switch between them
* Have a user logged on using Kerberos when another user visits and wants to logon
as himself without logging on to the computer.
The feature would be implemented via a new query parameter (i.e.
skipAuthMechanism=cookie,kerberos) that would allow the client to skip certain methods of
authentication.
I would like to make sure such a PR would not be rejected as work would have been wasted.
10:15 a.m.
Also, before you comment, read https://github.com/keycloak/keycloak/pull/1644
I believe there is no harm in skip_auth_mechanisms query parameter. I agree there are
scenarios where other options are also good, but not globally.
12:47 p.m.
As you can see in the older discussions in the PR in JIRA, we were still
discussing what exactly to do. Some approaches were:
1) Use the parameter like skip_auth_mechanisms
2) Use another confirmation screen (Account chooser authenticator or
something like that) - Something, which will be shown after successful
Kerberos authentication as user "jdoe" and will display "Do you really
want to authenticate as John Doe, click <link>here</link> . Do you want
to authenticate as the other user click <link>here</link>". In the
latter case, Kerberos authentication will be bypassed and
username/password screen shown
3) Automatically skip Kerberos after the logout. I personally didn't
like this approach. IMO if we do this, we will anyway need the config
option on the Kerberos authenticator.
My personal preference is 1, then 2, then 3.
For your usecase, I suspect that in most of the cases you want to
authenticate as Kerberos user, but just in some special cases (admin
needs to authenticate with some special account etc) bypass Kerberos. Is
it correct? So the query parameter is your preferred way right?
Anyway, I wouldn't start contribute to Keycloak for now until it's
agreed what exactly to do. You can already handle it in your environment
with your own Authenticator implementation where you can implement
"skip_auth_mechanisms" or something like that.
Marek
On 05/10/17 10:15, Jože Mlakar wrote:
Also, before you comment, read
https://github.com/keycloak/keycloak/pull/1644
I believe there is no harm in skip_auth_mechanisms query parameter. I agree there are
scenarios where other options are also good, but not globally.
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
12:55 p.m.
Another thing is, that we are planning to add the support for the "acr"
OIDC parameter (aka authentication levels) and I believe that this
usecase should be addressed through this.
For now, I would do something on your own as we still need to discuss
how exactly to address this and when (My guess is Keycloak 4.x somewhen
next year).
Marek
On 09/10/17 12:47, Marek Posolda wrote:
As you can see in the older discussions in the PR in JIRA, we were
still discussing what exactly to do. Some approaches were:
1) Use the parameter like skip_auth_mechanisms
2) Use another confirmation screen (Account chooser authenticator or
something like that) - Something, which will be shown after successful
Kerberos authentication as user "jdoe" and will display "Do you really
want to authenticate as John Doe, click <link>here</link> . Do you
want to authenticate as the other user click <link>here</link>". In
the latter case, Kerberos authentication will be bypassed and
username/password screen shown
3) Automatically skip Kerberos after the logout. I personally didn't
like this approach. IMO if we do this, we will anyway need the config
option on the Kerberos authenticator.
My personal preference is 1, then 2, then 3.
For your usecase, I suspect that in most of the cases you want to
authenticate as Kerberos user, but just in some special cases (admin
needs to authenticate with some special account etc) bypass Kerberos.
Is it correct? So the query parameter is your preferred way right?
Anyway, I wouldn't start contribute to Keycloak for now until it's
agreed what exactly to do. You can already handle it in your
environment with your own Authenticator implementation where you can
implement "skip_auth_mechanisms" or something like that.
Marek
On 05/10/17 10:15, Jože Mlakar wrote:
> Also, before you comment, read
> https://github.com/keycloak/keycloak/pull/1644
>
> I believe there is no harm in skip_auth_mechanisms query parameter. I
> agree there are scenarios where other options are also good, but not
> globally.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
7:20 p.m.
Understood, I have the changes for option 1 ready, however it’s usablity is very limited.
As was noted by one of the developers the pressure is now on the clients to decide if and
when to use the skip_auth_mechanisms. In case of keycloak.js client the client is forced
to use some sort of storage (cookie) to rembember that the user logged of and have the
next login use the new parameter. As said this is ready for a PR but i kind of hate it.
I am on board for option 2. If I get some more devs supporting this option, we will go
ahead and create a PR (separate of option 1?).
Option 3 is a killer for user experience. Users would have no idea why they got a login
screen.
2391
days inactive
2395
days old
4 comments
2 participants
participants (2)
-
Jože Mlakar -
Marek Posolda