Sandor Molnar created KNOX-3540:
-----------------------------------
Summary: 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
Fix For: 3.1.0
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)
