[keycloak-dev] KEYCLOAK-6225 Support Kerberos auth provider fallback

[Bill Burke]

But maybe I'm not understanding the problem.  JIRA seems to state that
it is one Kerberos realm, and multiple LDAP servers.  That's your
situation too, right?

On Tue, May 8, 2018 at 7:48 AM, Bill Burke <bburke at redhat.com> wrote:
> At first glance, this doesn't look like the correct fix.  Looks like
> the Kerberos Provider is looking for the user in local storage only.
> See line 233 of KerberosFederationProvider.
>
> findOrCreateAuthenticatedUser()
>
>         UserModel user =
> session.userLocalStorage().getUserByUsername(username, realm);
>
> I think you need to change this to
> session.users().getUserByUsername().  This might have fallen through
> the cracks when we ported to the new user storage SPI.
>
> On Tue, May 8, 2018 at 5:04 AM, Jim Groffen <jim.groffen at gmail.com> wrote:
>> Hello folks,
>>
>> I am using Keycloak with multiple Kerberos user federations, and am
>> affected by https://issues.jboss.org/browse/KEYCLOAK-6225 where only the
>> first user federation will attempt Kerberos auth.
>>
>> I tried the solution suggested by Ricardo Zanini in KEYCLOAK-6225, this
>> works great for me.
>>
>> Ricardo's suggestion is to change SPNEGO authenticators in LDAP and
>> Kerberos user federations to return null instead of 'failed' or 'continue'.
>> A null return value causes the UserCredentialStoreManager to continue to
>> the next auth provider instead of failing the Kerberos auth attempt for all
>> providers if the first provider fails.
>>
>> I have tested these changes in my deploy and would like to provide a pull
>> request, but I need some review and maybe a suggestion on how to add a
>> test. The following commit has the changes I've made so far:
>>
>> https://github.com/jgroffen/keycloak/commit/634854748ba40ba20432540ac27f79a3c37874e2
>>
>> Note I've reduced log noise as authentication attempts are expected to fail
>> when the Kerberos provider and user realm don't match.
>>
>> Ricardo had further problems with a false-positive replay attack - my
>> situation is not affected by this problem so I'd like to push ahead with
>> this intermediary fix if possible. I'm unaffected because I have separate
>> realms with no trust, and separate keytab files per federation that contain
>> only the relevant keytab entry.
>>
>> Thanks in advance!
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> --
> Bill Burke
> Red Hat



-- 
Bill Burke
Red Hat