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

Wed May 9 04:41:22 EDT 2018

Hello again Bill,

My problem is not related to KEYCLOAK-6225 although the solution is very
similar. Apologies for the confusion, I'll start a new thread relating to
my issue.

I am happy to help with KEYCLOAK-6225, and concur that your fix looks right
for that issue, barring the replay detection issue. I don't have an easy
way to test it unfortunately.

Cheers,

On 9 May 2018 at 10:03, Jim Groffen <jim.groffen at gmail.com> wrote:

> Hello Bill,
>
> Thanks for the prompt responses, apologies for delayed response, I'm
> down-under!
>
> The original issue is as you said, one Kerberos realm, and multiple LDAP
> servers.
>
> My situation is different though, I have multiple Kerberos realms, realm A
> as first priority and realm B as second. I get a checksum fails exception
> when validating a service ticket from realm B against the keytab for realm
> A. This currently stops Kerberos authentication from falling through to the
> next auth provider - realm B.
>
> We are actually looking at N kerberos realms, potentially adding and
> removing realms over time, so managing keytabs separately is preferred for
> us, but optimising service ticket validation is a good point.
>
> I'm also more likely to use the Kerberos federation provider than the LDAP
> federation provider with Kerberos enabled, but both providers are affected
> by this issue, so I'm suggesting a fix for both.
>
> I'll incorporate your changes and let you know how I go.
>
> Thanks again Bill,
>
> On 8 May 2018 at 21:52, Bill Burke <bburke at redhat.com> wrote:
>
>> 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/634854748ba40ba2
>> 0432540ac27f79a3c37874e2
>> >>>>
>> >>>> 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
>>
>
>