<div dir="ltr">I don&#39;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.<div><br></div><div>End of the day I don&#39;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&#39;s better that Michael would develop something custom on top of the authenticator spi, rather than us adding this to Keycloak.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 5 October 2015 at 08:01, Michael Gerber <span dir="ltr">&lt;<a href="mailto:gerbermichi@me.com" target="_blank">gerbermichi@me.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>I don&#39;t like this approach if the <span style="line-height:1.5">&quot;Account Chooser&quot; page is only </span>configurable <span style="line-height:1.5">per realm.</span></div><div><span style="line-height:1.5">Because, </span><span style="line-height:1.5">I think it is a bit annoying if you always have to go over the </span><span style="line-height:1.5">&quot;</span><span style="font-family:&#39;Helvetica Neue&#39;,Helvetica,sans-serif;line-height:22.4px;white-space:pre-wrap">Account Chooser&quot; page.</span></div><div><span style="font-family:&#39;Helvetica Neue&#39;,Helvetica,sans-serif;line-height:22.4px;white-space:pre-wrap">99% of all uses want to log in with their kerberos credentials, there are only a few people which want to switch their account.</span></div><div><br></div><div>But I think your approach is good, if you can enable the &quot;Account Chooser&quot; page per client and not only per realm. </div><div><div class="h5"><div><br></div><div>Am 02. Oktober 2015 um 16:31 schrieb Bill Burke &lt;<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>&gt;:<br><br></div></div></div><div><blockquote type="cite"><div><div><div><div class="h5"><span><span><br><br>On 10/2/2015 5:26 AM, Stian Thorgersen wrote:<br></span></span><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">On 1 October 2015 at 20:49, Bill Burke &lt;<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a></blockquote><blockquote type="cite">&lt;mailto:<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>&gt;&gt; wrote:</blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Sorry for late reply.</blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">On 10/1/2015 3:13 AM, Stian Thorgersen wrote:</blockquote><blockquote type="cite">&gt; * If a user that was logged in using Kerberos logs out the user should</blockquote><blockquote type="cite">&gt; not just be automatically logged-in again for the current browser</blockquote><blockquote type="cite">&gt; session. Instead the user should be displayed with a regular</blockquote><blockquote type="cite">&gt; username/password field, but also with an option to login with Kerberos</blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Don&#39;t like this idea.</blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">#1 Users that want to bypass kerberos have to know to logout first so</blockquote><blockquote type="cite">they can login as a non-kerberos user.</blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">#2 username/password screen would have to have knowledge that kerberos</blockquote><blockquote type="cite">is turned on and that the user was logged in via kerberos. I&#39;m don&#39;t</blockquote><blockquote type="cite">think this is possible with the current SPI.</blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Could we not have a selector or something in the authentication flow</blockquote><blockquote type="cite">that can select which authenticator to use? The selector could even be</blockquote><blockquote type="cite">allowed to prompt the user for input, so we could implement a &quot;Is this</blockquote><blockquote type="cite">you&quot; selector.</blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">&gt; * A variant on the above where if a user has logged-out from Kerberos</blockquote><blockquote type="cite">&gt; the user would be displayed with a &quot;Is this you?&quot; when login, if the</blockquote><blockquote type="cite">&gt; user selects yes the Kerberos authenticator would continue, if not the</blockquote><blockquote type="cite">&gt; regular username/password form would be displayed</blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">This one might be easy to do with current SPI although not sure if</blockquote><blockquote type="cite">kerberos plugin sets some session variables that need to be cleared.</blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I was assuming that this option would also require user to logout first.</blockquote><blockquote type="cite">&quot;Is this you&quot; would only be displayed after a logout.</blockquote><blockquote type="cite"><br></blockquote><span><span><br>I don&#39;t like this &quot;logout required&quot; thing and the logout cookie. What <br>is the big deal about having a screen &quot;You are already logged in via <br>Kerberos. Do you want to continue? Or log in as a different user?&quot; <br>This would be something that is optionally turned on and shown after the <br>Kerberos/SPNEGO handshake.<br><br><br></span></span><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">&gt; * Implement account switcher - where a user can login to multiple</blockquote><blockquote type="cite">&gt; accounts at a time and select which account to use</blockquote><blockquote type="cite">&gt;</blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Not sure how this is different than &quot;Is this you?&quot;.</blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">&quot;Is this you&quot; would simply prompt the user if the user is the user that</blockquote><blockquote type="cite">previously logged in from that browser.</blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Account switcher would allow a user to be signed-in to Keycloak with</blockquote><blockquote type="cite">multiple accounts and provide some mechanism for applications to select</blockquote><blockquote type="cite">which account. Like GMail and others allow you to be logged-in to</blockquote><blockquote type="cite">multiple accounts at a time.</blockquote><blockquote type="cite"><br></blockquote><span><span><br><br>Again, this is very similar to the &quot;Is this you?&quot;. The steps would be:<br><br>1. SPNEGO handshake successful<br>2. Show account switcher page with kerberos user as only choice.<br><br>The only need for a logout persistent cookie is to remember successful <br>logins.<br><br>I would like this approach the best.<br><br><br></span></span><blockquote type="cite"><br></blockquote><blockquote type="cite">&gt; Other ideas? Points for ideas that requires no hacks in applications ;)</blockquote><blockquote type="cite">&gt;</blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">idp_hint is a much different animal, isn&#39;t it? idp_hint is provided by</blockquote><blockquote type="cite">the application. skip_auth_mechanism would be something the user has to</blockquote><blockquote type="cite">know about to type in the URL right?</blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">We should never have added idp_hint in the first place IMO. It leaks</blockquote><blockquote type="cite">authentication semantics into applications and also only works if user</blockquote><blockquote type="cite">is not logged in already.</blockquote><blockquote type="cite"><br></blockquote><span><span><br>idp_hint is a good thing. If an app integrates with Facebook, they&#39;ll <br>need to force the user to login via Facebook so they can obtain a <br>Facebook token.<br><br></span></span><blockquote type="cite">skip_auth_mech could be implemented in applications as well</blockquote><blockquote type="cite">but my same</blockquote><blockquote type="cite">point stands here. It requires applications to be aware of</blockquote><blockquote type="cite">authentication semantics. It seems that what&#39;s being proposed here is</blockquote><blockquote type="cite">that admins manually add it to the login URL though, but that&#39;s just a</blockquote><blockquote type="cite">horrible idea, period.</blockquote><blockquote type="cite"><br></blockquote></div></div><span><div><div class="h5"><br>skip_auth_mech is the opposite of auth_mechs_required. Something that I <br>believe SAML has.<br><br></div></div><span class="">-- <br>Bill Burke<br>JBoss, a division of Red Hat<br><a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a><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" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br></span></span></div></div></blockquote></div></div></blockquote></div><br></div>