Use an original domain name of Kerberos Principal in UserModel attrib… #22516
Conversation
1 flaky test on run #8715 ↗︎Details:
|
|||||||||||||||||||||
| Test | Artifacts | |
|---|---|---|
| Realm settings general tab tests > Test all general tab switches |
Output
Screenshots
|
|
This comment has been generated by cypress-bot as a result of this project's GitHub integration settings.
common/src/main/java/org/keycloak/common/constants/KerberosConstants.java
Show resolved
Hide resolved
jonkoops
left a comment
There was a problem hiding this comment.
Changes on the client side look good to me.
sguilhen
left a comment
There was a problem hiding this comment.
From a storage perspective, the changes also look good to me
…ute instead of configured value of Kerberos realm in User federation closes keycloak#20045
73cef0e to
5b85a0a
Compare
mposolda
left a comment
There was a problem hiding this comment.
@pedroigor I've rebased the PR and also updated per your suggestion. Could you please review again?
common/src/main/java/org/keycloak/common/constants/KerberosConstants.java
Show resolved
Hide resolved
|
Looks like this PR has enough approval to be merged. Are we still waiting on a specific reviewer? |
|
@jonkoops - the first comment asks for feedback from @andymunro about the docs, and from @miquelsi about testing other LDAP servers. While docs could be handled in a follow-up PR, I'm hesitant about the test around the other LDAP servers. If the test configurations for other LDAP servers could be handled in another PR should be decided by @mposolda or @miquelsi. |
|
Thanks everyone for the review! @ahus1 I agree that documentation can be addressed in a follow-up if needed. Regarding testing, I've tested with our LDAP pipeline and created the PR to our LDAP configuration (will send the details offline). |
…ute instead of configured value of Kerberos realm in User federation
closes #20045
This PR addresses issue when single LDAP/Kerberos provider allows to authenticate users from multiple kerberos realms (which are in trust among each other). It does somehow what is mentioned here #20045 (comment) . Despite the last point with the fallback between multiple LDAP storage providers, which is different issue and handled in the PR #22531 (Both are related to trust scenarios, but that one is multiple LDAP providers to single kerberos realm when this one is possibly single LDAP provider to multiple Kerberos realms).
The
SPNEGOAuthenticatorreturns whole authenticated kerberos principal without cutting realm from it, so LDAP provider is able to lookup proper user based on the kerberos principal. The LDAP attribute where Kerberos principal is saved unfortunately differs among LDAP servers, so added configuration optionKerberos principal attributeto have some flexibility here.The
KerberosFederationProvideruses whole authenticated principal instead of just username chained with configured realm, which ensures that correct realm is used.For backwards compatibility, when the attribute is left empty, it sticks to the previous behaviour and tries to find the LDAP user with same username as the prefix of kerberos principal without realm. This might be needed as it is possible that some LDAP servers don't support specific attribute with kerberos principal name (however looks that all LDAP servers we support have this).
@ahus1 Could you please review from the store team or delegate to someone?
@ssilvert Could you please review the UI related changes or delegate to someone from the UI team?
@andymunro Could you please review documentation changes?
@miquelsi Adding you as reviewer too as this can be needed to be tested with our LDAP pipeline though to make sure it works with all our LDAP servers. It's possible that some new things would need to be added to the properties files, which we use in LDAP pipeline. For MSAD, the property file might need:
And for RHDS/FreeIPA maybe something like this (not 100% sure about the attribute name in RHDS, just tried FreeIPA):