[
https://issues.apache.org/jira/browse/KNOX-3219?focusedWorklogId=993423&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-993423
]
ASF GitHub Bot logged work on KNOX-3219:
----------------------------------------
Author: ASF GitHub Bot
Created on: 26/Nov/25 13:12
Start Date: 26/Nov/25 13:12
Worklog Time Spent: 10m
Work Description: smolnar82 opened a new pull request, #1112:
URL: https://github.com/apache/knox/pull/1112
[KNOX-3129](https://issues.apache.org/jira/browse/KNOX-3219) - New Virtual
Group mapping function to check request parameters
## What changes were proposed in this pull request?
This PR adds a new Virtual Group mapping function that gets the value (later
used for testing the given predicate) from the request parameters.
## How was this patch tested?
Added new uni test cases to cover this new function.
Additionally, I applied the following configs in a topology:
```
<provider>
<role>identity-assertion</role>
<name>HadoopGroupProvider</name>
<enabled>true</enabled>
<param>
<name>CENTRAL_GROUP_CONFIG_PREFIX</name>
<value>gateway.group.config.</value>
</param>
<param>
<name>group.mapping.non_rejected_requests</name>
<value>(= (strlen (request-parameter 'impala.doas.user'))
0)</value>
</param>
</provider>
<provider>
<role>authorization</role>
<name>AclsAuthz</name>
<enabled>true</enabled>
<param>
<name>webhdfs.acl</name>
<value>*;non_rejected_requests;*</value>
</param>
</provider>
```
The challenged this topology using the WEBHDFS service with and without the
`impala.doas.user` request parameter and confirmed that the
`non_rejected_requests` group was mapped when the `impala.doas.user` was not in
the request. See the relevant `gateway-audit.log` entries (check th
`identity-mapping` lines):
```
25/11/26 11:53:57
||dcacf4a6-2cf4-4c81-a7d4-ca51b26f2a8f|audit|10.140.118.194|WEBHDFS||||access|uri|/gateway/cdp-proxy-api/webhdfs/v1?op=LISTSTATUS&impala.doas.user=myUser|unavailable|Request
method: GET
25/11/26 11:53:58
||dcacf4a6-2cf4-4c81-a7d4-ca51b26f2a8f|audit|10.140.118.194|WEBHDFS|knoxui|||authentication|uri|/gateway/cdp-proxy-api/webhdfs/v1?op=LISTSTATUS&impala.doas.user=myUser|success|
25/11/26 11:53:58
||dcacf4a6-2cf4-4c81-a7d4-ca51b26f2a8f|audit|10.140.118.194|WEBHDFS|knoxui|||authentication|uri|/gateway/cdp-proxy-api/webhdfs/v1?op=LISTSTATUS&impala.doas.user=myUser|success|Groups:
[admin]
25/11/26 11:53:58
||dcacf4a6-2cf4-4c81-a7d4-ca51b26f2a8f|audit|10.140.118.194|WEBHDFS|knoxui|||identity-mapping|principal|knoxui|success|Groups:
[admin]
25/11/26 11:53:58
||dcacf4a6-2cf4-4c81-a7d4-ca51b26f2a8f|audit|10.140.118.194|WEBHDFS|knoxui|||authorization|uri|/gateway/cdp-proxy-api/webhdfs/v1?op=LISTSTATUS&impala.doas.user=myUser|failure|
25/11/26 11:53:58
||dcacf4a6-2cf4-4c81-a7d4-ca51b26f2a8f|audit|10.140.118.194|WEBHDFS|knoxui|||access|uri|/gateway/cdp-proxy-api/webhdfs/v1?op=LISTSTATUS&impala.doas.user=myUser|success|Response
status: 403
...
25/11/26 11:54:05
||ec83e82f-43f8-4963-8493-0e22ea09a1bc|audit|10.140.118.194|WEBHDFS||||access|uri|/gateway/cdp-proxy-api/webhdfs/v1?op=LISTSTATUS|unavailable|Request
method: GET
25/11/26 11:54:05
||ec83e82f-43f8-4963-8493-0e22ea09a1bc|audit|10.140.118.194|WEBHDFS|knoxui|||authentication|uri|/gateway/cdp-proxy-api/webhdfs/v1?op=LISTSTATUS|success|
25/11/26 11:54:05
||ec83e82f-43f8-4963-8493-0e22ea09a1bc|audit|10.140.118.194|WEBHDFS|knoxui|||authentication|uri|/gateway/cdp-proxy-api/webhdfs/v1?op=LISTSTATUS|success|Groups:
[knoxui]
25/11/26 11:54:05
||ec83e82f-43f8-4963-8493-0e22ea09a1bc|audit|10.140.118.194|WEBHDFS|knoxui|||identity-mapping|principal|knoxui|success|Groups:
[non_rejected_requests, admin]
25/11/26 11:54:05
||ec83e82f-43f8-4963-8493-0e22ea09a1bc|audit|10.140.118.194|WEBHDFS|knoxui|||authorization|uri|/gateway/cdp-proxy-api/webhdfs/v1?op=LISTSTATUS|success|
25/11/26 11:54:05
||ec83e82f-43f8-4963-8493-0e22ea09a1bc|audit|10.140.118.194|WEBHDFS|knoxui|||dispatch|uri|https://ccycloud-1.tpayer-knox.root.comops.site:20102/webhdfs/v1/?op=LISTSTATUS&doAs=knoxui|unavailable|Request
method: GET
25/11/26 11:54:05
||ec83e82f-43f8-4963-8493-0e22ea09a1bc|audit|10.140.118.194|WEBHDFS|knoxui|||dispatch|uri|https://ccycloud-1.tpayer-knox.root.comops.site:20102/webhdfs/v1/?op=LISTSTATUS&doAs=knoxui|success|Response
status: 200
25/11/26 11:54:05
||ec83e82f-43f8-4963-8493-0e22ea09a1bc|audit|10.140.118.194|WEBHDFS|knoxui|||access|uri|/gateway/cdp-proxy-api/webhdfs/v1?op=LISTSTATUS|success|Response
status: 200
```
Issue Time Tracking
-------------------
Worklog Id: (was: 993423)
Remaining Estimate: 0h
Time Spent: 10m
> New Virtual Group mapping function to check request parameters
> --------------------------------------------------------------
>
> Key: KNOX-3219
> URL: https://issues.apache.org/jira/browse/KNOX-3219
> Project: Apache Knox
> Issue Type: Improvement
> Components: Server
> Affects Versions: 2.0.0, 2.1.0
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
> Priority: Major
> Fix For: 3.0.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> KNOX-2707 added a very cool feature that allows virtual group mapping using
> predicates. There are many pre-defined functions, including
> {{request-header}} and {{{}request-attribute{}}}.
> It'd be beneficial to add a new request-related function called
> {{request-parameter}} that works the same way as the above listed ones, but
> it gets the value to compare from the request parameters.
> For instance:
> {code:java}
> <param>
> <name>group.mapping.non_rejected_requests</name>
> <value>(= (strlen (request-parameter 'impala.doas.user')) 0)</value>
> </param> {code}
> This would map user principals to the {{non_rejected_requests}} where the
> request doesn't contain the {{impala.doas.user}} parameter.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
