[
https://issues.apache.org/jira/browse/KNOX-3490?focusedWorklogId=1044046&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1044046
]
ASF GitHub Bot logged work on KNOX-3490:
----------------------------------------
Author: ASF GitHub Bot
Created on: 25/Sep/26 15:41
Start Date: 25/Sep/26 15:41
Worklog Time Spent: 10m
Work Description: smolnar82 opened a new pull request, #1431:
URL: https://github.com/apache/knox/pull/1431
[KNOX-3490](https://issues.apache.org/jira/browse/KNOX-3490) - Fix LDAP
roles lookup using the wrong username when the client omits the uid attribute
## What changes were proposed in this pull request?
`LDAPRolesLookupInterceptor` derived the roles-lookup identity from entry
*attributes* (`uid`, `cn`). Because the entry is trimmed to the attributes the
client requested, a client that omits `uid` (e.g. Hadoop `LdapGroupsMapping`)
left only `cn`, so the lookup was keyed on a display name and returned the
wrong roles. The username is now taken from the entry's DN (always present),
falling back to attributes for non-uid-based DNs.
## How was this patch tested?
- New unit tests in `LDAPRolesLookupInterceptorTest` covering the
trimmed-uid case and the non-uid-DN fallback.
- `mvn -pl gateway-server test -Dtest=LDAPRolesLookupInterceptorTest` → 7/7
pass.
- Manually verified on a running cluster by hot-patching the gateway jar:
the local-cluster path now resolves the correct roles.
## Integration Tests
No integration test added — this is an internal interceptor fix covered by
unit tests.
Issue Time Tracking
-------------------
Worklog Id: (was: 1044046)
Remaining Estimate: 0h
Time Spent: 10m
> LDAPRolesLookupInterceptor resolves the wrong username when the LDAP client
> does not request the uid attribute, causing incorrect role lookups
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: KNOX-3490
> URL: https://issues.apache.org/jira/browse/KNOX-3490
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
> Affects Versions: 3.0.0
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
> Priority: Major
> Fix For: 3.1.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *Background*
> Knox's embedded LDAP server supports a roles-lookup feature:
> {{LDAPRolesLookupInterceptor}} intercepts search results, derives the user's
> identity from the returned entry, calls the configured roles-lookup service
> with that identity, and rewrites the entry's {{memberOf}} values to reflect
> the resolved roles.
> In a federated topology this embedded LDAP on a _central_ cluster is queried
> by a _local_ cluster. The _local_ cluster resolves groups/roles via Hadoop's
> {{LdapGroupsMapping}} (through {{{}HadoopGroupProviderFilter{}}}), connecting
> to the central cluster's embedded LDAP over LDAPS.
> *The bug*
> The interceptor derives the username with:
> {code:java}
> final String username = LdapUtils.extractUsernameFromEntry(entry, "uid",
> "cn");{code}
> {{extractUsernameFromEntry}} reads attribute values from the entry, but the
> entry has already been trimmed to the attributes the client requested.
> {{LdapGroupsMapping}} requests only the attributes it needs for group
> resolution (e.g. {{{}memberOf{}}}/{{{}group-name{}}} attributes) and does
> *not* request {{{}uid{}}}. As a result, by the time the interceptor runs, the
> {{uid}} attribute is gone and the code falls back to {{{}cn{}}}, which is a
> human-readable display name rather than the stable login id.
> The roles-lookup service is then called with the display name instead of the
> {{{}uid{}}}, and returns the wrong set of roles (or none).
> *Observed behavior*
> For the same user, two paths produce different results against the same
> roles-lookup service:
> ||Path 1||Attributes requested||user_id sent to lookup||Roles returned||
> |_Central_ cluster (requests all attributes, *)|includes uid|<uid> (e.g.
> [email protected])|correct (e.g. 4 roles)|
> |_Local_ cluster via {{LdapGroupsMapping}}|uid *not* requested|cn display
> name (e.g. John Doe)|wrong (e.g. 1 role)|
> *Root cause*
> The username is read from an attribute that may be absent depending on what
> the client requested. The entry's DN ({{{}uid=…,ou=…{}}}), however, is always
> present regardless of the requested attribute set, and already carries the
> stable {{uid}} in its RDN.
> *Steps to Reproduce*
> 1. Configure Knox's embedded LDAP with roles lookup enabled.
> 2. Perform an LDAP search that requests only group-related attributes and
> omits {{uid}} (as Hadoop {{LdapGroupsMapping}} does).
> 3. Observe that the roles-lookup call is keyed on the {{cn}} display name,
> returning the wrong roles.
> 4. Repeat the search requesting * (all attributes) and observe the correct
> roles - confirming the discrepancy is driven purely by which attributes the
> client requested.
> *Expected Behavior*
> Role lookup is keyed on the stable {{uid}} regardless of which attributes the
> client requested, so all clients receive a consistent set of roles for the
> same user.
> *Proposed Fix*
> Derive the username from the entry's DN first (always present), falling back
> to entry attributes only if the DN does not yield a uid:
> {code:java}
> String username = LdapUtils.extractUsernameFromDn(entry.getDn());
> if (username == null) {
> username = LdapUtils.extractUsernameFromEntry(entry, "uid", "cn");
> }{code}
> {{LdapUtils.extractUsernameFromDn}} returns the RDN value when the RDN type
> is {{{}uid{}}}, which is immune to attribute trimming. The fallback preserves
> existing behavior for entries whose DN is not uid-based.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
