<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 12:04, Stian Thorgersen
wrote:<br>
</div>
<blockquote
cite="mid:CAJgngAeeafzh1O0wGmeDwOgD4wOBUtUVZ=XNj+1TGiY=QrQExg@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 1 October 2015 at 11:42, 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:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><span class="">
<div>On 01/10/15 10:59, Stian Thorgersen wrote:<br>
</div>
<blockquote 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"><a class="moz-txt-link-abbreviated" href="mailto:mposolda@redhat.com">mposolda@redhat.com</a></a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><span>
<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:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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>
</span> 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).</div>
</blockquote>
<div><br>
</div>
<div><span style="font-size:12.8px">I'm not a big fan of </span><span
style="font-size:12.8px">kc_idp_hint either ;)</span></div>
<div><span style="font-size:12.8px"><br>
</span></div>
<div>"skip_auth_mech" would be a horrible way to enforce a
specific auth mechanism. What if you add another
mechanism? What if user is already logged-in? It's just
not something that should be added without thinking about
the corner cases. Then there are also similar things baked
into OIDC to consider (<font face="verdana, charcoal,
helvetica, arial, sans-serif" color="#000000">acr, amr,
id_token_hint, etc..).</font><br>
</div>
<div><font face="verdana, charcoal, helvetica, arial,
sans-serif" color="#000000"><br>
</font></div>
<div><font face="verdana, charcoal, helvetica, arial,
sans-serif" color="#000000">As we have loads of things
to do and skip_auth_mech is not something that anyone
has requested, except for in this use-case. Where I'm
arguing that it's a bad way to do it. We shouldn't add
it now as it's a work around/hackish solution that we
haven't fully considered.</font></div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><span class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><span><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><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>
</span> I imagine I have 10 tabs opened in my browser. I
want to close the tab with <a moz-do-not-send="true"
href="http://mojo.redhat.com" target="_blank">mojo.redhat.com</a>
and before that, I automatically click on "logout" .
After few minutes, I want again to do something
different for example in calendar. <a
moz-do-not-send="true" href="http://redhat.com"
target="_blank">redhat.com</a> 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><span>
:-) </span></span></div>
</blockquote>
<div><br>
</div>
<div>Really? I just don't see that as a problem. 99.999% of
the time the user won't see any splash screen as they will
just login and that's that. For the times when someone
logs out I just can't see it being a huge problem that
they get a "is this you" prompt.</div>
<div><br>
</div>
<div>If someone is really that bothered about the splash
screen let them tell us and we can add an option, but
there's no point in filling the admin console up with all
sorts of unused toggles.</div>
</div>
</div>
</div>
</blockquote>
Ok, I agree it's better to add additional toggles just when someone
requests it. I just bet this request will come <span
class="moz-smiley-s1"><span> :-) </span></span><br>
<br>
Marek<br>
<blockquote
cite="mid:CAJgngAeeafzh1O0wGmeDwOgD4wOBUtUVZ=XNj+1TGiY=QrQExg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><br>
<span class=""><font color="#888888"> <br>
Marek</font></span>
<div>
<div class="h5"><br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><span><font
color="#888888"><br>
<br>
Marek</font></span><span><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:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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"><a class="moz-txt-link-freetext" href="https://issues.jboss.org/browse/KEYCLOAK-1727">https://issues.jboss.org/browse/KEYCLOAK-1727</a></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"><a class="moz-txt-link-freetext" href="https://github.com/gerbermichi/keycloak/commit/f804d9e13573cb666cf6d2eff1407978c9e5e854">https://github.com/gerbermichi/keycloak/commit/f804d9e13573cb666cf6d2eff1407978c9e5e854</a></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"><a class="moz-txt-link-freetext" href="https://github.com/gerbermichi/keycloak/commit/abd3bd87f5aa4c28914da677653268c0f44fe6cc">https://github.com/gerbermichi/keycloak/commit/abd3bd87f5aa4c28914da677653268c0f44fe6cc</a></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>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</body>
</html>