[ 
https://issues.apache.org/jira/browse/KNOX-3539?focusedWorklogId=1052253&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1052253
 ]

ASF GitHub Bot logged work on KNOX-3539:
----------------------------------------

                Author: ASF GitHub Bot
            Created on: 03/Nov/26 20:52
            Start Date: 03/Nov/26 20:52
    Worklog Time Spent: 10m 
      Work Description: handavid commented on code in PR #1479:
URL: https://github.com/apache/knox/pull/1479#discussion_r4458170297


##########
gateway-server/src/main/java/org/apache/knox/gateway/services/ldap/interceptor/LDAPRolesLookupInterceptor.java:
##########
@@ -257,7 +266,7 @@ private EntryFilteringCursor 
handleSearch(SearchOperationContext ctx) throws Lda
                 if (LdapUtils.isGroupEntry(entry)) {
                     roleEntries.addAll(translateGroupEntry(entry));
                 } else {
-                    final String username = 
LdapUtils.extractUsernameFromEntry(entry, "uid", "cn");
+                    final String username = 
toRolesLookupUserId(LdapUtils.extractUsernameFromEntry(entry, "uid", "cn"));
                     final Set<String> groups = fetchGroups(entry);

Review Comment:
   we should lowercase the group names as well



##########
gateway-server/src/main/java/org/apache/knox/gateway/services/ldap/KnoxLDAPServerManager.java:
##########
@@ -211,6 +211,11 @@ private void createInterceptors(GatewayConfig config) 
throws Exception {
                 }
             }
 
+            // Add common LDAP Proxy configurations to the roles lookup 
interceptor

Review Comment:
   we won't need to copy the config if we move the config under the interceptor 
instead of on the roles lookup service.



##########
.github/workflows/tests/test_knox_ldap_proxy_search_with_role_lookup.py:
##########
@@ -163,6 +169,11 @@ def test_list_all_roles_by_objectclass_presence(self) -> 
None:
         groups = self.rdn_values(self.search(PROXY_GROUPS_BASE, 
"(objectClass=*)"))
         self.assertEqual(ALL_ROLES, set(groups))
 
+    # ApacheDS hands the interceptors 
(|(objectClass=groupOfNames)(objectClass=referral)), which
+    # the roles lookup does not take for a list search from an ancestor of 
ou=groups. So the
+    # backend groups are translated instead and roles assigned only to users 
(platform:deployer)
+    # are missing.
+    @unittest.skip("root-level role listing misses roles assigned only to 
users")

Review Comment:
   I wasn't expecting this. this may be a bug in the way we determine whether a 
filter is an all groups filter. I'll have to take a closer look



##########
gateway-spi/src/main/java/org/apache/knox/gateway/config/GatewayConfig.java:
##########
@@ -153,11 +153,13 @@ public interface GatewayConfig {
   String LDAP_BACKEND_DATA_FILE = "gateway.ldap.backend.data.file";
   String LDAP_RECURSIVE_GROUP_RESOLUTION = 
"gateway.ldap.recursive.group.resolution";
   String LDAP_RECURSIVE_GROUP_RESOLUTION_MAX_DEPTH = 
"gateway.ldap.recursive.group.resolution.max.depth";
-  String LDAP_ROLES_LOOKUP_STRATEGY = "gateway.ldap.roles.lookup.strategy";
-  String LDAP_ROLES_LOOKUP_REST_API_ENDPOINT = 
"gateway.ldap.roles.lookup.rest.api.endpoint";
-  String LDAP_ROLES_LOOKUP_FILE_PATH = "gateway.ldap.roles.lookup.file.path";
-  String LDAP_ROLES_LIST_REST_API_ENDPOINT = 
"gateway.ldap.roles.list.rest.api.endpoint";
-  String LDAP_ROLES_GET_REST_API_ENDPOINT = 
"gateway.ldap.roles.get.rest.api.endpoint";
+  String LDAP_ROLES_PREFIX = "gateway.ldap.roles.";
+  String LDAP_ROLES_LOOKUP_STRATEGY = LDAP_ROLES_PREFIX + "lookup.strategy";
+  String LDAP_ROLES_LOOKUP_REST_API_ENDPOINT = LDAP_ROLES_PREFIX + 
"lookup.rest.api.endpoint";
+  String LDAP_ROLES_LOOKUP_FILE_PATH = LDAP_ROLES_PREFIX + "lookup.file.path";
+  String LDAP_ROLES_LIST_REST_API_ENDPOINT = LDAP_ROLES_PREFIX + 
"list.rest.api.endpoint";
+  String LDAP_ROLES_GET_REST_API_ENDPOINT = LDAP_ROLES_PREFIX + 
"get.rest.api.endpoint";
+  String LDAP_ROLES_LOOKUP_LOWERCASE_USER_ID = LDAP_ROLES_PREFIX + 
"lookup.lowercase.user.id";

Review Comment:
   I think we can push this under the roles lookup interceptor config instead 
of the roles lookup config. This config isn't used by the roles lookup service 
itself.





Issue Time Tracking
-------------------

    Worklog Id:     (was: 1052253)
    Time Spent: 40m  (was: 0.5h)

> Add an option to lowercase the user ID in the LDAP proxy roles-lookup 
> interceptor
> ---------------------------------------------------------------------------------
>
>                 Key: KNOX-3539
>                 URL: https://issues.apache.org/jira/browse/KNOX-3539
>             Project: Apache Knox
>          Issue Type: Task
>          Components: LDAP, Server
>    Affects Versions: 3.0.0
>            Reporter: Sandor Molnar
>            Assignee: Sandor Molnar
>            Priority: Major
>             Fix For: 3.1.0
>
>          Time Spent: 40m
>  Remaining Estimate: 0h
>
> The LDAP proxy's {{LDAPRolesLookupInterceptor}} builds the user ID for the 
> roles lookup from the {{uid}} attribute of the entry returned by the backend 
> directory. For Active Directory backends, uid holds {{sAMAccountName}}. AD 
> matches this attribute case-insensitively, but the value comes back in its 
> canonical case (e.g. {{Admin}}). Whatever case the client searched with 
> ({{admin}}, {{ADMIN}}), the roles-lookup service receives {{Admin}}.
> If the roles backend stores and matches user IDs case-sensitively and has 
> role memberships keyed on a different case (e.g. the login name as typed), 
> the lookup finds nothing and the user gets no roles.
> *Proposal*: add a new gateway configuration property:
> {code}
> gateway.ldap.roles.lookup.lowercase.user.id = false (default)
> {code}
> When {{true}}, the interceptor lowercases the user ID before calling 
> {{LDAPRolesLookupService.lookupRoles()}}. Combined with 
> {{expression.principal.mapping = (lowercase username)}} in the 
> {{identity-assertion}} provider, the asserted principal and the roles-lookup 
> key are then always the same case. The default (false) keeps the current 
> behavior.



--
This message was sent by Atlassian Jira
(v10.3.26#10030026)

Reply via email to