-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RESTEasy Reactive - prevent repeating of standard security checks #26567
RESTEasy Reactive - prevent repeating of standard security checks #26567
Conversation
This comment has been minimized.
This comment has been minimized.
Thanks for this! CI seems unhappy however :) |
c09d7f7
to
870c78e
Compare
@michalvavrik Thanks, it looks technically totally fine, thanks for working out how to handle it. |
@sberyozkin yes, it would be possible and I actually already had it in progress... I stopped as the binding is between annotation (and its values) and the interceptor, not between method and the interceptor. Please remember we still need other annotated methods not checked by I had in progress Is that how you meant it? |
My point is that the check can only be removed on "method invocation" scope, not request scope as you need nested CDI beans to be able to perform its own (different checks) within same request. |
Hey @michalvavrik the last thing that should be of concern is if some code in PR can make me less excited :-), you keep creating good quality PRs I may not be even getting from the first round of review :-). |
This comment has been minimized.
This comment has been minimized.
Sure, I'll find a build time solution as discussed. I changed PR to draft then. |
870c78e
to
0665fa1
Compare
0665fa1
to
68d5fb0
Compare
This comment has been minimized.
This comment has been minimized.
@sberyozkin ready for review |
@michalvavrik Great, sorry for a delay, can you please resolve the conflict ? |
68d5fb0
to
0b92d3b
Compare
Sure, conflict resolved. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@michalvavrik I think this is a very nicely researched and done PR.
However, I think we need to get at least one more review as there might be some details that I've missed.
Thanks
0b92d3b
to
a5c9818
Compare
@mkouba Hi Martin, can you please have a look at the Arc related code in this PR when you are get a chance ? |
I personally don't like the concept of "interceptor binding filtering", as it seems too easy to misuse, but I didn't see the code, so my hesitation is really quite a bit uninformed. That said, let me draw a parallel with a very similar problem I'm facing with SmallRye Fault Tolerance (#21431). If a JAX-RS resource method is annotated It makes me wonder: is there an easy way to figure out if an intercepted method is a JAX-RS resource method? An interceptor (be it the security interceptor, or the fault tolerance interceptor) could adjust its behavior based on that. I think resource methods always have to have the HTTP verb annotation ( |
I like the idea @Ladicek, but I am wondering if we can make it a little more general. |
That would be great, I also thought about that a little -- problem is that the invocation context starts to exist only when the method in question is actually invoked. So at the point when RESTEasy Reactive does the security check, there's no shared storage for that information. A request-scoped bean might work, but it would bring a hard dependency on context propagation. What I can imagine is ArC exposing an API for invoking a method and adding some contextual information to the invocation context. I guess RESTEasy Reactive currently has to have some code that invokes the resource method. I don't know how it looks, but if the invocation is reflective, there must be something like this: Map<String, Object> data = Map.of("resteasy.reactive.resource.method", Boolean.TRUE);
Arc.container().runWithInterceptionContext(() -> method.invoke(instance, params), data); (It would probably be a bit more complex, but you get the idea...) |
The invocation in RR is not reflective, it's generated code, so we can do whatever we like in there :) |
Right, gotcha. The API I suggest above still requires some form of out-of-band communication, but that would now have a very short lifespan, so a thread local variable should be fine. It would still be quite a bit unsafe. Maybe @mkouba can think of something better/safer, but I think the approach should work. |
👍🏼 |
I just realized that the concept of "executable methods", which we unfortunately failed to explore in the CDI 4.0 timeframe (see jakartaee/cdi#460), would be a perfect fit for this. If we had that, it would likely be straightforward to extend to support extending the context data map. Oh well. |
Well, there's no such thing like "CDI execution context". Yes, we have
It's safe until the execution is offloaded to a different thread. I think that an idiomatic solution would be to introduce a new interceptor with priority |
@mkouba that was my solution number one (it's already implemented), as long as other agrees, we could use interceptor solution for now. |
Fine with me |
809091d
to
110a083
Compare
Done. |
.../security/runtime/src/main/java/io/quarkus/security/runtime/interceptor/SecurityHandler.java
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added a minor comment, but otherwise this is a good with me!
@sberyozkin, @mkouba mind taking a look as well?
...rity/runtime-spi/src/main/java/io/quarkus/security/spi/runtime/SecurityHandlerConstants.java
Outdated
Show resolved
Hide resolved
110a083
to
e2e94f1
Compare
I've added a minor comment too and it's already addressed ;-). So let's wait for Sergey? |
General comment but I see a lot of you here so it's in good hands: we should be extremely careful given we are changing a behavior related to security. Better check things three times to make sure we are all good. |
That's the reason why we wait for Sergey's opinion as well. |
Failing Jobs - Building e2e94f1
Full information is available in the Build summary check run. Failures⚙️ Gradle Tests - JDK 11 #- Failing: integration-tests/gradle
📦 integration-tests/gradle✖
|
ping @sberyozkin |
Hi All, apologies for keeping you waiting, was back on Mon but missed this one. So it is back to the original solution, which is fine, it is the easiest to understand. |
fix: #26536
EagerSecurityHandler
performs standard security checks for endpoints annotated with an RBAC annotation and the same checks are later done bySecurityHandler
. We still need interceptors to run for CDI beans and gRPC. This PR prevents repeating of security checks by propagating the information that check is done toSecurityHandler
via invocation context.