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

[Jim Groffen]

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/
> 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
>