<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 01/10/15 10:59, Stian Thorgersen
wrote:<br>
</div>
<blockquote
cite="mid:CAJgngAda+cjaGQeP7rxf_vaxDKj6NPsXKyr4qCgHzwEG+y2T-A@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 1 October 2015 at 10:26, Marek
Posolda <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:mposolda@redhat.com" target="_blank">mposolda@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><span class="">
<div>On 01/10/15 09:13, Stian Thorgersen wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">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.</div>
</blockquote>
</span> I thing that some applications care about how
was user authenticated <span><span> :-\ </span></span></div>
</blockquote>
<div><br>
</div>
<div>Maybe, but that's not the case in this use-case. In
this case we simply want to use another user than the
automatically logged-in user. So skip_auth_mech just
becomes a work around/hack rather than a proper solution</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><br>
<br>
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. <br>
<br>
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 ?<br>
</div>
</blockquote>
<div><br>
</div>
<div>Those situations are much more advanced than this
use-case. In those case you'd have to have some form of a
additional authenticators. For example if an app needs
Facebook token they would need the user to authenticate
with Facebook whether or not the user is already
authenticated. This becomes quite tricky, especially if
the user is already logged-in and logs in with FB as
another user. But, that's not what this use case is about
and we haven't had a request for this, so no need to
consider it now.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"> <br>
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.</div>
</blockquote>
<div><br>
</div>
<div>SSO or not, it's still the same concept of moving
authentication semantics away from apps to the
authentication server.</div>
</div>
</div>
</div>
</blockquote>
TBH I am still not seeing why kc_idp_hint parameter support is ok,
but skip_auth_mech is not. In both cases, it's the application which
wants to control the behaviour somehow. Skip_auth_mech can be used
to skip some mechanism, but also to enforce login with some
mechanism (skip all other mechanisms besides the one required).<br>
<br>
<blockquote
cite="mid:CAJgngAda+cjaGQeP7rxf_vaxDKj6NPsXKyr4qCgHzwEG+y2T-A@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><span class=""><br>
<blockquote type="cite">
<div dir="ltr">
<div>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.</div>
</div>
</blockquote>
</span> For external IdPs, we already have "Authenticate
by Default" switch on identity providers. We also have
kc_idp_hint parameter as I mentioned above.<span
class=""><br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>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):</div>
<div><br>
</div>
<div>* 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</div>
<div>* 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</div>
</div>
</blockquote>
</span> +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.<br>
<br>
Classic example is <a moz-do-not-send="true"
href="http://redhat.com" target="_blank">redhat.com</a>.
When I have kerberos ticket, I can never see the login
screen on <a moz-do-not-send="true"
href="http://saml.redhat.com" target="_blank">saml.redhat.com</a>
. 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 <span><span> ;-) </span></span></div>
</blockquote>
<div><br>
</div>
<div>I don't see why it's a problem that the splash screen
is displayed. The user has decided to log out from the
Kerberos session so it makes no sense whatsoever to
automatically log the user in again. That's basically
disabling the log out.</div>
</div>
</div>
</div>
</blockquote>
I imagine I have 10 tabs opened in my browser. I want to close the
tab with mojo.redhat.com and before that, I automatically click on
"logout" . After few minutes, I want again to do something different
for example in calendar. redhat.com and now I will see the splash
screen when I want to relogin. <br>
<br>
For me, splash screen is not an issue. Not sure about all other
employees... <br>
<br>
Maybe we can add splash screen automatically and add support for a
flag to not display splash screen just when someone requests it.
Again, I can be wrong, but I bet this request will come earlier or
later <span class="moz-smiley-s1"><span> :-) </span></span><br>
<br>
Marek<br>
<blockquote
cite="mid:CAJgngAda+cjaGQeP7rxf_vaxDKj6NPsXKyr4qCgHzwEG+y2T-A@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><br>
<br>
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.</div>
</blockquote>
<div><br>
</div>
<div>If we add is this you screen, then skip_auth_mechanism
is not required for this use case and hence we should not
add it unless specifically requested</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><span class="HOEnZb"><font
color="#888888"><br>
<br>
Marek</font></span><span class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>* Implement account switcher - where a user
can login to multiple accounts at a time and
select which account to use<br>
</div>
<div><br>
</div>
<div>Other ideas? Points for ideas that requires
no hacks in applications ;)</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 30 September 2015 at
15:39, Michael Gerber <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:gerbermichi@me.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:gerbermichi@me.com">gerbermichi@me.com</a></a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div>
<div>Hi all,</div>
<div><br>
</div>
<div>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. </div>
<div>Therefore, I want to skip the kerberos
authenticator after a successful logout.</div>
<div><a moz-do-not-send="true"
href="https://issues.jboss.org/browse/KEYCLOAK-1727"
target="_blank">https://issues.jboss.org/browse/KEYCLOAK-1727</a></div>
<div><br>
</div>
<div>How would you solve this problem?</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Logout Session Cookie</div>
<div><a moz-do-not-send="true"
href="https://github.com/gerbermichi/keycloak/commit/f804d9e13573cb666cf6d2eff1407978c9e5e854"
target="_blank">https://github.com/gerbermichi/keycloak/commit/f804d9e13573cb666cf6d2eff1407978c9e5e854</a></div>
<div><br>
</div>
<div>Query Param</div>
<div><a moz-do-not-send="true"
href="https://github.com/gerbermichi/keycloak/commit/abd3bd87f5aa4c28914da677653268c0f44fe6cc"
target="_blank">https://github.com/gerbermichi/keycloak/commit/abd3bd87f5aa4c28914da677653268c0f44fe6cc</a></div>
<span><font color="#888888">
<div><br>
</div>
<div>Michael</div>
</font></span></div>
<br>
_______________________________________________<br>
keycloak-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:keycloak-dev@lists.jboss.org"
target="_blank">keycloak-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/keycloak-dev"
rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
keycloak-dev mailing list
<a moz-do-not-send="true" href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>
<a moz-do-not-send="true" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
</blockquote>
<br>
</span></div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</body>
</html>