Add annotation to allow using custom CDI bean methods as permission checkers

[michalvavrik]

• Closes: Idea for custom permission annotations that can work on user model and endpoint parameters #43238

This PR is ready for review, however CI cannot run until quarkusio/quarkus-security#56 is merged and Quarkus Security API is released and bumped in the Quarkus project.

[sberyozkin]

Thanks @michalvavrik, sorry for the delay, will start looking tomorrow, need to sign off now

[michalvavrik]

Thanks @michalvavrik, sorry for the delay, will start looking tomorrow, need to sign off now

no worry, if don't have API anyway (I run all the related tests locally, so I don't expect CI issues), take your time, this won't be easy to review even though this PR consist mostly of tests

[sberyozkin]

This is going to be a massive feature, thanks @michalvavrik

[michalvavrik]

I've addressed @FroMage and @cescoffier comments (thanks!) and added required validations and their tests. Specifically I believe extensions/resteasy-reactive/rest/deployment/src/test/java/io/quarkus/resteasy/reactive/server/test/security/PermissionCheckerOnEndpointValidationFailureTest.java addresses @gsmet concern that @PermissionChecker and @PermissionsAllowed could be confused with each other. I also pinged Guillaume and asked for a Quarkus Security release when the time is right for him.

[michalvavrik]

Although I made changes when there was electricity outage, now that I rerun all the test, there was ugly hack on ExecutionModelAnnotationsProcessor that I had to workaround so that this validation would work. It works now, I am not happy about this though.

[michalvavrik]

No sorry, ExecutionModelAnnotationsAllowedBuildItem is not reliable check whether method is an entrypoint or not as it has false positives for checkers declared on resources. I'll just drop that validation.

[quarkus-bot]

Status for workflow Quarkus Documentation CI

This is the status report for running Quarkus Documentation CI on commit ee1c852.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

Warning

There are other workflow runs running, you probably need to wait for their status before merging.

[github-actions]

🙈 The PR is closed and the preview is expired.

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit ee1c852.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

You can consult the Develocity build scans.

[michalvavrik]

CI is green!

[sberyozkin]

Thanks @michalvavrik for completing this important enhancement.

@gsmet Are you still somewhat concerned with how it will all stand against the code evolution or have some other concerns ? I think we are ready to merge otherwise as @cescoffier has also approved.

Note we hope some internal code made to support this PR may go, with more simplifications planned

[michalvavrik]

Thanks @michalvavrik for completing this important enhancement.

@gsmet Are you still somewhat concerned with how it will all stand against the code evolution or have some other concerns ? I think we are ready to merge otherwise as @cescoffier has also approved.

Note we hope some internal code made to support this PR may go, with more simplifications planned

I think @gsmet won't be around for next 4 days starting tomorrow. It has been 2 weeks since we discussed it here quarkusio/quarkus-security#56.

While I am personally fine with waiting for whatever time, I don't believe it is necessary. It takes but a minute to give heads up that you need more time to review. I will try to address any concerns raised whether it is now or when PR is merged. Thanks

[michalvavrik]

That said, let's wait, I didn't mean to press you :-)

[sberyozkin]

Sure, let me merge, @gsmet, please ping us any time to clarify the details, a brief summary of the PR:

• Any @PermissionAllowed restriction on a JAX-RS endpoint can be approved/denied with a boolean method which accepts one or more request parameters and/or the already verified security identity and is annotated with a matching @PermissionChecker.
• @michalvavrik added a lot of tests. 2 specific tests which may help address your earlier concerns are about failing when 1) @PermissionChecker is attached by mistake to the JAX-RS method and 2) @PermissionChecker does not have a matching @PermissionAllowed (correctly placed on the JAX-RS method)