Skip to content

KNOX-3459: honor delegation policy tokenTtlSec as the minted token's expiry basis - #1401

Merged
smolnar82 merged 2 commits into
apache:masterfrom
smolnar82:KNOX-3459
Sep 16, 2026
Merged

smolnar82 merged 2 commits into
apache:masterfrom
smolnar82:KNOX-3459

Conversation

@smolnar82

Copy link
Copy Markdown
Contributor

KNOX-3459 - Honor delegation policy tokenTtlSec

What changes were proposed in this pull request?

PolicyDecision.getEffectiveTtlSec() is already computed by JdbcDelegationPolicyService.evaluate() (from DelegationPolicy.getTokenTtlSec(), falling back to the configured default), but it was silently discarded — TokenExchangeHandler read only getDenyReason(), so the per-policy TTL had no effect on the minted token's lifetime.

This plumbs the effective TTL to KNOXTOKEN, mirroring the existing audience passthrough:

  • CommonTokenConstants — adds REQUESTED_TTL_REQUEST_ATTR (knox.token.requested.ttl), an Integer seconds value an upstream component may set.
  • TokenExchangeHandler — on the authorized delegation path (OBO / headless), sets the attribute from policyDecision.getEffectiveTtlSec().
  • TokenResource.getExpiry() — when the attribute is present and positive, uses it as the expiry basis directly, deliberately bypassing the topology knox.token.ttl upper bound and the client lifespan clamp.

The policy TTL is authoritative because DelegationPolicy.tokenTtlSec is trusted, operator-configured server-side state (a peer of the topology config, not untrusted client input like lifespan). Its main use case — longer-lived tokens for headless/batch delegations — is impossible if capped by the topology default. Plain (same-subject) exchanges are unaffected: the attribute is set only on the policy-governed delegation path.

How was this patch tested?

  • TokenExchangeHandlerTest (66 → 69): OBO delegation conveys the policy TTL, headless delegation conveys it, same-subject exchange does not.
  • TokenServiceResourceTest (101 → 103): minted token honors the policy TTL while bypassing a lower topology knox.token.ttl cap, and bypasses a shorter lifespan clamp.
  • Both modules compile clean; full suites green.

@smolnar82

Copy link
Copy Markdown
Contributor Author

Cc. @hsheinblatt

@smolnar82
smolnar82 requested a review from pzampino September 15, 2026 13:25
@github-actions

Copy link
Copy Markdown

Test Results

  4 files    4 suites   1m 48s ⏱️
 87 tests  87 ✅ 0 💤 0 ❌
105 runs  105 ✅ 0 💤 0 ❌

Results for commit e7dfd64.

// directly: it deliberately bypasses the topology knox.token.ttl upper bound and the client-supplied
// lifespan clamp below, since the policy value is server-side state (a peer of the topology config),
// not untrusted client input, and its purpose is longer-lived tokens for headless/batch delegations.
final Object requestedTtlSec = request.getAttribute(CommonTokenConstants.REQUESTED_TTL_REQUEST_ATTR);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe worth referring to the authoring bounds: knox.delegation.max.token.ttl.sec defaults to 86400 sec (24 hours) and knox.delegation.min.token.ttl.sec defaults to 60 sec.

@hsheinblatt hsheinblatt left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @smolnar82 , looks good to me. Just a comment that the operator allowed values are still bounded.

@smolnar82

Copy link
Copy Markdown
Contributor Author

Thanks @smolnar82 , looks good to me. Just a comment that the operator allowed values are still bounded.

I made that bound clear in my comment in the code. Thanks for the review.

@smolnar82
smolnar82 merged commit cc6ec93 into apache:master Sep 16, 2026
2 checks passed
@smolnar82
smolnar82 deleted the KNOX-3459 branch September 16, 2026 08:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants