KNOX-3395: Add KNOXTOKEN issuance and JWTProvider federation integration tests

[Raghav-Mah3shwari]

What changes were proposed in this pull request?

This PR adds a new Docker Compose integration test suite that covers the knoxtoken topology (JWTProvider federation) and the KNOXTOKEN token-issuance service. Both are baked into the CI test image but were previously exercised by no integration test.

New file: .github/workflows/tests/test_knoxtoken_jwt.py

It validates a real end-to-end token flow:

1. Mint a Knox JWT from the KNOXTOKEN service (gateway/knoxldap/knoxtoken/api/v1/token) using Basic auth.
2. Present that bearer token to the JWTProvider-protected topology (gateway/knoxtoken/auth/api/v1/pre) and confirm the caller identity is asserted.

Test cases:

• test_token_endpoint_returns_jwt_and_metadata — token response contains access_token, token_type: Bearer, expires_in, and the token is a well-formed 3-segment JWT.
• test_token_requires_authentication — anonymous token request returns 401.
• test_jwt_grants_access_to_federated_topology — a valid JWT authenticates and yields x-knox-actor-username: guest.
• test_federated_topology_requires_token — a request with no token returns 401.
• test_federated_topology_rejects_invalid_token — a malformed bearer token returns 401.

The suite reuses the existing common_utils helpers and follows the current test style. It does not overlap with existing tests: all other suites use Basic auth or preauth headers, and none issue a Knox token or authenticate via JWTProvider.

No production code, topologies, or workflow behavior are changed.

How was this patch tested?

• Verified endpoint paths and contract against the codebase before writing:
  • KNOXTOKEN path knoxtoken/api/v1/token and JSON keys access_token / token_type / expires_in (gateway-service-knoxtoken/.../TokenResource.java).
  • Auth service path auth/api/v1/pre (gateway-service-auth/.../PreAuthResource.java).
  • knoxtoken.xml uses JWTProvider with RS256, matching the gateway's default token signing algorithm.
• The new file is auto-discovered by the default pytest run in docker-compose.yml (it is not in the single-EKU --ignore list), so it executes as part of the existing Docker Compose test job.
• Locally, the suite can be run with:

  docker compose -f ./.github/workflows/compose/docker-compose.yml up -d
  docker compose -f ./.github/workflows/compose/docker-compose.yml run --rm tests

Integration Tests

This PR is itself an addition of integration tests under .github/workflows/tests. No Java unit tests are added because the change only introduces black-box HTTP integration tests against the packaged gateway; the underlying KNOXTOKEN and JWTProvider components already have Java unit coverage in their respective modules.

UI changes

N/A — no UI changes.

[Raghav-Mah3shwari]

Hi @pzampino , @smolnar82, can i get a review on this? thanks

[github-actions]

Test Results

45 tests   45 ✅  6s ⏱️
 3 suites   0 💤
 3 files     0 ❌

Results for commit e228bf0.

[smolnar82]

Nice addition, @Raghav-Mah3shwari, the end-to-end path here (mint a token in knoxldap → present it to the JWTProvider-federated knoxtoken topology → assert x-knox-actor-username) is the highest-value scenario and it's covered cleanly. The file follows the suite conventions (common_utils, unittest, HTTPBasicAuth) and the issuance + negative auth cases all look correct.

A couple of things before merge:

1. Missing token lifecyle operation test cases
Would you be up for extending the scope to cover the token lifecycle operations (renew / revoke / enable / disable) in a follow-up (or here, if you prefer)? Since KNOX-3395 indicates KNOXTOKEN issuance, it's a natural next step and there's a config prerequisite worth capturing while it's fresh:

These endpoints require server-managed token state, which neither knoxtoken.xml nor knoxldap.xml currently enables (both set only token TTL). So it's a topology-config change first, tests second. Against the current config:

• enable / disable / revoke → tokenStateService == null → 400 CONFIGURATION_ERROR
• renew → falls into the renewalDisabled branch and echoes the token's own expiry — no actual renewal

To exercise them you'd need, on the KNOXTOKEN service:

<param><name>knox.token.exp.server-managed</name><value>true</value></param>
<param><name>knox.token.renewer.whitelist</name><value>guest</value></param>

Without the whitelist, token renewal or revocation will return 403 (revoking your own token is the one exception).

Cases I'd suggest for that round:

• Revoke → enforcement (the key one): mint → revoke → re-present to the federated endpoint and assert it's now 401. The {"revoked":"true"} response alone doesn't prove revocation is enforced.
• Renew: returns {"renewed":"true", ...} and the renewed token still federates.
• Authorization negative: a non-whitelisted user gets 403 on renew/revoke.
• enable/disable: disable a token, confirm it stops working; cover the "already enabled/disabled" 400 paths.

2. Two minor notes on the existing tests:

• test_federated_topology_rejects_invalid_token uses "not.a.valid.jwt" (structurally malformed). Consider also a well-formed-but-wrong-signature token so the RS256 signature check (jwt.expected.sigalg) is exercised, not just the parser. This is doable by removing the last character of the generated token's access_key field.
• The topologies set knoxsso.token.ttl, but the documented KNOXTOKEN TTL param is knox.token.ttl if I were you, I'd change them in the scope of this PR.