Introduce build item representing permissions

[knutwannheden]

Description

Currently the permissions of REST resources is captured either using javax.annotation.security annotations like @RolesAllowed or using the quarkus.http.auth.permissions config properties. Similarly the role-based policies are set using the quarkus.http.auth.role-policy config properties.

While there is a dedicated build item representing the policies (HttpSecurityPolicyBuildItem) there is nothing equivalent for the permissions, which are processed by a recorder in the static-init phase in PathMatchingHttpSecurityPolicy#init().

Use Case

I think it would be useful to have a build item for permissions as well. Our use case is the following: We are building a platform based on Quarkus, which includes some REST endpoints for features "delivered" as Quarkus extensions. We want to dynamically add permissions to these resources based on whether the downstream application has enabled security or not and possibly also allow the application to provide the actual roles. This would be possible in the downstream project using the quarkus.http.auth.permissions config properties (e.g. add them to application.properties). We would however prefer the Quarkus extension in the platform to provide the default permissions for its resources. One reason for this is that we want to be able to add new resources and don't want to depend on the downstream projects to setup the permissions correctly.

Currently our Quarkus extension supplies a set of quarkus.http.auth.permissions config properties, but this is fragile and imposes some restrictions with regards to how the quarkus.http.root-path, quarkus.http.non-application-root-path, and quarkus.rest.path properties are set by the downstream project, which isn't very satisfactory.

Also note that we in the platform would like to define the permissions for some endpoints provided by Quarkus (like /q/metrics). Also here we use the config properties:

quarkus.http.auth.permission.metrics.paths=${quarkus.http.root-path}${quarkus.http.non-application-root-path}/metrics
quarkus.http.auth.permission.metrics.policy=foo

Implementation ideas

Add a new build item for permissions similar to the HttpSecurityPolicyBuildItem build item for policies and then allow extensions to produce such build items.

[sberyozkin]

@michalvavrik FYI, HttpSecurityPolicyBuildItem is in use

[michalvavrik]

@michalvavrik FYI, HttpSecurityPolicyBuildItem is in use

true; I think this should be closed by #36874 for it won't be possible now that they are runtime and extensions can define runtime config builder to pre-configure permissions for users. I'll comment here again when named runtime policies are done (even though this issue name only talks permissions)

[michalvavrik]

Hello @knutwannheden,

the HttpSecurityPolicyBuildItem is now deprecated and permissions and policies has been moved to runtime by #37017, #37022 and #36874, therefore it won't be possible to have build item representing permissions.

You want to dynamically create permissions based on whether downstream application has enabled security. Properties that enables security are still build-time properties, therefore you can produce configuration permissions like any other runtime configuration properties with io.quarkus.deployment.builditem.RunTimeConfigBuilderBuildItem or define config source etc. (please see SmallRye Config for your options).

Also note that we in the platform would like to define the permissions for some endpoints provided by Quarkus (like /q/metrics). Also here we use the config properties:

I also believe that is possible now.

I'm going to close this as not planned, but if you still need some improvements in this area, please open new issue based on current state as this one can't be done. Thank you.

[michalvavrik]

For non-application endpoints you will need to use quarkus.management.auth.permission.*.