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(a)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/634854748ba40ba20432540ac27f7...
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
Red Hat