<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 class="gmail_extra"><br><div class="gmail_quote">On 3 May 2016 at 18:29, Bill Burke <span dir="ltr"><<a href="mailto:bburke@redhat.com" target="_blank">bburke@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 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 class="h5"><br>
<br>
<div>On 5/3/2016 12:19 PM, Josh Cain wrote:<br>
</div>
</div></div><blockquote type="cite"><div><div class="h5">
<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 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 href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a></pre><span class="HOEnZb"><font color="#888888">
</font></span></blockquote><span class="HOEnZb"><font color="#888888">
<br>
<pre cols="72">--
Bill Burke
JBoss, a division of Red Hat
<a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a></pre>
</font></span></div>
<br>_______________________________________________<br>
keycloak-user mailing list<br>
<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
<a 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>