[JDK 23+15] org.apache.kafka.common.security.oauthbearer.internals.OAuthBearerSaslClientCallbackHandler.handleCallback fails with UnsupportedOperationException

[jerboaa]

Describe the bug

In our Mandrel native integration tests we see new failures since the JDK 23+15 ea build in quarkus-integration-test-kafka-oauth-keycloak-999-SNAPSHOT-runner tests:

2024-03-22 02:18:58,664 WARN  [org.apa.kaf.com.net.Selector] (kafka-producer-network-thread | kafka-producer-out) [Producer clientId=kafka-producer-out] Unexpected error from localhost/127.0.0.1 (channelId=-1); closing connection: java.lang.UnsupportedOperationException: getSubject is supported only if a security manager is allowed
	at java.base@23-beta/javax.security.auth.Subject.getSubject(Subject.java:347)
	at org.apache.kafka.common.security.oauthbearer.internals.OAuthBearerSaslClientCallbackHandler.handleCallback(OAuthBearerSaslClientCallbackHandler.java:99)
	at org.apache.kafka.common.security.oauthbearer.internals.OAuthBearerSaslClientCallbackHandler.handle(OAuthBearerSaslClientCallbackHandler.java:83)
	at org.apache.kafka.common.security.oauthbearer.internals.OAuthBearerSaslClient.evaluateChallenge(OAuthBearerSaslClient.java:92)
	at org.apache.kafka.common.security.authenticator.SaslClientAuthenticator.lambda$createSaslToken$1(SaslClientAuthenticator.java:535)
	at java.base@23-beta/jdk.internal.vm.ScopedValueContainer.callWithoutScope(ScopedValueContainer.java:162)
	at java.base@23-beta/jdk.internal.vm.ScopedValueContainer.call(ScopedValueContainer.java:147)
	at java.base@23-beta/java.lang.ScopedValue$Carrier.runWith(ScopedValue.java:74)
	at java.base@23-beta/java.lang.ScopedValue$Carrier.call(ScopedValue.java:419)
	at java.base@23-beta/java.lang.ScopedValue.callWhere(ScopedValue.java:588)
	at java.base@23-beta/javax.security.auth.Subject.callAs(Subject.java:439)
	at java.base@23-beta/javax.security.auth.Subject.doAs(Subject.java:614)
	at org.apache.kafka.common.security.authenticator.SaslClientAuthenticator.createSaslToken(SaslClientAuthenticator.java:535)
	at org.apache.kafka.common.security.authenticator.SaslClientAuthenticator.sendSaslClientToken(SaslClientAuthenticator.java:434)
	at org.apache.kafka.common.security.authenticator.SaslClientAuthenticator.sendInitialToken(SaslClientAuthenticator.java:333)
	at org.apache.kafka.common.security.authenticator.SaslClientAuthenticator.authenticate(SaslClientAuthenticator.java:274)
	at org.apache.kafka.common.network.KafkaChannel.prepare(KafkaChannel.java:181)
	at org.apache.kafka.common.network.Selector.pollSelectionKeys(Selector.java:543)
	at org.apache.kafka.common.network.Selector.poll(Selector.java:481)
	at org.apache.kafka.clients.NetworkClient.poll(NetworkClient.java:585)
	at org.apache.kafka.clients.producer.internals.Sender.runOnce(Sender.java:349)
	at org.apache.kafka.clients.producer.internals.Sender.run(Sender.java:252)
	at java.base@23-beta/java.lang.Thread.runWith(Thread.java:1588)
	at java.base@23-beta/java.lang.Thread.run(Thread.java:1575)
	at org.graalvm.nativeimage.builder/com.oracle.svm.core.thread.PlatformThreads.threadStartRoutine(PlatformThreads.java:836)
	at org.graalvm.nativeimage.builder/com.oracle.svm.core.thread.PlatformThreads.threadStartRoutine(PlatformThreads.java:812)

See: https://github.com/graalvm/mandrel/actions/runs/8384081617/job/22961614228#step:12:968

I'm pretty sure, though, this isn't a native-only issue but can happen in JVM mode on JDK 23+15 as well.

Expected behavior

No java.lang.UnsupportedOperationException: getSubject is supported only if a security manager is allowed is being thrown.

Actual behavior

java.lang.UnsupportedOperationException is being thrown.

How to Reproduce?

Build Integration Tests - Kafka OAUTH with Keycloak native test and run test with a 23-beta+15-ea, vendor version: Mandrel-24.1.0-dev13054560 mandrel build. For example from here.

Additional information

This seems to be caused by https://bugs.openjdk.org/browse/JDK-8296244 freshly part of JDK 23+15. See the CSR on how to possibly fix it: https://bugs.openjdk.org/browse/JDK-8327134

[quarkus-bot]

/cc @Karm (mandrel), @alesj (kafka), @cescoffier (kafka), @galderz (mandrel), @ozangunalp (kafka), @pedroigor (bearer-token), @sberyozkin (bearer-token,security), @zakkak (mandrel)

[cescoffier]

Unfortunately there is not much we can do. It's an issue to report in the Apache Kafka Client.

[jerboaa]

OK. Feel free to bring this to the Apache Kafka Client team.

[gsmet]

Isn't the security manager supposed to go away? I'm surprised they made it mandatory for some operations?

[jerboaa]

Isn't the security manager supposed to go away? I'm surprised they made it mandatory for some operations?

Yes the security manager is going away. The reason this change was done was supporting this move. Please see the CSR of this change which should have all the info needed: https://bugs.openjdk.org/browse/JDK-8327134

It appears a possible work-around is to add -Djava.security.manager=allow. But this comes with the following caveat:

If for some reason, user cannot modify their code in time, they can add
`-Djava.security.manager=allow` on the command line as a workaround.
This allows the old implementation to be used even if a Security Manager is never set.
Please note that in a future version when the Security Manager is completely
removed this workaround would fail.

Hope that helps.

[jerboaa]

@cescoffier Is there an upstream kafka client issue for this? Who would we need to talk to to get it created? I'm hoping to get this on the radar for kafka client folks.

[cescoffier]

Yes, it's an issue for Apache Kafka (the upstream project).

[jerboaa]

Understood. If possible, could somebody create an upstream issue? That tracker seems invite only and I'm not keen on creating one just for a single bug. Could somebody with an (existing) account there file one? Thanks!

https://issues.apache.org/jira/projects/KAFKA/issues