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). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
