Unable to change unauthenticated response with quarkus-resteasy-reactive

[ivansenic]

Describe the bug

I tried to add a custom exception mapper for unauthenticated exceptions. Followed the instruction on https://quarkus.io/guides/security-built-in-authentication#how-to-customize-authentication-exception-responses. However, although the exception mapper is defined, it's never being invoked. Switching the proactive auth on and off does not have any impact.

The exception mapper is the same as in the documentation:

import io.quarkus.security.AuthenticationFailedException;

import javax.annotation.Priority;
import javax.ws.rs.Priorities;
import javax.ws.rs.core.Context;
import javax.ws.rs.core.Response;
import javax.ws.rs.core.UriInfo;
import javax.ws.rs.ext.ExceptionMapper;
import javax.ws.rs.ext.Provider;


@Provider
@Priority(Priorities.AUTHENTICATION)
public class AuthenticationFailedExceptionMapper implements ExceptionMapper<AuthenticationFailedException> {

    @Context
    UriInfo uriInfo;

    @Override
    public Response toResponse(AuthenticationFailedException exception) {
        // on purpose change to 5xx
        return Response.status(500).entity("Custom body").build();
    }
}

Expected behavior

Response can be customized.

Actual behavior

Always returns the same response:

$ curl 'http://localhost:8080/hello' -u scott:wrong -v
*   Trying 127.0.0.1:8080...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 8080 (#0)
* Server auth using Basic with user 'scott'
> GET /hello HTTP/1.1
> Host: localhost:8080
> Authorization: Basic c2NvdHQ6cmVhZGU=
> User-Agent: curl/7.68.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 401 Unauthorized
* Authentication problem. Ignoring this.
< www-authenticate: basic realm="Quarkus"
< content-length: 0
< 
* Connection #0 to host localhost left intact

How to Reproduce?

Here is the reproducible example: https://github.com/ivansenic/quarkus-25732

Output of uname -a or ver

Linux ise-Precision-5550 5.13.0-41-generic #46~20.04.1-Ubuntu SMP Wed Apr 20 13:16:21 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Output of java -version

openjdk version "17.0.3" 2022-04-19 OpenJDK Runtime Environment (build 17.0.3+7-Ubuntu-0ubuntu0.20.04.1) OpenJDK 64-Bit Server VM (build 17.0.3+7-Ubuntu-0ubuntu0.20.04.1, mixed mode, sharing)

GraalVM version (if different from Java)

No response

Quarkus version or git rev

2.9.1.Final

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

Maven home: /home/ise/.m2/wrapper/dists/apache-maven-3.8.4-bin/52ccbt68d252mdldqsfsn03jlf/apache-maven-3.8.4 Java version: 17.0.3, vendor: Private Build, runtime: /usr/lib/jvm/java-17-openjdk-amd64 Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "5.13.0-41-generic", arch: "amd64", family: "unix"

Additional information

No response

[quarkus-bot]

/cc @FroMage, @geoand, @stuartwdouglas

[ivansenic]

Attached example: https://github.com/ivansenic/quarkus-25732

[sberyozkin]

@ivansenic Thanks, the mapper is tested here, https://github.com/quarkusio/quarkus/blob/main/integration-tests/oidc-code-flow/src/main/java/io/quarkus/it/keycloak/AuthenticationCompletionExceptionMapper.java, https://github.com/quarkusio/quarkus/blob/main/integration-tests/oidc-code-flow/src/test/java/io/quarkus/it/keycloak/CodeFlowTest.java#L696. That test, though quite complex, only passes because the test mapper adds a RedirectUri response header.
The only difference is that that test uses Resteasy Classic, so it appears that with Resteasy Reactive it does not work

[geoand]

I'll have a look tomorrow

[sberyozkin]

Thanks @geoand, I did not mean to say it was just a RestEasy Reactive problem :-), but it might need some tweak, I can create a draft PR with a test

[geoand]

Completely understood 😀

[ivansenic]

Hmm but I am not registering a mapper for AuthenticationCompletionException, but for AuthenticationFailedException. Could it be that I am tragetting a wrong exception class? Can test tomorrow, and if so then this js just a documentation issue.

[geoand]

I just tried your sample and handling the exception with the ExceptionMapper does not work for RESTEasy Classic either.

@sberyozkin I think this is best handled by you, since I am lacking a lot of the security context.
At the very least, I think we need to update the documentation to specify under which conditions using an ExceptionMapper works.

[sberyozkin]

@geoand Thanks. I see that I don't have tests for mapping AuthenticationFailedException but only for AuthenticationCompletionException and I believe users have confirmed it was working for ForbiddenException.

Perhaps intercepting AuthenticationFailedException is not even possible since it is used as a trigger to create authentication mechanism specific challenges

[geoand]

Perhaps intercepting AuthenticationFailedException is not even possible since it is used as a trigger to create authentication mechanism specific challenges

From what I saw from the security code, that does seem to be the case.

[ivansenic]

Just checked and intercepting the AuthenticationCompletionException also does not work.. I updated the reproducible example to showcase it..

[sberyozkin]

@ivansenic quarkus-oidc is throwing AuthenticationCompletionException. I'll clarify in the docs

[geoand]

@sberyozkin is there anything else we can do to improve here?

[sberyozkin]

@geoand I'll be on PTO next week, overflowing into the week which follows and looking at some other open issues right now, but yeah, definitely a few things have to be clarified.

One thing that is certain is that it is impossible to intercept security exceptions with JAX-RS mappers if the proactive authentication is enabled which is a default - the security chain will start before the JAX-RS chain.
So the only way to try to handle it with JAX-RS mappers is to start a security check only when it is determined a JAX-RS method requires it, which is what disabling the proactive authentication does.
I'll review various security exceptions reported and test which ones can be intercepted and which are not in a couple of weeks.

2 other possible options:

• custom HttpAuthenticationMechanism - it might be the only way to intercept AuthenticationFailedException since it triggers a call into HttpAuthenticationMechanism.getChallenge - and this flow must not be broken by interposing exception mappers. @ivansenic if it can be of interest then I can help with a custom mechanism, it is straightforward, one would just inject for ex, BasicAuthenticationMechanism into a custom one and delegate to it and only postprocess a getChallenge response.
• Wire in Vert.x fault handlers into a security code handling the errors, but I'd appreciate some help from Vert.x experts here

[geoand]

Thanks a lot @sberyozkin!

[ivansenic]

@sberyozkin In turns our that I am already implementing a custom HttpAuthenticationMechanism.. Actually it's a straight forward and standard header-based authentication.. Let me try to hook into that getChallenge thingy.. I'll get back to you..

Btw, the header based authentication could be interesting also for contributing back to Quarkus.. Here is a quick showcase on what I did: https://github.com/stargate/stargate/blob/v2.0.0/sgv2-docsapi/src/main/java/io/stargate/sgv2/docsapi/api/common/security/HeaderBasedAuthenticationMechanism.java

[ivansenic]

Yup hooking into challenge works.. Just in case that somebody needs it, here is the reference on how I am setting the custom response: https://github.com/stargate/stargate/blob/304cff3ace476737ab1309a44a20b26bed8a7ad7/sgv2-docsapi/src/main/java/io/stargate/sgv2/docsapi/api/common/security/HeaderBasedAuthenticationMechanism.java#L88-L125

As far as I am concerned, the issue is resolved.

Thanks @geoand @sberyozkin

[geoand]

Thanks for the update @ivansenic .

I'll leave this open because at the very least, we could use a doc update.

[sberyozkin]

@ivansenic Nice one, thanks for quickly verifying the custom mechanism option.
@geoand Yeah, I'll review which security exceptions can be mapped, and add a note re dealing with AuthenticationFailedException

[sberyozkin]

Will look further into it asap, I haven't forgotten

[sberyozkin]

@michalvavrik Hi Michal, did your PR fix this issue as well ? See also #26314

[michalvavrik]

@sberyozkin AuthenticationFailedException here is thrown by io.quarkus.elytron.security.runtime.ElytronPasswordIdentityProvider#authenticate that is called from permissionCheckHandler and it's running before RR begin processing. Here DefaultAuthFailureHandler is used as it would be dangerous to remove it before RR begun processing (it would go to failure handler, probably down to the io.quarkus.vertx.http.runtime.QuarkusErrorHandler and not to the RR exception mappers.

It's actually very much related to the other tickets I work on, let me have a look. It would be nice to have a solution that covers all related cases, not just this reproducer (and it would fix proactive auth stuff too)