<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">I am also not sure whether to support
it in Keycloak OOTB rather then implement fallback in the
federationProvider itself... Maybe we can add it just if more
people asks for it? Every usecase we support is nice, but on the
other hand, it usually introduces some additional complexity :/<br>
<br>
Marek<br>
<br>
On 03/05/16 20:17, Stian Thorgersen wrote:<br>
</div>
<blockquote
cite="mid:CAJgngAca-OrOy5tem7PBdS+-AwfetJD5QwTbo6bSenpm-z9fRg@mail.gmail.com"
type="cite">
<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 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">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">
<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 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
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">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>
<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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
keycloak-user mailing list
<a class="moz-txt-link-abbreviated" href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-user">https://lists.jboss.org/mailman/listinfo/keycloak-user</a></pre>
</blockquote>
<br>
</body>
</html>