How to enable (proactive) authentication for custom programmatic reactive routes

[jfbenckhuijsen]

Hi, how can I enable (proactive) authentication on reactive routes which I added using the Vert.x web router interface

    public void registerRoutes(@Observes Router router) {
        loginPath.ifPresent(path -> {
            router.route(HttpMethod.POST, path)
                    .handler(this::sendCookieResponse);
        });
    }

It looks like if I add this router, HTTP authentication from Quarkus security is not triggered. However I can't seem to find a way to register a handler which enables the authentication.

(Background; I'm working on a new feature for the Quarkiverse Google Cloud extension to support session based cookies. I need to be able to create a custom route (the user of the extension can configure the endpoint path). The custom routes needs access to the principal created by Quarkus Security to create a cookie based on the JWT Token).

[sberyozkin]

I believe you should use Quarkus reactive routes, is it correct @michalvavrik ?

By the way, not sure if it is relevant, but the Google Cloud project is integrated indirectly with Quarkus OIDC, there is a section about it in the OIDC code flow authentication doc, sorry for not providing a link as I'm on my phone

[jfbenckhuijsen]

I do use the reactive routes (the above code is from my - uncommitted - changes in my feature branch).

As for OIDC, the extension deals with integration with Firebase authentication, which has some extra features over basic Google stuff. The current extension already supports this, I'm currently working on adding the cookie based authentication.

[michalvavrik]

I believe we need more context because I don't understand what you try to do and how. For example:

It looks like if I add this router, HTTP authentication from Quarkus security is not triggered.

We have loads of tests in Vert.x HTTP deployment module that add a handle and authentication happens.

However I can't seem to find a way to register a handler which enables the authentication.

if it is a route on HTTP router, the HTTP authenticator is present and by default proactive authentication happens.

The custom routes needs access to the principal created by Quarkus Security to create a cookie based on the JWT Token).

Use io.quarkus.vertx.http.runtime.security.QuarkusHttpUser#getSecurityIdentity(io.vertx.ext.web.RoutingContext, io.quarkus.security.identity.IdentityProviderManager).

Knowing following context would help:

• how is authentication enforced? Do you use:
  • https://quarkus.io/guides/security-authorize-web-endpoints-reference#authorization-using-configuration
  • https://quarkus.io/guides/security-authorize-web-endpoints-reference#standard-security-annotations
  • do you trigger authentication yourselfs by subscribing to the identity uni and fail if identity is anonymous?

As for Reactive Routes, they will work and do some work for you regarding CDI context, but your snipped above can work too.

[michalvavrik]

Or better io.quarkus.security.identity.SecurityIdentity#getCredential.

[jfbenckhuijsen]

Follow up: injection of Securityidenty works, however a proxy is returned, so can't cast it to FirebasePrincipal. Probably due to that TODO?

I think you got this wrong, you definitely can inject identity and cast it's principal. SecurityIdentityProxy returns original proxy. For more info, see below.

I'll have a look at the QuarkusHttpUser route. From an end-user application I'd rather not be bound to that, but given this is an extension binding it a bit more to Quarkus itself seem fine

Well, I just want you to understand that if users used augmentor or Quarkus needed to wrap the identity for other reason (like because we needed to propagate RoutingContext) casting won't work anyway. It is fragile concept to expect that what you returned is what is result of the authentication process. I propose to use SecurityIdentity attributes instead.

yeah already punched myself for that. Tried the SecurityIdentity route, which has the downside that the request context isn't active. I could fix that probably using @ActivateRequestContext, but the QuarkusHttpUser just works.

That would be using the casting approach for now.

As for the getCredetial route, lemme check if I understand correctly. I would need to get access to the original JWT Token (the raw string version), with the guarantee that it has been verified (hence retrieving it via the SecurityIdentity/QuarkusHttpUser route), If I would go via the getCredential approach I would need to:

1. Introduce a credential class to hold the original token (or use TokenCredential from quarkus itself)
2. Add that credential to the logic creating the SecurityIdentity (which is in the extension already)
3. Retrieve the credential using getCredantial(Class) in the cookie exchange logic

Correct?

[michalvavrik]

You don't need credentials, I didn't know how your mechanism looks like. So if OIDC does:

builder.addCredential(request.getToken());

that is fine but you have https://github.com/quarkiverse/quarkus-google-cloud-services/blob/main/firebase-admin/runtime/src/main/java/io/quarkiverse/googlecloudservices/firebase/admin/runtime/authentication/http/FirebaseAuthenticationRequest.java#L11 so just store it as identity attribute and request it from injected identity. If you don't see your users changing principal in augmentor, there you can continue casting principal and you are done.

[michalvavrik]

If I would go via the getCredential approach I would need to

yes

[jfbenckhuijsen]

Awesome, tnx!