[
https://issues.apache.org/jira/browse/KNOX-3540?focusedWorklogId=1052207&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1052207
]
ASF GitHub Bot logged work on KNOX-3540:
----------------------------------------
Author: ASF GitHub Bot
Created on: 03/Nov/26 16:51
Start Date: 03/Nov/26 16:51
Worklog Time Spent: 10m
Work Description: smolnar82 opened a new pull request, #1480:
URL: https://github.com/apache/knox/pull/1480
[KNOX-3540](https://issues.apache.org/jira/browse/KNOX-3540) - KnoxIDF
LdapUserParamsProvider: honor the configured system password alias, support
user search and memberOf roles
## What changes were proposed in this pull request?
The KnoxIDF LDAP user-parameter provider (`LdapUserParamsProvider`) could
not be pointed at Knox's embedded LDAP server (the LDAP proxy with the
roles-lookup interceptor):
1. **The system password alias value was ignored.** The provider looked up
an alias literally named `user.params.provider.ldap.systemPasswordAlias`
instead of the alias named by the parameter's value, so the bind failed (error
49) whenever that literal alias held a different credential.
2. **Users could only be fetched with a base-object search** on the DN built
from `userDnTemplate`. The embedded LDAP server rejects that for entries served
by the proxied backend (`ERR_648 Invalid search base`), while a subtree search
works.
3. **Roles were only resolved by a `member=<userDn>` group search.** The
embedded LDAP server exposes the user's roles via `memberOf`; its group entries
carry no `member`, so no roles ended up in the token.
Changes:
- `user.params.provider.ldap.systemPasswordAlias` is now the **name** of the
alias holding the system password. It defaults to the legacy literal alias
name, so existing deployments keep working. A missing alias produces an error
that names the alias.
- New `user.params.provider.ldap.userSearchBase` and
`user.params.provider.ldap.userSearchFilter` (default `(uid={0})`): when a
search base is set, the user is found with a subtree search (the filter
argument is escaped by JNDI). Without it, the existing `userDnTemplate` lookup
is used unchanged.
- `memberOf` is requested along with the other attributes. When present, the
roles are the `cn` of each group DN directly under `ou=groups,<baseDn>`, the
same groups the existing group search considers. Otherwise the provider falls
back to the group search.
- Docs: `knox-site/docs/knoxidf/configuration.md` documents the new
parameters, the alias semantics, role resolution, and an example for the
embedded LDAP server:
```xml
<param><name>user.params.provider.ldap.url</name><value>ldap://localhost:10389</value></param>
<param><name>user.params.provider.ldap.baseDn</name><value>dc=proxy,dc=com</value></param>
<param><name>user.params.provider.ldap.userSearchBase</name><value>ou=people,dc=proxy,dc=com</value></param>
<param><name>user.params.provider.ldap.systemUser</name><value>uid=proxy-user,ou=people,dc=proxy,dc=com</value></param>
<param><name>user.params.provider.ldap.systemPasswordAlias</name><value>gateway_ldap_bind_password</value></param>
```
## How was this patch tested?
- New LdapUserParamsProviderTest (mocked LdapContext/AliasService):
- the alias name is read from the config
- the legacy alias name is used when the param is not set
- subtree search with userSearchBase and roles from memberOf; groups
outside ou=groups,<baseDn>, nested groups and invalid DNs are ignored, and no
group search is issued
- userDnTemplate base-object read with the group-search fallback
(case-insensitive member match)
- user not found returns no parameters
- mvn -pl gateway-service-knoxidf verify: all module tests pass, and
checkstyle, PMD, SpotBugs and forbidden-apis are clean.
- Manual end-to-end test on a Kubernetes deployment: the token topology's
KNOXIDF service used the config above against the embedded LDAP server, with
the REST roles-lookup strategy. An authorization-code + PKCE flow (client
registration, /authorize, /token with code_verifier, /userinfo) returned an
access token and userinfo response with name, given_name, family_name, email
and the roles resolved by the roles-lookup interceptor. Before the change, the
same flow failed with HTTP 500 (LDAP: error code 49 for the system user).
Issue Time Tracking
-------------------
Worklog Id: (was: 1052207)
Remaining Estimate: 0h
Time Spent: 10m
> KnoxIDF LdapUserParamsProvider ignores the configured system password alias
> and cannot look up users in Knox's embedded LDAP server
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: KNOX-3540
> URL: https://issues.apache.org/jira/browse/KNOX-3540
> Project: Apache Knox
> Issue Type: Task
> Components: KnoxIDF
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
> Priority: Major
> Fix For: 3.1.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The KnoxIDF LDAP user-parameter provider ({{LdapUserParamsProvider}}) cannot
> be pointed at Knox's embedded LDAP server (the LDAP proxy with the
> roles-lookup interceptor), and it has problems with other directories too:
> # *The system password alias value is ignored.* The provider looks up an
> alias literally named {{user.params.provider.ldap.systemPasswordAlias}}, not
> the alias named by that parameter's value. A topology that sets e.g.
> {{<value>gateway_ldap_bind_password</value>}} has no effect, and the bind
> fails with error code 49 when the literal alias holds a different credential.
> # *Users can only be fetched with a base-object search.* The provider builds
> the user DN from {{userDnTemplate}} and runs a base-object search on it. The
> embedded LDAP server rejects that for entries served by the proxied backend
> ({{LdapNoSuchObjectException: ERR_648 Invalid search base}}). It also doesn't
> work for directories where users are not under a single, predictable DN.
> # *Roles are only resolved by a group search ({{member=<userDn>}}).* The
> embedded LDAP server exposes the user's groups/roles via {{memberOf}}, and
> its group entries carry no {{member}} attribute, so the token gets no roles.
> h3. Proposed fix
> * Treat {{user.params.provider.ldap.systemPasswordAlias}} as the *name* of
> the alias. It defaults to the legacy literal name for backward compatibility.
> If the alias is missing, report a clear error.
> * Add {{user.params.provider.ldap.userSearchBase}} and
> {{user.params.provider.ldap.userSearchFilter}} (default {{(uid=\{0\})}}).
> When a search base is set, users are found with a subtree search. Otherwise
> the existing {{userDnTemplate}} base-object lookup is kept.
> * Request {{memberOf}} along with the other user attributes. When it is
> present, the roles are the {{cn}} values of the group DNs directly under
> {{ou=groups,<baseDn>}}. When it is absent, fall back to the existing group
> search.
> Example: pointing KnoxIDF at the embedded LDAP server:
> {code:xml}
> <param><name>user.params.provider.ldap.url</name><value>ldap://localhost:10389</value></param>
> <param><name>user.params.provider.ldap.baseDn</name><value>dc=proxy,dc=com</value></param>
> <param><name>user.params.provider.ldap.userSearchBase</name><value>ou=people,dc=proxy,dc=com</value></param>
> <param><name>user.params.provider.ldap.systemUser</name><value>uid=proxy-user,ou=people,dc=proxy,dc=com</value></param>
> <param><name>user.params.provider.ldap.systemPasswordAlias</name><value>gateway_ldap_bind_password</value></param>
> {code}
> With this config, the access token and userinfo response contain {{name}},
> {{given_name}}, {{family_name}}, {{email}} and the {{roles}} resolved by the
> roles-lookup interceptor.
> Unit tests and the KnoxIDF configuration docs (LDAP user-parameter provider
> table) will be updated.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
