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

[Marek Posolda]

+1 for the fix like this.

I think the performance won't be big issue as SPNEGO authenticator on 
Keycloak side calls "gssContext.acceptSecContext" which itself is 
offline validation and doesn't need to talk to Kerberos server. I will 
need to doublecheck this. There will be some minor performance penalty 
as more providers will need to be tried, but that's always the case when 
you have more providers (EG. when you have 5 userStorage providers and 
you call "getUserByEmail", you can fail 4 providers until user is found 
in 5th provider).

Also we may finally need performance tests for SPNEGO (and LDAP) 
scenarios, but that's another topic.

IMO the fix itself won't be hard, but biggest effort would be automated 
test. We may need to add test with multiple Kerberos servers. Also make 
sure that it works not just with default ApacheDS, but with MSAD etc. 
But maybe it's sufficient as the 2nd server to always use ApacheDS? Will 
be good to test also the scenario with same Kerberos server and multiple 
LDAP providers to check the replay issue. Also to check that it works 
for both LDAP provider and Kerberos provider.

Marek

Dne 8.5.2018 v 14:22 Bill Burke napsal(a):
> 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
>
>