RR - use exception mappers on auth failure exceptions for proactive auth

[michalvavrik]

fixes: #29896

This is proposal to enable RESTEasy Reactive exception mappers to handle AuthenticationCompletionException, AuthenticationFailedException, AuthenticationRedirectException, ForbiddenException when quarkus.http.auth.proactive=true. I suggest we weight the arguments and decide whether the change is needed in some form or the PR should be closed.

Pros:

• user can use exception mappers when quarkus.http.auth.proactive=false
• it's JAX-RS way that user asked for in the past
• HTTP path matching policy may lead to 403 that will be customizable via exception mappers (after this PR, not down to proactive=true), currently it's only customizable via failure handlers
• by accident, above-mentioned already works for RESTEasy Classic since 2.14 (however we can regress it) and classic/reactive behavior should be same

Cons:

• IMO in reported issues, users seemed complacent about using proactive=false (once Sergey suggested it)
• custom exception mapper that catches AuthenticationFailedException thrown by OIDC is unlikely to send challenge
• currenlty users can customize response via failure handlers after the default auth failure handler has send challenge and failed event (iff auth mechanism didn't end response), therefore it's safer

[sberyozkin]

@michalvavrik Sorry for the delay.
Can you please add a test showing that fault handlers can still be used with the proactive auth enabled if preferred unless we already have the existing test ? I'm not sure why you remove the doc section explaining how to use the fault handlers.
Thanks

[michalvavrik]

@sberyozkin sure, I'll think about it and may add tests next week. I removed the docs section as it says with proactive=true the only way to customize response is to use failure handler, which would no more be true. My issue with user defined failure handler when proactive=true is that with RESTEasy Reactive/Classic they would need negative priority and I don't want to advice that to users. I think primary way for RESTEasy Reactive/Classic should be exception mappers and failure handlers are available for special cases or for non-JAX-RS users (Reactive Routes, pure lambdas?).

[michalvavrik]

Maybe there is another way, let me think about it, I'm currently on sick leave.

[sberyozkin]

@michalvavrik Sorry, take care, no rush at all, lets talk in a few days (I'd consider keeping the doc section but adjusting the advice only when/how to use it - ex, if both basic and code flow are enabled, etc)

[sberyozkin]

@michalvavrik Hey, so the only question on my part here, is the fault route path still working with this PR (can you link to the test please), and if yes, then my only change request is to keep the info about using fault routes in the docs (with some minor updates - it won't longer be the only option)

[michalvavrik]

@michalvavrik Hey, so the only question on my part here, is the fault route path still working with this PR (can you link to the test please), and if yes, then my only change request is to keep the info about using fault routes in the docs (with some minor updates - it won't longer be the only option)

Simply priority adjustment will make failure handlers working again and then I will return docs section & add all relevant tests. I'll do that.

[michalvavrik]

I've added an example and caution note to docs regarding auth mechanism challenge. Together existing test coverage and added tests covers both exception mappers and failure handlers in RESTEasy Reactive and Classic.

[sberyozkin]

@michalvavrik Great work, thanks, left a few minor doc suggestions only

[michalvavrik]

Docs looks better with your comments, thank you.

[quarkus-bot]

Failing Jobs - Building 8ed165f

Status	Name	Step	Failures	Logs	Raw logs
✔️	Gradle Tests - JDK 11
✖	Gradle Tests - JDK 11 Windows	Build	Failures	Logs	Raw logs

Full information is available in the Build summary check run.

Failures

⚙️ Gradle Tests - JDK 11 Windows #

- Failing: integration-tests/gradle 

📦 integration-tests/gradle

✖ io.quarkus.gradle.devmode.JandexMultiModuleProjectDevModeTest.main line 21 - More details - Source on GitHub

org.awaitility.core.ConditionTimeoutException: Condition with lambda expression in io.quarkus.test.devmode.util.DevModeTestUtils that uses java.util.function.Supplier, java.util.function.Supplierjava.util.concurrent.atomic.AtomicReference, java.util.concurrent.atomic.AtomicReferencejava.lang.String, java.lang.Stringboolean was not fulfilled within 1 minutes.
	at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
	at org.awaitility.core.CallableCondition.await(CallableCondition.java:78)