2:22 p.m.
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(a)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(a)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(a)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(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
>
>
>
> --
> Bill Burke
> Red Hat
--
Bill Burke
Red Hat
--
Bill Burke
Red Hat