[
https://issues.apache.org/jira/browse/KNOX-3461?focusedWorklogId=1042247&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1042247
]
ASF GitHub Bot logged work on KNOX-3461:
----------------------------------------
Author: ASF GitHub Bot
Created on: 17/Sep/26 07:19
Start Date: 17/Sep/26 07:19
Worklog Time Spent: 10m
Work Description: smolnar82 commented on code in PR #1405:
URL: https://github.com/apache/knox/pull/1405#discussion_r4034183129
##########
gateway-provider-security-jwt/src/main/java/org/apache/knox/gateway/provider/federation/jwt/filter/TokenExchangeHandler.java:
##########
@@ -316,7 +316,29 @@ ActionOutcome.SUCCESS, auditMessage(policyDecision,
actorIdentity, subjectToken,
// present so that KNOXTOKEN falls back to its resource query parameter
otherwise; when set,
// the body value takes precedence over the query parameter.
if (!requestedAudiences.isEmpty()) {
-
request.setAttribute(CommonTokenConstants.REQUESTED_AUDIENCES_REQUEST_ATTR,
requestedAudiences);
+ final boolean sameSubjectExchange = !hasActorToken &&
!requestedSubjectDiffersFromSubject;
Review Comment:
> nit: I hadn't computed the boolean delegationExchange above for the big
branch that handles delegation, because it was only used once, so I just
inlined the AND expression. It branches off for the delegation authorization
logic. But if we're using it again here, we can compute it up there and share
it.
Makes sense. I'll hoist `delegationExchange = hasActorToken ||
requestedSubjectDiffersFromSubject` up where it's first used and reuse it here.
> nit: Arguably this logic, or at least the enforcement logic could be moved
into the above conditional, where we already have an if delegation block. We
can add an else block to enforce the audiences are valid there, so all the
enforcement is done before the subject setting. That is, if we later add more
options for how to validate same-subject audience requests, we'd have a more
complex validation step there. Grouping it with setting the attribute is a bit
confusing.
Agreed. I'll move the same-subject audience enforcement into an else on the
delegation block so all authorization happens before the subject is set,
leaving the downstream conveyance as a plain attribute-set.
Issue Time Tracking
-------------------
Worklog Id: (was: 1042247)
Time Spent: 1h 10m (was: 1h)
> Same subject validation for requested audience
> ----------------------------------------------
>
> Key: KNOX-3461
> URL: https://issues.apache.org/jira/browse/KNOX-3461
> Project: Apache Knox
> Issue Type: Sub-task
> Components: JWT
> Reporter: Harrison Sheinblatt
> Assignee: Sandor Molnar
> Priority: Major
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> When delegation is enabled, we'll want to set the knoxidf audience strategy
> to passthrough so we rely on the delegation policy to authorize a requested
> audience instead of the hardcoded list. But once that's set, then the
> same-subject requested audience is unauthorized at all. So we either need to
> not allow requested audiences just for same-subject exchanges with a setting,
> or add enforcement, or both.
> The simplest thing is to add a setting to skip reading the requested audience
> only for same-subject token exchanges.
> The natural authz is to validate the original subject token has the audience
> requested to allow the requested audience. So if the flag to allow reading
> the audience for same-subject exchange is on, we'd authorize on the subject
> token. If this proves a problem, we can turn it off or figure out a way to
> add more audiences to the user tokens knox issues.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
