Why is redundant path mapping required when using @PermissionsAllowed with Keycloak UMA?

[SDAChess]

Hi everyone,

I’m currently integrating Quarkus Keycloak Authorization with UMA, and I’ve run into a pattern that feels like it requires redundant configuration. I’m wondering if I’m missing a specific setting or if this is a limitation of the current integration.

The Scenario

I have a JAX-RS resource with a method secured like this:

@Path("/hello/permission")
public class MyResource {

    @GET
    @PermissionsAllowed("server:list")
    public String get() { 
        return "Hello"; 
    }
}

The Issue

Even with @PermissionsAllowed present, the request is automatically DENIED (403) by the Policy Enforcer unless I explicitly map the path to the resource name in application.properties:

quarkus.keycloak.policy-enforcer.paths.1.paths=/hello/permission
quarkus.keycloak.policy-enforcer.paths.1.name=server

If I remove the URI from the Keycloak Admin Console and the configuration from application.properties, the logs show that the PolicyEnforcer fails to find a configuration for the path and denies the request before the annotation logic is even evaluated:

DEBUG [org.keycloak.adapters.authorization.PolicyEnforcer] Could not find a configuration for path [/hello/permission]
DEBUG [org.keycloak.adapters.authorization.PolicyEnforcer] Policy enforcement result ... is : DENIED

My Questions

1. Am I missing a "Discovery" setting? Is there a way to tell the Policy Enforcer to use the metadata already provided in the @PermissionsAllowed annotation to identify the resource automatically?
2. Is this mapping intended to be decoupled? It feels like "meaningless configuration" because Quarkus already knows the path (from @Path) and the resource/scope (from @PermissionsAllowed) at build time.
3. Could this be automated? Since Quarkus is built on the principle of augmentation, would it be feasible for the framework to automatically register these path-to-resource mappings during the build scan when @PermissionsAllowed is detected?

[quarkus-bot[bot]]

/cc @sberyozkin (keycloak)

[sberyozkin]

Hi @SDAChess,

Currently, Keycloak authorization policies can only be set in application.properties, annotations like @PermissionsAllowed do not map. @PermissionsAllowed works on the existing properties of the current identity.

It may warrant a new enhancement request where, instead of quarkus.keycloak.policy-enforcer.paths.1.paths=/hello/permission one uses an annotation, which can be neat, but it can't be @PermissionsAllowed but a keycloak authorization specific annotation like @KeycloakAuthorization. Would you be interested in working on the PR ?

A far as the centralized authorization is concerned, #52233 is next so I'm not sure when we can ourselves prioritize on enhancing the quarkus-keycloak-authorization further.

By the way, you can link @PetrmissionsAllowed with @PermissionChecker bean that can be returning Uni - which was nicely done by @michalvavrik, so perhaps this is something that may be of help

[SDAChess]

I also understand that you can technically configure the application.properties to be the single source of truth for this but I find this being a bit difficult to maintain and error prone as the complexity of the API grows, it might be difficult to keep it in sync with the REST resources of the Quarkus application.

[SDAChess]

To build on my previous point, I think the real feature I am looking for here would be allowing a Resource-based rather than a Path-based authorization model.

Currently, the Policy Enforcer is heavily tied to HTTP URIs. My hope is that we could have a mechanism, such as a dedicated annotation, that triggers a direct call to the Keycloak Permission API using the user's token, without caring about the URL whatsoever.

If we decouple the permission check from the HTTP path, this security model becomes immediately implementable for non-RESTful endpoints.

One can imagine securing:

• gRPC services
• GraphQL resolvers
• Message-driven beans

In these cases I can think of, there isn't always a "URI" that maps cleanly to a Keycloak resource. By allowing the annotation to drive the validation API call directly, we simplify the developer experience: you annotate the "What" (the resource/scope) and Quarkus handles the "How" (the UMA token exchange/evaluation), regardless of how the request arrived.

Does that make sense or am I completely off regarding what the purpose of this library is? 😁

[sberyozkin]

@SDAChess

Perhaps a dedicated Keycloak-specific annotation, that explicitly handles the "bridge" between the JAX-RS endpoint and the Keycloak resource/scope, would be a cleaner approach. This would allow for build-time auto-configuration of the Policy Enforcer without overloading the standard security annotations.

Sure, please investigate if it can be of interest

[michalvavrik]

I agree it could be useful and if it is of interest for you, go for it. I would recommend to take it easy, open small-scoped well defined Quarkus issue, we can discuss expectations in there before you start and then you can work on it. I don't want you to be disappointed, that is all. We have many existing issues you could work on.

What Keycloak UMA offers is useful for more complex scenarios, or transferability between applications and so on. Performance wise, it is less effective than Quarkus permissions checkers as these do not require outgoing HTTP communication. It is definitely useful, but we didn't have many users asking questions or opening issues and if we know that Keycloak is heading in a different direction keycloak/keycloak#45288, I'd put no effort into current Keycloak Authorization.

[sberyozkin]

There is some ongoing pressure to use centralized authorization like the one offered by AuthZen API, but indeed, keycloak authorization is probably a legacy solution at this point of time, though I'm sure it works well for many users who are already on it