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 list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user

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&gt; 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 > _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user

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. On 3 May 2016 at 19:58, Josh Cain <josh.cain(a)redhat.com&gt; wrote: > 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. > > 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. > > @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. > > Josh Cain | Software Applications Engineer > *Identity and Access Management* > *Red Hat* > +1 843-737-1735 > > On Tue, May 3, 2016 at 12:35 PM, Stian Thorgersen <sthorger(a)redhat.com&gt; > wrote: > >> 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&gt; 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 >>> >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > >

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. On 3 May 2016 at 20:52, Josh Cain <josh.cain(a)redhat.com <mailto:josh.cain@redhat.com>> wrote: 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? Josh Cain | Software Applications Engineer /Identity and Access Management/ *Red Hat* +1 843-737-1735 <tel:%2B1%20843-737-1735> On Tue, May 3, 2016 at 1:17 PM, Stian Thorgersen <sthorger(a)redhat.com <mailto:sthorger@redhat.com>> wrote: 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. On 3 May 2016 at 19:58, Josh Cain <josh.cain(a)redhat.com <mailto:josh.cain@redhat.com>> wrote: 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. 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. @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. Josh Cain | Software Applications Engineer /Identity and Access Management/ *Red Hat* +1 843-737-1735 <tel:%2B1%20843-737-1735> On Tue, May 3, 2016 at 12:35 PM, Stian Thorgersen <sthorger(a)redhat.com <mailto:sthorger@redhat.com>> wrote: 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 <mailto:bburke@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 <tel:%2B1%20843-737-1735> > > > _______________________________________________ > keycloak-user mailing list > keycloak-user(a)lists.jboss.org > <mailto:keycloak-user@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/keycloak-user -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/keycloak-user _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/keycloak-user