[keycloak-user] Fallback to secondary federation provider possible?

Wed May 4 00:32:36 EDT 2016

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 at 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
>
> On Tue, May 3, 2016 at 1:17 PM, Stian Thorgersen <sthorger at 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 at 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
>>>
>>> On Tue, May 3, 2016 at 12:35 PM, Stian Thorgersen <sthorger at 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 at 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 at 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 at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> keycloak-user mailing list
>>>> keycloak-user at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160504/457fa08d/attachment-0001.html 