KNOX-3338: Fix UnsupportedOperationException on JDK 23+ via reflective Subject lookups

[arunk-kumar]

[KNOX-3338] - A short description of the change

Problem

On JDK 23+, Apache Knox throws UnsupportedOperationException at runtime
because Subject.getSubject(AccessController.getContext()) and
Subject.doAs() were deprecated for removal in JDK 17 (JEP 411) and
are now non-functional on JDK 23+.

Stack trace:
at javax.security.auth.Subject.getSubject(Subject.java:277)
at org.apache.knox.gateway.security.SubjectUtils.getCurrentSubject(SubjectUtils.java:41)
at org.apache.knox.gateway.filter.ShiroSubjectIdentityAdapter$CallableChain.call(...)

Solution

Migrate to the JDK 18+ replacement APIs (Subject.current() and
Subject.callAs()) using cached reflection — resolved once at class-load
time via a static initializer — with a graceful fallback to the legacy APIs
on JDK 17. This keeps the code compilable on JDK 17 while being
correct on JDK 23+.

What changes were proposed in this pull request?

SubjectUtils.java

• Replaced Subject.getSubject(AccessController.getContext()) with
  a cached reflection lookup for Subject.current() (JDK 18+)
• Static initializer resolves the method once at boot — zero per-request
  reflection overhead
• Falls back to Subject.getSubject() on JDK 17
• Catches NoSuchMethodException | SecurityException in static block
  to prevent ExceptionInInitializerError

ShiroSubjectIdentityAdapter.java

• Added SUBJECT_CALL_AS static field — cached reflection lookup for
  Subject.callAs(Subject, Callable) (JDK 18+)
• Added doSubjectAction() private helper method that routes to
  Subject.callAs() on JDK 18+ or falls back to Subject.doAs() on JDK 17
• Replaced both Subject.doAs() call sites (anonymous path and
  authenticated path) with doSubjectAction()
• Replaced PrivilegedExceptionAction anonymous class with Callable lambda

gateway-provider-security-shiro/pom.xml

• Added de.thetaphi:forbiddenapis compile dependency required for
  @SuppressForbidden annotation on doSubjectAction()

How was this patch tested?

• Full build compiles cleanly on JDK 17
• gateway-provider-security-shiro: 26 tests run, 0 failures, 0 errors
• No new test failures introduced by this change

Pre-existing failures on master (unrelated to this PR)

The following 30 test failures exist on master before this change
and are confirmed by running git stash and reproducing the same failures
on the unmodified codebase:

• DefaultDispatchTest (4 errors)
• BCInterceptingOutputStreamTest (8 errors)
• SSEDispatchTest (5 errors)
• KnoxImpersonationProviderTest (13 errors)

Root cause: Mockito/ByteBuddy incompatibility (Could not create type)
in the local build environment. These failures are not caused by any
code change in this PR.

JIRA

https://issues.apache.org/jira/browse/KNOX-3338

UI changes

NA

Please review Knox Contributing Process before opening a pull request.

[github-actions]

Test Results

28 tests   28 ✅  2s ⏱️
 1 suites   0 💤
 1 files     0 ❌

Results for commit 11cc435.

[smolnar82]

I'm generally against about these changes because of the use of reflection here. Let me explain why.

There are other ways that avoid reflection:

1. Multi-Release JAR (MRJAR): the textbook solution for exactly this. Base classes compiled at 17 keep doAs/getSubject; a META-INF/versions/18/... overlay compiled with a JDK 18+ toolchain calls callAs/current directly and type-safely. No runtime reflection, no deprecation suppression on the modern path. Cost: we'll need a JDK 18+ available at build (a Maven toolchain) and some pom wiring, which conflicts with the current [17,18) enforcer, so that pin would have to relax for the build JDK.
2. Raise the baseline to JDK 21 and compile with --release 21, dropping JDK 17. Then just call the new methods directly. Simplest code by far; it's a project-policy decision, not a technical blocker.

More important than the reflection debate, the change looks incomplete/risky. While analyzing I found things I'd weight higher than the reflection question:

1. Only the Shiro path was migrated; the getter/setter now mismatch. SubjectUtils.getCurrentSubject() now prefers Subject.current() on JDK 18+, but Subject.current() only sees identities established by callAs, not by doAs!! (unless the legacy -Djdk.security.auth.subject.useTL=true flag is set). This PR converts one setter (ShiroSubjectIdentityAdapter) to callAs, but ~10 other auth providers still call Subject.doAs(...) directly:

AbstractPreAuthFederationFilter, ClientCertFilter, RemoteAuthFilter, AnonymousAuthFilter, AbstractIdentityAssertionFilter, HadoopAuthFilter/PostFilter, Pac4jIdentityAdapter, AccessTokenFederationFilter, AbstractJWTFilter, SpnegoAuthInterceptor, gateway-shell/KnoxSession

Consequences on JDK 18+: for any topology using those providers, getCurrentSubject() via current() would return null even though the request was authenticated (regression risk that appears the moment someone runs on 18+, before 23 even matters), and those doAs sites still throw UnsupportedOperationException on JDK 23+, so KNOX-3338 isn't actually fully fixed, only the Shiro path is. The migration needs to be all-or-nothing across paired call sites.

2. Exception-wrapping semantics changed. Subject.doAs wraps checked exceptions in PrivilegedActionException; Subject.callAs wraps them in CompletionException. doSubjectAction unwraps InvocationTargetException one level, so the filter chain's IOException/ServletException now surfaces wrapped in CompletionException instead of the old type. Any caller that unwraps PrivilegedActionException will behave differently. Worth verifying the outer filter's error handling.

3. Minor pom hygiene in gateway-provider-security-shiro/pom.xml: trailing whitespace after the new </dependency> and the removed newline at EOF (\ No newline at end of file).

Conclusion:

• Reflection works and is defensible, but it's not the only option: MRJAR keeps JDK 17 support with zero runtime reflection and no deprecation suppression on the modern path; bumping the baseline to 21 is even simpler if 17 can be dropped.
• Regardless of reflection vs MRJAR, the bigger issue is that the callAs/current pairing is applied inconsistently: migrating only the Shiro setter while the getter switches globally risks breaking identity propagation on JDK 18+ and leaves the other doAs sites still broken on 23+.

I'll start a [DISCUSS] thread on the DEV mailing list about this matter and closing this PR for now.

[smolnar82]

Discuss thread: https://lists.apache.org/thread/b580r214xys7wl2l37cdkonhmlchgrvo

[arunk-kumar]

Thank you @smolnar82 for the thorough review. The point about the callAs / current pairing being incomplete is well taken. Migrating SubjectUtils.getCurrentSubject() to Subject.current()while leaving the other ~10 providers still calling Subject.doAs() creates a real context regression risk on JDK 18+ that I had not fully analyzed. I completely agree that this needs to be an all-or-nothing holistic migration.

Closing this PR is absolutely the right call. I will follow the [DISCUSS] thread closely on the DEV mailing list and am looking forward to addressing all the points raised here before resubmitting once the community aligns on a strategy.

Thank you again for safeguarding the architecture and preventing a major regression!