Need authorization without authentication

[pantaoran]

Feature or Problem Description

In my enterprise environment, we have Apicurio running behind an API GW. The gateway takes care of authenticating the user in a standardized way (we can choose between different methods and decided for OIDC client credentials) and forwards the authenticated identity (JWT token in http header) to Apicurio.
What I want: Apicurio should take that authenticated identity and make authorization decisions based on it, without trying to perform its own authentication.

Proposed Solution

Reading the Apicurio docs, it seems like authentication and authorization are tightly coupled. To achieve owner-based access control (OBAC), I need to either integrate Keycloak or Azure AD, but both solutions would first perform their own authentication.
My wish is to have a possibility of decoupling. I already have authentication solved in the API gateway, so I don't want Apicurio to do that again.

Additional Context

In the version 2.5 of Apicurio there is a basically undocumented feature called multitenancy. This seems to fulfill my needs well, but unfortunately it is being removed in v3.0. Now I'm wondering what to use in the future.

[EricWittmann]

This is an interesting use-case, and I don't think it would take too much effort to implement. Authentication and Authorization are actually already quite decoupled within Registry. I think the key would be to implement a Quarkus Authentication Mechanism that would consume the JWT bearer token without actually validating it. It needs to populate the Quarkus security context (or whatever its called, I need to refresh my memory). Once that is done, all of the existing authorization logic would work just fine.

Note: I wonder if Quarkus already has such a mechanism.

I guess we would need to enhance this:

https://github.com/Apicurio/apicurio-common-app-components/blob/main/auth/src/main/java/io/apicurio/common/apps/auth/authn/AppAuthenticationMechanism.java

What do you think, @carlesarnal ?

[EricWittmann]

@pantaoran I'm curious - how are you trusting that the JWT is valid? I'm assuming Registry is not accessible other than through the Gateway? Do you have trust in your network security or are you using MTLS or something similar?

[pantaoran]

Good questions. Firstly, we only open the firewall to the registry for the Gateway, so that's one layer.
Secondly, the Gateway usually sends its TLS client certificate with connections to its backends, but we have not figured out how to configure Apicurio to validate that. Would that be possible in this scenario where we would need to first validate the client cert but then ignore that and use the forwarded JWT token for client identification?

[EricWittmann]

I don't think validation of TLS client cert helps with consuming the forwarded JWT bearer token. I just think it's useful to ensure overall security of the architecture. :)

I do think Quarkus can do MTLS (Registry is a Quarkus application). We haven't actually tried doing it ourselves yet though:

https://quarkus.io/blog/quarkus-mutual-tls/

I think all of the config mentioned in that blog post can be passed via equivalent ENV variables successfully to the Registry backend.

In any case, I think the core request of an auth mechanism that will consume a JWT without validating it may need some implementation on our end. I'll check with the Quarkus team and see what they have to say...

[EricWittmann]

It seems the way to do this in Quarkus is to provide a custom implementation of JWTCallerPrincipalFactory. The default impl is here:

• https://github.com/smallrye/smallrye-jwt/blob/main/implementation/jwt-auth/src/main/java/io/smallrye/jwt/auth/principal/DefaultJWTTokenParser.java

I presume that's what is being called right now, since we aren't setting anything custom.

@carlesarnal wdyt?

[carlesarnal]

It seems the way to do this in Quarkus is to provide a custom implementation of JWTCallerPrincipalFactory. The default impl is here:

• https://github.com/smallrye/smallrye-jwt/blob/main/implementation/jwt-auth/src/main/java/io/smallrye/jwt/auth/principal/DefaultJWTTokenParser.java

I presume that's what is being called right now, since we aren't setting anything custom.

@carlesarnal wdyt?

Yes, that's very likely what would be needed to implement such a feature. That said, I would like to explore this as part of a the broader authorization implementation I'm planning for 3.x. Just as a note, I don't think multitenancy solves the problem since Keycloak (or other OIDC servers) is still involved there.