On 01/10/15 09:13, Stian Thorgersen wrote:
I don't like the query param approach as it requires somehow
adding
the query param to specify what authenticators to skip. This would
have to be added to applications themselves and with Keycloak the
whole idea is that applications shouldn't have to worry about
authentication semantics.
I thing that some applications care about how was user
authenticated :-\
For example when application wants to reuse Kerberos credential from the
SPNEGO authentication to call some other thirdparty kerberos-secured
service, it needs a way to "force" keycloak to authenticate with
Kerberos. Hence it can skip other authenticators and leave just Kerberos.
Similar case is, when application wants to reuse Facebook access token -
in this case application wants to enforce login with Facebook. For this
case, we already have kc_idp_hint parameter, which also requires support
on the application side . Isn't it similar to the query parameter
skip_auth_mechanisms ?
I might be wrong, but maybe some Keycloak users don't care too much
about SSO. The added value for them is provisioning of users and the
fact, that they don't need to implement Facebook or Kerberos
authentication, but Keycloak implements it for them. So they may want
some control on the application side how is user authenticated.
We need a generic mechanism to be able to skip any authenticators
that
automatically log in a user. Currently this is only Kerberos, but in
the future we could add more, including an option to automatically
route to external IdPs.
For external IdPs, we already have "Authenticate by
Default" switch on
identity providers. We also have kc_idp_hint parameter as I mentioned above.
Ignoring implementation semantics for now, but taking Kerberos as the
example authenticator I can see some options (in the example below
replace 'Kerberos' with any other authentication method that can
automatically login a user):
* 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
* 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
+1 to support "Is this
you" screen. However maybe this should be
configurable as some deployments may not want to display the screen, but
want to relogin automatically.
Classic example is
redhat.com. When I have kerberos ticket, I can never
see the login screen on
saml.redhat.com . If we enforce adding "Is this
you", some employees may complain "Hey, why there is another splash
screen I need to click. Why I am not logged automatically" etc. But
maybe I am wrong here. Maybe good opportunity to ask IT guys on the call
today as they have experience with the real world scenarios ;-)
Conclusion of my point of view: Add variable support for "Is this you"
screen and in addition have the support for skip_auth_mechanism Michael
implemented.
Marek
* Implement account switcher - where a user can login to multiple
accounts at a time and select which account to use
Other ideas? Points for ideas that requires no hacks in applications ;)
On 30 September 2015 at 15:39, Michael Gerber <gerbermichi(a)me.com
<mailto:gerbermichi@me.com>> wrote:
Hi all,
I would like to use kerberos as my standard authentication
mechanism, but I also want to have the possibility to log in as an
admin over the login form.
Therefore, I want to skip the kerberos authenticator after a
successful logout.
https://issues.jboss.org/browse/KEYCLOAK-1727
How would you solve this problem?
I've got two solutions, one sets a logout session cookie after a
logout and then skips the kerberos authentication and another
which allows users to skip any kind of alternative authenticators
with a query parameter.
Logout Session Cookie
https://github.com/gerbermichi/keycloak/commit/f804d9e13573cb666cf6d2eff1...
Query Param
https://github.com/gerbermichi/keycloak/commit/abd3bd87f5aa4c28914da67765...
Michael
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev