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?
On 3 May 2016 at 18:29, Bill Burke <bburke(a)redhat.com> wrote:
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.
So, no failover. I'm not sure i that's something Keycloak should be
responsible for. I'm open to adding it though.
On 5/3/2016 12:19 PM, Josh Cain wrote:
Hi all,
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.
For example, consider a realm with two providers configured:
1. ProviderA, Priority 0
2. ProviderB, Priority1
Where ProviderB is a fall-back mechanism containing the same logical
userbase as ProviderA.
If *user1* 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 *user1* with ProviderA, then fails if the
provider is unsuccessful. Is there a way to failover to ProviderB should
ProviderA become unavailable?
Josh Cain | Software Applications Engineer
*Identity and Access Management*
*Red Hat*
+1 843-737-1735
_______________________________________________
keycloak-user mailing
listkeycloak-user@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
--
Bill Burke
JBoss, a division of Red
Hathttp://bill.burkecentral.com
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user