<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Yes, if you configure Kerberos
authenticator as "ALTERNATIVE" in the Authentication tab in admin
console, then SPNEGO login is done automatically just if user has
kerberos ticket. Otherwise he will be switched to next
authenticator in the chain (by default it's form, so showing
classic username/password form).<br>
<br>
Marek<br>
<br>
On 04/05/16 06:32, Stian Thorgersen wrote:<br>
</div>
<blockquote
cite="mid:CAJgngAejV9Am0x_0P_uXCN-L0M+FZOqr_RkwDP0h1ugQBNEuxQ@mail.gmail.com"
type="cite">
<div dir="ltr">If Kerberos ticket is unavailable the
username/password login form should be displayed. If you have
LDAP configured username/password should be checked against
this. That's the default behavior AFAIK.</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 3 May 2016 at 20:52, Josh Cain <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:josh.cain@redhat.com" target="_blank">josh.cain@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 dir="ltr">How does something a little more common like
a Kerberos/LDAP failover work. I.E. if users have their
kerberos ticket sometimes, but not all the time, how would
we configure KC to use the kerb ticket when available and
otherwise LDAP?<br>
</div>
<div class="gmail_extra"><span class=""><br clear="all">
<div>
<div>
<div dir="ltr"><span>
<div>
<div>Josh Cain | Software Applications
Engineer<br>
</div>
<i>Identity and Access Management</i><br>
</div>
<b>Red Hat</b><br>
<a moz-do-not-send="true"
href="tel:%2B1%20843-737-1735"
value="+18437371735" target="_blank">+1
843-737-1735</a><br>
</span></div>
</div>
</div>
<br>
</span>
<div>
<div class="h5">
<div class="gmail_quote">On Tue, May 3, 2016 at 1:17
PM, Stian Thorgersen <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:sthorger@redhat.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:sthorger@redhat.com">sthorger@redhat.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 dir="ltr">Makes more sense now. In theory it
should be relatively easy to add something like
that, as you're just saying if this provider is
unavailable use this other one and you're
guaranteeing that the users will be the same. As
you say though I'm not sure that's a very common
use-case and supporting failover through a
single provider would be more common.</div>
<div>
<div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 3 May 2016 at
19:58, Josh Cain <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:josh.cain@redhat.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:josh.cain@redhat.com">josh.cain@redhat.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 dir="ltr">
<div>
<div>
<div>
<div>Long story short, it's the
same user base, but exposed in
a completely different way (as
opposed to exactly the same
services set in something like
different data centers). As
such, we thought two separate
Federation Providers were
appropriate, but now have
realized that the failover
case described above isn't
covered.<br>
<br>
</div>
I know this is a pretty
non-standard use. We're in the
middle of a migration of our
services layer, so we're kind of
an outlier when it comes to
typical usage patterns. We've
talked through simply handling
this failover manually using a
single provider, and we can by
with that for now, but we're
looking ahead at some similar
use cases that might experience
the same problem.<br>
</div>
<br>
</div>
@Bill I think some kind of stackable
configuration like the
authenticators have could be really
useful for us. If we could mark
providers as 'alternative' or
'optional' in the same way it would
give us what we need. Anyway, just
an idea. At the end of the day I
think we're after a way to customize
the way in which federation
providers interact with one another
(or don't), whatever that looks
like.<br>
</div>
<div>
<div class="gmail_extra"><span><br
clear="all">
<div>
<div>
<div dir="ltr"><span>
<div>
<div>Josh Cain |
Software
Applications
Engineer<br>
</div>
<i>Identity and Access
Management</i><br>
</div>
<b>Red Hat</b><br>
<a
moz-do-not-send="true"
href="tel:%2B1%20843-737-1735" value="+18437371735" target="_blank">+1
843-737-1735</a><br>
</span></div>
</div>
</div>
<br>
</span>
<div>
<div>
<div class="gmail_quote">On
Tue, May 3, 2016 at 12:35
PM, Stian Thorgersen <span
dir="ltr"><<a
moz-do-not-send="true"
href="mailto:sthorger@redhat.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:sthorger@redhat.com">sthorger@redhat.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 dir="ltr">With the
current user federation
strategy we have
wouldn't this type of
failover be implemented
in the user federation
provider itself? You're
not actually "falling"
back to another
provider, it's the same
provider, but the slave
replica right?</div>
<div>
<div>
<div
class="gmail_extra"><br>
<div
class="gmail_quote">On
3 May 2016 at
18:29, Bill Burke
<span dir="ltr"><<a
moz-do-not-send="true" href="mailto:bburke@redhat.com" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:bburke@redhat.com">bburke@redhat.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
bgcolor="#FFFFFF"
text="#000000">
We don't have
anything like
that.
Keycloak
assumes that
username is
unique in a
federation.
Before
validating
credentials it
goes through
federation
list. The
first provider
that finds a
user of that
username will
have
credentials
validated
against it.<br>
<br>
So, no
failover. I'm
not sure i
that's
something
Keycloak
should be
responsible
for. I'm open
to adding it
though.
<div>
<div><br>
<br>
<div>On
5/3/2016 12:19
PM, Josh Cain
wrote:<br>
</div>
</div>
</div>
<blockquote
type="cite">
<div>
<div>
<div dir="ltr">
<div>
<div>Hi all,<br>
<br>
</div>
We're
attempting to
stack a number
of
FederationProviders,
and I was
wondering if
Keycloak
currently
does, or plans
to support
falling back
to a secondary
provider
*after*
another
provider has
already been
used.<br>
<br>
</div>
For example,
consider a
realm with two
providers
configured:<br>
<ol>
<li>ProviderA,
Priority 0</li>
<li>ProviderB,
Priority1</li>
</ol>
<p>Where
ProviderB is a
fall-back
mechanism
containing the
same logical
userbase as
ProviderA.<br>
</p>
<div>
<div>
<div>
<div>If <i>user1</i>
logs into
Keycloak and
is associated
with
ProviderA,
then ProviderA
goes down,
we'd ideally
like for
ProviderB to
be able to
authenticate
the user.
Right now, all
our Keycloak
instance does
is attempt to
authenticate <i>user1</i>
with
ProviderA,
then fails if
the provider
is
unsuccessful.
Is there a way
to failover to
ProviderB
should
ProviderA
become
unavailable?<br>
</div>
<div><br
clear="all">
<div>
<div>
<div dir="ltr"><span>
<div>
<div>Josh Cain
| Software
Applications
Engineer<br>
</div>
<i>Identity
and Access
Management</i><br>
</div>
<b>Red Hat</b><br>
<a
moz-do-not-send="true"
href="tel:%2B1%20843-737-1735" value="+18437371735" target="_blank">+1
843-737-1735</a><br>
</span></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
</div>
</div>
<pre>_______________________________________________
keycloak-user mailing list
<a moz-do-not-send="true" href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.jboss.org</a>
<a moz-do-not-send="true" href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a></pre>
<span><font
color="#888888">
</font></span></blockquote>
<span><font
color="#888888">
<br>
<pre cols="72">--
Bill Burke
JBoss, a division of Red Hat
<a moz-do-not-send="true" href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a></pre>
</font></span></div>
<br>
_______________________________________________<br>
keycloak-user
mailing list<br>
<a
moz-do-not-send="true"
href="mailto:keycloak-user@lists.jboss.org" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a></a><br>
<a
moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/keycloak-user"
rel="noreferrer"
target="_blank"><a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-user">https://lists.jboss.org/mailman/listinfo/keycloak-user</a></a><br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
<br>
_______________________________________________<br>
keycloak-user mailing list<br>
<a moz-do-not-send="true"
href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/keycloak-user"
rel="noreferrer"
target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>