Use failure handlers for security exceptions before JAX-RS chain starts

[michalvavrik]

fixes: #28489
fixes: #28488

Make it possible to customize response when Quarkus Security authentication exceptions are thrown before JAX-RS chain started. That is done by failing event when proactive security is enabled and ensuring default failure handler QuarkusErrorHandler sends response if it wasn't sent downstream. We should provide a way to customize response as users were asking for it and currently it's not possible f.e. when smallrye-jwt receives invalid token to customize response.

[quarkus-bot]

Failing Jobs - Building 1a299fc

Status	Name	Step	Failures	Logs	Raw logs
✔️	JVM Tests - JDK 11
✖	JVM Tests - JDK 11 Windows	Build	Failures	Logs	Raw logs
✔️	JVM Tests - JDK 17
✖	JVM Tests - JDK 17 MacOS M1	Set up job	⚠️ Check →	Logs	Raw logs
✔️	JVM Tests - JDK 18

Full information is available in the Build summary check run.

Failures

⚙️ JVM Tests - JDK 11 Windows #

- Failing: extensions/opentelemetry/deployment 
! Skipped: integration-tests/micrometer-prometheus integration-tests/opentelemetry integration-tests/opentelemetry-grpc and 5 more

📦 extensions/opentelemetry/deployment

✖ io.quarkus.opentelemetry.deployment.instrumentation.RestClientOpenTelemetryTest.path line 132 - More details - Source on GitHub

org.opentest4j.AssertionFailedError: expected: <SERVER> but was: <CLIENT>
	at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
	at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)

[sberyozkin]

LGTM, thanks @michalvavrik.

Next, we can revisit your idea of allowing to get into the application code to map the error even if the proactive authentication is enabled, and combine it with the generic failure handler approach

[michalvavrik]

Next, we can revisit your idea of allowing to get into the application code to map the error even if the proactive authentication is enabled, and combine it with the generic failure handler approach

For RESTEasy Reactive that would be as simple as removing this boolean https://github.com/quarkusio/quarkus/blob/main/extensions/resteasy-reactive/quarkus-resteasy-reactive/runtime/src/main/java/io/quarkus/resteasy/reactive/server/runtime/ResteasyReactiveRecorder.java#L228. It has no real value except of stopping exception mappers from receiving auth failures when proactive auth is enabled :-) For classic it might be harder, don't know yet. We can wait with next step as there have been a lot of changes in that area (whatever you want); now I have #5751 to deal with and it's strongly related.