/cc @pedroigor (bearer-token)

cc @FroMage

I think we should do that. Will put this on my list. One thing I am not sure is id you used in params = "id". In your example, it refers to @PathParam("id"), but so far, params always refer to the formal parameter name. I think it could be confusing. Maybe we could do either aBeanParam.organizationUnitId or simply organizationUnitId. The latter could be ambiguous. I'd prefer aBeanParam.organizationUnitId. Thoughts?

IMHO the parameter-naming conventions should be the same, regardless if it is a directly defined method-parameter or capsulated in a BeanParam.
In my tests, i used the same String used as @PathParam-name in the @PermissionAllowed-params:

@GET
@Path("{id}/2params")
@PermissionsAllowed(value = "read", permission = OrganizationUnitIdPermission.class, params = "id") 
public OrganizationUnit find2(@PathParam("id") UUID aOrganizationUnitId, @QueryParam("second") UUID aSecondUUIDParam) {
       ...
 }

I just checked: using aOrganizationUnit as params also works.
I don't know if that is correct by any definition, but it's convinient 😉

In my tests, i used the same String used as @PathParam-name in the @PermissionAllowed-params:

yeah, honestly, I really hoped your example was a typo. I wrote decent Javadoc to it that describes expected behavior https://github.com/quarkusio/quarkus-security/blob/main/src/main/java/io/quarkus/security/PermissionsAllowed.java#L156

I think I forgot to add validation exception when id is not found and there is at least one UUID. The aOrganizationUnitId is chosen because it has the first parameter type assignable to UUID and inside your OrganizationUnitIdPermission you have matching name in constructor: UUID aOrganizationUnitId

TL;DR; it's documented and works for you as expected, but I think we need to inform user if he specifically types id and it's not found.

I'll add it when I get to implementing this issue (which won't be immediately). It's more of user experience improvement than bug.

I'd expect you can just drop params = id and it will work anyway on the same principle, but aOrganizationUnitId would be right value if you don't want to rely on order of params.

TL;DR; it's documented and works for you as expected, but I think we need to inform user if he specifically types id and it's not found.

👍

Seeing this, I'm curious about how you populate your user's permissions. Out of curiosity, @ChMThiel how do you add the permissions to you user identity for all the aOrganizationUnitId? Are these coming from Keycloak or a DB or what exactly?

I'd prefer aBeanParam.organizationUnitId. Thoughts?

@michalvavrik agreed.

Seeing this, I'm curious about how you populate your user's permissions. Out of curiosity, @ChMThiel how do you add the permissions to you user identity for all the aOrganizationUnitId? Are these coming from Keycloak or a DB or what exactly?

We are currently workin on a POC for restricting User's access to certain OrganizationUnits. Which user may acces what will be stored in a DB.

OK, so you have those stored in your DB, so they're in your model. Thanks.

@ChMThiel The JAX-RS parameter name is the bean parameter name, I'm not sure we have to start unwrapping it

IMHO the parameter-naming conventions should be the same, regardless if it is a directly defined method-parameter or capsulated in a BeanParam.

Why ? The custom permission class is not a JAX-RS thing. What is difficult or not dev friendly about accessing a query parameter as bean.getMyQueryParam() ?
Users choose to use BeanParam to have multiple parameters nicely wrapped in a single container. IMHO we should not try to unwrap it all for custom permissions

Without unwrapping we need a separate Permission-Class for each BeanBaram-Class containing the parameter (in my example 'aOrganinzationUnitId').
We have hundrets of APIs that take such a parameter but almost every of the API combines it's parameters in it's own BeanParam-class.
If unwrapping will not be implemented the only workaround would by to create an interface that all of our BeanParam-classes implement and to use this interface in the Permission-class (but i did not try that yet. not sure if working with an interface works here)

I see, I got it now, thanks @ChMThiel, @michalvavrik

Without unwrapping we need a separate Permission-Class for each BeanBaram-Class containing the parameter (in my example 'aOrganinzationUnitId'). We have hundrets of APIs that take such a parameter but almost every of the API combines it's parameters in it's own BeanParam-class. If unwrapping will not be implemented the only workaround would by to create an interface that all of our BeanParam-classes implement and to use this interface in the Permission-class (but i did not try that yet. not sure if working with an interface works here)

It's almost as if I wrote it :-D +1