smolnar82 opened a new pull request, #1401: URL: https://github.com/apache/knox/pull/1401
[KNOX-3459](https://issues.apache.org/jira/browse/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. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
