<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 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><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 href="http://redhat.com" target="_blank">redhat.com</a>. When I have kerberos ticket, I can
never see the login screen on <a 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><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 href="mailto:gerbermichi@me.com" target="_blank">gerbermichi@me.com</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 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 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 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 href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><br>
<a 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 href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>
<a 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>