smolnar82 opened a new pull request, #1499: URL: https://github.com/apache/knox/pull/1499
[KNOX-3558](https://issues.apache.org/jira/browse/KNOX-3558) - Role memberOf DNs from the LDAP proxy, configurable groups base/filter in LdapUserParamsProvider ## What changes were proposed in this pull request? An authorization code `/token` request with the `roles` scope failed with a 500 when KnoxIDF read users through the Knox embedded LDAP server with the roles-lookup interceptor: 1. The interceptor wrote each role into the user's `memberOf` as a bare `cn=<role>`. 2. `LdapUserParamsProvider` only accepts `memberOf` DNs directly under the groups base, so it dropped all of them. 3. The provider then fell back to searching every group under the groups base. 4. The LDAP server answers an all-groups search by listing every role in the roles service (`GET /roles`). That call can be forbidden (403), and the lookup failure surfaced as a 500. Changes: - **`LDAPRolesLookupInterceptor`:** writes each role into `memberOf` as `cn=<role>,ou=groups,<proxy base dn>`, the DN the role listing and the reverse role lookup already use, instead of a bare `cn=<role>` or a DN copied from the first backend group. - **`LdapUserParamsProvider`:** - New `user.params.provider.ldap.groupSearchBase` (default `ou=groups,<baseDn>`) sets where roles are read from, both from `memberOf` and in the fallback search. - New `user.params.provider.ldap.groupSearchFilter` (default `(&(objectClass=groupOfNames)(member={0}))`, where `{0}` is the user DN) makes the fallback search only the user's groups instead of all groups, then matching members client-side. - **Docs:** `knoxidf/configuration.md` (new parameters, how roles are resolved) and `service_ldap_server.md` (the `memberOf` DN format). ## How was this patch tested? Unit tests, all passing: - `LDAPRolesLookupInterceptorTest` (39): `memberOf` expectations updated to the full role DNs. - `ReverseRoleLookupMappingVisitorTest` (13): unchanged. - `LdapUserParamsProviderTest` (9). Updates and new tests: - The fallback runs the per-user group search. - A custom `groupSearchBase` applies to both `memberOf` and the fallback. - A custom `groupSearchFilter` is used. - A user with no `memberOf` and no groups gets no roles. ## Integration Tests Updated the KnoxIDF authorization code tests to request `roles` and assert the `roles` claim of the access token: - **`knoxidf-token` topology:** reads users and roles from the embedded LDAP server (`ldaps://localhost:33390`) through `LdapUserParamsProvider`. - **`knoxidf-ldap` topology:** allows registering the `roles` scope. - **`test_knoxidf.py`:** expected roles are optional. The default stack has no roles-lookup interceptor, so it keeps running the flows without `roles`. - **New `test_knoxidf_with_rest_role_lookup.py`:** reruns those tests in the REST roles lookup pass, for two users: - `guest`: in no backend group, with `platform:viewer` assigned to the user id in `roles.json`. This is the scenario of the reported failure. - `sam`: roles from its groups (`platform:analyst`, `platform:scientist`). - **Compose overrides:** fixed the usage comments of `docker-compose.role-lookup.yml`, `docker-compose.role-lookup-rest.yml` and `docker-compose.knoxidf-federation.yml`. Their `up --abort-on-container-exit` aborted as soon as the build-only `knox-dev` service exited. Local results: Default pass: 148 passed (`test_knoxidf.py`: 7 passed). REST roles lookup pass: ``` collected 57 items test_knox_ldap_proxy_search_with_rest_role_lookup.py ......s............ [ 33%] ...................s.... [ 75%] test_knoxidf_with_rest_role_lookup.py .............. [100%] ================== 55 passed, 2 skipped, 16 warnings in 8.54s ================== ``` KnoxIDF federation (the brokered subject has no LDAP entry, so the new lookup in `knoxidf-token` must not break it): ``` collected 3 items test_knoxidf_federation.py ... [100%] ======================== 3 passed, 3 warnings in 3.72s ========================= ``` -- 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]
