[
https://issues.apache.org/jira/browse/KNOX-3337?focusedWorklogId=1024256&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1024256
]
ASF GitHub Bot logged work on KNOX-3337:
----------------------------------------
Author: ASF GitHub Bot
Created on: 09/Jun/26 10:10
Start Date: 09/Jun/26 10:10
Worklog Time Spent: 10m
Work Description: smolnar82 commented on code in PR #1247:
URL: https://github.com/apache/knox/pull/1247#discussion_r3379764485
##########
gateway-server/src/main/java/org/apache/knox/gateway/services/ldap/LDAPRolesLookupInterceptor.java:
##########
@@ -0,0 +1,147 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.knox.gateway.services.ldap;
+
+import org.apache.directory.api.ldap.model.cursor.ListCursor;
+import org.apache.directory.api.ldap.model.entry.Attribute;
+import org.apache.directory.api.ldap.model.entry.Entry;
+import org.apache.directory.api.ldap.model.entry.Value;
+import org.apache.directory.api.ldap.model.exception.LdapException;
+import org.apache.directory.api.ldap.model.exception.LdapInvalidDnException;
+import org.apache.directory.api.ldap.model.name.Dn;
+import org.apache.directory.api.ldap.model.name.Rdn;
+import org.apache.directory.server.core.api.filtering.EntryFilteringCursor;
+import org.apache.directory.server.core.api.filtering.EntryFilteringCursorImpl;
+import org.apache.directory.server.core.api.interceptor.BaseInterceptor;
+import
org.apache.directory.server.core.api.interceptor.context.SearchOperationContext;
+import org.apache.knox.gateway.i18n.messages.MessagesFactory;
+
+import java.util.ArrayList;
+import java.util.Collection;
+import java.util.List;
+
+/**
+ * Interceptor that replaces group names in memberOf attributes with role names
+ * if LDAP roles lookup is enabled.
+ */
+public class LDAPRolesLookupInterceptor extends BaseInterceptor {
+ private static final LdapMessages LOG =
MessagesFactory.get(LdapMessages.class);
+ private final LDAPRolesLookupService rolesLookupService;
+
+ public LDAPRolesLookupInterceptor(LDAPRolesLookupService
rolesLookupService) {
+ this.rolesLookupService = rolesLookupService;
+ }
+
+ @Override
+ public EntryFilteringCursor search(SearchOperationContext ctx) throws
LdapException {
+ final List<Entry> entries = new ArrayList<>();
+ try (EntryFilteringCursor cursor = next(ctx)) {
+ while (cursor.next()) {
+ entries.add(modifyEntry(cursor.get()));
Review Comment:
Thank you for the feedback regarding the batching strategy! I looked into
implementing the 3-step approach (Collect -> Batch Map -> Merge), but I found
that because our current REST API endpoint is designed for single-context
lookups (one user + their associated groups), batching actually introduces more
overhead rather than reducing it.
Specifically, since the API doesn't support a 'Bulk' request (e.g., fetching
roles for multiple users at once), we must still make $N$ requests for $N$
users. Using a separate 3-step process actually increases the total number of
HTTP round-trips.
Here is a comparison for a search result returning 100 users sharing the
same 5 groups:
| Metric | Per-Entry Approach (Proposed) | 3-Step Strategy
(Batching) |
|---------------------|-------------------------------|----------------------------------|
| Total HTTP Requests | 100 | 105
|
| Backend DB Lookups | 600 | 105
|
| Network Bottleneck | 100 round-trips | 105 round-trips
|
| Implementation | Simple & Stateless | Complex (manual
result merging) |
_Conclusion_:
While the 3-step strategy reduces the number of lookups on the backend
(database) side, it increases the number of HTTP round-trips, which is the
primary latency bottleneck in this architecture. Furthermore, the REST API
backend was specifically built to perform the User/Group 'OR' logic in a single
query. By using the per-entry approach, we leverage the backend's design to get
the final role set in exactly one trip per user.
If we ever introduce a 'Bulk' endpoint to the REST API, the 3-step strategy
would absolutely be the way to go. But for the current API, the per-entry
approach is both faster and simpler.
Issue Time Tracking
-------------------
Worklog Id: (was: 1024256)
Time Spent: 1h (was: 50m)
> Enhance KnoxLdapService with Pluggable Role Lookup Support
> ----------------------------------------------------------
>
> Key: KNOX-3337
> URL: https://issues.apache.org/jira/browse/KNOX-3337
> Project: Apache Knox
> Issue Type: Improvement
> Components: Server
> Affects Versions: 3.0.0
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
> Priority: Critical
> Fix For: 3.0.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Currently, the KnoxLdapService provides user and group information directly
> from its configured LDAP backend. In many deployment scenarios, particularly
> in modern cloud-native environments, there is a requirement to map these
> LDAP-authenticated identities and their group memberships to higher-level
> application roles managed by an external source.
> This JIRA introduces a pluggable role lookup mechanism within KnoxLdapService
> that allows Knox to intercept group resolution and instead populate roles
> from either a local configuration file (for testing purposes) or a remote
> REST API.
> *Key Features*
> 1. *Pluggable Interface:* Introduction of LdapRolesLookup to allow for
> extensible lookup strategies.
> 2. *REST Implementation:* A client implementation that POSTs user ID and
> group lists to a configured endpoint to retrieve role mappings, following a
> specific OpenAPI schema.
> 3. *File-based Implementation:* A JSON-based lookup strategy for static
> environments, using the same data structure as the REST API.
> 4. *Configuration-driven:* New gateway-site.xml properties to toggle
> lookup types and configure endpoints or file paths.
> *Proposed Configuration*
> * {{{}gateway.ldap.roles.lookup.strategy{}}}: Enables the lookup (file or
> rest).
> * {{{}gateway.ldap.roles.lookup.rest.api.endpoint{}}}: The destination URL
> for REST lookups.
> * {{{}gateway.ldap.roles.lookup.file.path{}}}: the file path which points to
> the JSON mapping file.
> *Data Contract:*
> The implementation will exchange JSON payloads containing a user_id and an
> array of groups, receiving a response containing a list of RoleAssignment
> objects (consisting of scope and name).
>
> This enhancement will allow for more dynamic and flexible authorization
> workflows in Knox-managed environments.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
