gRPC: Perform authentication when gRPC server runs on the same server and root path is different than '/'

[michalvavrik]

• fixes https://quarkusio.zulipchat.com/#narrow/channel/187030-users/topic/Quarkus.20gRPC.20Security.20and.20http.2Eroot.2Epath
• main router doesn't have authentication and authorization handlers, we attach them to the HTTP router, however gRPC is attached to a main router when the root path is different than '/'

[cescoffier]

Looks good, thanks!

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit 2c58e9f.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

You can consult the Develocity build scans.

---

Flaky tests - Develocity

⚙️ JVM Tests - JDK 17

📦 integration-tests/opentelemetry

✖ io.quarkus.it.opentelemetry.MetricsTest.directCounterTest - History

• Condition with Lambda expression in io.quarkus.it.opentelemetry.MetricsTest was not fulfilled within 5 seconds. - org.awaitility.core.ConditionTimeoutException

org.awaitility.core.ConditionTimeoutException: Condition with Lambda expression in io.quarkus.it.opentelemetry.MetricsTest was not fulfilled within 5 seconds.
	at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
	at org.awaitility.core.CallableCondition.await(CallableCondition.java:78)
	at org.awaitility.core.CallableCondition.await(CallableCondition.java:26)
	at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:1006)
	at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:975)
	at io.quarkus.it.opentelemetry.MetricsTest.directCounterTest(MetricsTest.java:57)
	at java.base/java.lang.reflect.Method.invoke(Method.java:569)

[michalvavrik]

I slept on #45861 and realized that HTTP authorizer is not applied due to

quarkus/extensions/grpc/runtime/src/main/java/io/quarkus/grpc/runtime/GrpcServerRecorder.java

Line 207 in b4287d5

} else if (ctx.get(HttpAuthenticator.class.getName()) != null) {

. There are tests for HTTP Security policies with gRPC, but I created them to detect hanging (verify fix), not to test authorization, therefore they didn't fail #45861. Documentation https://quarkus.io/guides/grpc-service-implementation#secure-grpc-service says clearly that security annotations are a way to secure gRPC services and there is not a single mention of HTTP permissions.

Now I wonder, either drop filter.getPriority() == FilterBuildItem.AUTHORIZATION because it is misleading or support & test & document HTTP Security policies with gRPC. I am not sure it makes sense to support HTTP Security policies with gRPC.

Apologies I didn't realize it sooner.