Keycloak Integration

Describe the bug

We have integrated Keycloak and OIDC extensions with Quarkus version 3.18.3. Everything works fine, but once in a while we get the an exception about EagerSecurityHandler.instance being null upon sending a request to an endpoint that requires authorization.

Expected behavior

If some error is occuring on our side, it should be well reported by the system. If it is on Quarkus side, it should also be reported and recovered.

Actual behavior

java.lang.NullPointerException: Cannot read field "authorizationController" because "io.quarkus.resteasy.reactive.server.runtime.security.EagerSecurityContext.instance" is null
        at io.quarkus.resteasy.reactive.server.runtime.security.EagerSecurityHandler.handle(EagerSecurityHandler.java:53)
        at io.quarkus.resteasy.reactive.server.runtime.QuarkusResteasyReactiveRequestContext.invokeHandler(QuarkusResteasyReactiveRequestContext.java:150)
        at org.jboss.resteasy.reactive.common.core.AbstractResteasyReactiveContext.run(AbstractResteasyReactiveContext.java:147)
        at org.jboss.resteasy.reactive.server.handlers.RestInitialHandler.beginProcessing(RestInitialHandler.java:48)
        at org.jboss.resteasy.reactive.server.vertx.ResteasyReactiveVertxHandler.handle(ResteasyReactiveVertxHandler.java:23)
        at org.jboss.resteasy.reactive.server.vertx.ResteasyReactiveVertxHandler.handle(ResteasyReactiveVertxHandler.java:10)
        at io.vertx.ext.web.impl.RouteState.handleContext(RouteState.java:1281)
        at io.vertx.ext.web.impl.RoutingContextImplBase.iterateNext(RoutingContextImplBase.java:177)
        at io.vertx.ext.web.impl.RoutingContextWrapper.next(RoutingContextWrapper.java:205)
        at io.quarkus.vertx.http.runtime.options.HttpServerCommonHandlers$1.handle(HttpServerCommonHandlers.java:62)
        at io.quarkus.vertx.http.runtime.options.HttpServerCommonHandlers$1.handle(HttpServerCommonHandlers.java:40)
        at io.vertx.ext.web.impl.RouteState.handleContext(RouteState.java:1281)
        at io.vertx.ext.web.impl.RoutingContextImplBase.iterateNext(RoutingContextImplBase.java:177)
        at io.vertx.ext.web.impl.RoutingContextWrapper.next(RoutingContextWrapper.java:205)
        at io.quarkus.vertx.http.runtime.security.AbstractHttpAuthorizer.doPermissionCheck(AbstractHttpAuthorizer.java:94)
        at io.quarkus.vertx.http.runtime.security.AbstractHttpAuthorizer$1.accept(AbstractHttpAuthorizer.java:107)
        at io.quarkus.vertx.http.runtime.security.AbstractHttpAuthorizer$1.accept(AbstractHttpAuthorizer.java:100)
        at io.smallrye.context.impl.wrappers.SlowContextualConsumer.accept(SlowContextualConsumer.java:21)
        at io.smallrye.mutiny.helpers.UniCallbackSubscriber.onItem(UniCallbackSubscriber.java:73)
        at io.smallrye.mutiny.operators.uni.UniOnItemTransformToUni$UniOnItemTransformToUniProcessor.onItem(UniOnItemTransformToUni.java:60)
        at io.smallrye.mutiny.operators.uni.UniOnItemTransform$UniOnItemTransformProcessor.onItem(UniOnItemTransform.java:43)
        at io.smallrye.mutiny.operators.uni.UniOnItemTransformToUni$UniOnItemTransformToUniProcessor.onItem(UniOnItemTransformToUni.java:60)
        at io.smallrye.mutiny.operators.uni.builders.UniCreateFromCompletionStage$CompletionStageUniSubscription.forwardResult(UniCreateFromCompletionStage.java:63)
        at java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:863)
        at java.base/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:841)
        at java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:510)
        at java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2147)
        at io.vertx.core.Future.lambda$toCompletionStage$3(Future.java:602)
        at io.vertx.core.impl.future.FutureImpl$4.onSuccess(FutureImpl.java:176)
        at io.vertx.core.impl.future.FutureBase.lambda$emitSuccess$0(FutureBase.java:60)
        at io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:173)
        at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:166)
        at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472)
        at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:569)
        at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:998)
        at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
        at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
        at java.base/java.lang.Thread.run(Thread.java:840)

How to Reproduce?

Not really sure how to replicate it.

Output of uname -a or ver

Linux MustafaMachine 6.1.0-27-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.115-1 (2024-11-01) x86_64 GNU/Linux

Output of java -version

openjdk version "17.0.13" 2024-10-15 OpenJDK Runtime Environment (build 17.0.13+11-Debian-2deb12u1) OpenJDK 64-Bit Server VM (build 17.0.13+11-Debian-2deb12u1, mixed mode, sharing)

Quarkus version or git rev

3.18.3

Build tool (ie. output of mvnw --version or gradlew --version)

Apache Maven 3.9.9 (8e8579a9e76f7d015ee5ec7bfcdc97d260186937) Maven home: /home/mustafa/.m2/wrapper/dists/apache-maven-3.9.9-bin/33b4b2b4/apache-maven-3.9.9 Java version: 17.0.13, vendor: Debian, runtime: /usr/lib/jvm/java-17-openjdk-amd64 Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "6.1.0-27-amd64", arch: "amd64", family: "unix"

Additional information

No response

[quarkus-bot]

/cc @pedroigor (keycloak), @sberyozkin (keycloak)

[sberyozkin]

@MustafaOtbah It can be hard to find out the cause without a reproducer, can you create it ?
@michalvavrik Michal, can it be a race condition?

[michalvavrik]

This is initialized before HTTP router accepts requests, so I don't think that stacktrace makes sense when Security extension is present (which it is judging by the fact you use OIDC). I am not sure how this can happen, but it is easy to make this bulletproof. I'll refactor it in a bit, shouldn't cost us (almost) anything.

[michalvavrik]

I wonder if this can occur close to Quarkus application shutdown @MustafaOtbah ?

[michalvavrik]

Hey, I think this #46438 should effectively limit possibility of NPE to zero. Thanks for info @MustafaOtbah , if you have more context or if you experience the issue once you upgrade to Quarkus with the fix, please let us know.

@michalvavrik I think you are right, it could happen when the application shuts down. The application was running normally though but in development mode. I think there is a mechanism where some parts shut down when it compiles new code. Could this be the case?
The EagerSecurityContext.instance was not null, because the application was running correctly, but at some point this has happened. The whole application stopped responding for few minutes.

Unfortunately I am not aware of how to reproduce the error. The stacktrace does not help me either understand how it could happen unless I look into how Quarkus was written. But if I find some pattern I will definitely report it. Thanks for the fix.

[michalvavrik]

@michalvavrik I think you are right, it could happen when the application shuts down. The application was running normally though but in development mode. I think there is a mechanism where some parts shut down when it compiles new code. Could this be the case?

yes, it seems like the most likely candidate

Unfortunately I am not aware of how to reproduce the error. The stacktrace does not help me either understand how it could happen unless I look into how Quarkus was written. But if I find some pattern I will definitely report it. Thanks for the fix.

np, thanks