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

[Bill Burke]

The null return should be line 689 in LDAPStorageProvider.  Logger
should probably be debug instead of warn too.

                    UserModel user =
findOrCreateAuthenticatedUser(realm, username);

                    if (user == null) {
                        logger.warnf("Kerberos/SPNEGO authentication
succeeded with username [%s], but couldn't find or create user with
federation provider [%s]", username, model.getName());
                        return null;// OLD CODE IS ---->
CredentialValidationOutput.failed();

The authenticate method should return null too I believe.  I have to
talk to Marek though about this.  Kerberos token validation would be
redone for each LDAP provider.  I don't know if this is an expensive
operation or not and wonder if it should be optimized


On Tue, May 8, 2018 at 8:07 AM, Bill Burke <bburke at redhat.com> wrote:
> Ugh, sorry...that's not it...Sorry, I haven't looked at this code in a
> long time and I'm not the original author either....
>
> If you are using Kerberos backed by LDAP, then you should not be using
> the KerberosFederationProvider.  You should be enabling kerberos auth
> on your LDAP provider. See this:
>
> https://www.keycloak.org/docs/latest/server_admin/index.html#_kerberos
>
>
> On Tue, May 8, 2018 at 7:59 AM, Bill Burke <bburke at redhat.com> wrote:
>> 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
>
>
>
> --
> Bill Burke
> Red Hat



-- 
Bill Burke
Red Hat