You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@knox.apache.org by "ASF GitHub Bot (Jira)" <ji...@apache.org> on 2025/09/11 09:59:00 UTC

[jira] [Work logged] (KNOX-3188) Add group-based configuration parameter for KnoxToken renewer/revoker access control

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

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

                Author: ASF GitHub Bot
            Created on: 11/Sep/25 09:58
            Start Date: 11/Sep/25 09:58
    Worklog Time Spent: 10m 
      Work Description: smolnar82 opened a new pull request, #1083:
URL: https://github.com/apache/knox/pull/1083

   
   ## What changes were proposed in this pull request?
   
   (Please fill in changes proposed in this fix)
   
   ## How was this patch tested?
   
   Updated existing unit tests, added new test cases to cover the new functionality and executed them successfully.
   
   Additionally, I conducted manual testing using the OOTB LDAP server with different users:
   ```
   analyst  group
   member: uid=sam,ou=people,dc=hadoop,dc=apache,dc=org
   member: uid=tom,ou=people,dc=hadoop,dc=apache,dc=org
   
   scientist group
   member: uid=sam,ou=people,dc=hadoop,dc=apache,dc=org
   
   admin group
   member: uid=admin,ou=people,dc=hadoop,dc=apache,dc=org
   ```
   
   In order for the group-based authorization to work, I changed the `DEFAULT` identity assertion filter to `HadoopGroupProvider` in the `homepage` topology as well as edited the `gateway-site.xml` and added `sam` and `tom` to `gateway.knox.token.management.users.can.see.all.tokens`.
   
   Other than this, I customized the `knox.token.renewer.whitelist` (RW, going forward) and `knox.token.renewer.group.whitelist` (GRW, going forward) service-level params.
   
   Since token renewal is not exposed on the token management UI, only token revocation, I tested using that functionality (they both have been updated the same way).
   
   Cases:
   - Logged in user: admin, RW: admin, GRW: empty -> token revocation succeeded ✅
   - Logged in user: admin, RW: empty, GRW: admin -> token revocation succeeded ✅
   - Logged in user: sam, RW: empty, GRW: scientist -> token revocation succeeded ✅
   - Logged in user: sam, RW: empty, GRW: analyst -> token revocation succeeded ✅
   - Logged in user: sam, RW: empty, GRW: admin -> token revocation failed ✅
   - Logged in user: tom, RW: empty, GRW: scientist -> token revocation failed ✅
   - Logged in user: tom, RW: empty, GRW: analyst -> token revocation succeeded ✅
   
   




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

            Worklog Id:     (was: 982754)
    Remaining Estimate: 0h
            Time Spent: 10m

> Add group-based configuration parameter for KnoxToken renewer/revoker access control
> ------------------------------------------------------------------------------------
>
>                 Key: KNOX-3188
>                 URL: https://issues.apache.org/jira/browse/KNOX-3188
>             Project: Apache Knox
>          Issue Type: Improvement
>          Components: Server
>    Affects Versions: 2.0.0, 1.6.0, 2.1.0
>            Reporter: Sandor Molnar
>            Assignee: Sandor Molnar
>            Priority: Major
>             Fix For: 3.0.0
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently, the {{knox.token.renewer.whitelist}} parameter allows administrators to specify a comma-separated list of users who are authorized to invoke KnoxToken renewal and revocation APIs. While this works for individual users, it does not provide a convenient way to manage authorization at the group level.
> In environments where user/group membership is centrally managed (e.g., via LDAP, AD, or other identity providers), group-based access control is often preferred to simplify configuration and ongoing maintenance. Without group support, administrators must list each individual user explicitly, which becomes cumbersome and error-prone, especially in larger deployments.
> {*}Proposal{*}:
> Introduce a new optional configuration parameter (e.g., {{{}knox.token.renewer.group.whitelist{}}}) that accepts a comma-separated list of groups. Any user belonging to one of the listed groups should be authorized to renew or revoke tokens.
> {*}Example{*}:
> {code:java}
> knox.token.renewer.whitelist=alice,bob  
> knox.token.renewer.group.whitelist=admins,devops
> {code}
>  In the above example, both explicitly whitelisted users ({{{}alice{}}}, {{{}bob{}}}) and any users belonging to the {{admins}} or {{devops}} groups would be allowed to invoke the renewal/revocation APIs.
> {*}Benefits{*}:
>  * Simplifies administration by allowing group-based access control.
>  * Reduces the risk of configuration drift when onboarding or offboarding users.
>  * Aligns KnoxToken access control with common enterprise practices for authorization management.
> {*}Acceptance Criteria{*}:
>  * A new configuration parameter {{knox.token.renewer.group.whitelist}} is recognized.
>  * Token renewal/revocation APIs check both user and group whitelists for authorization.
>  * Backwards compatibility: existing behavior with {{knox.token.renewer.whitelist}} remains unchanged if the group-based parameter is not set.
>  * Documentation is updated to reflect the new parameter.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)