-
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
WebSockets Next: Support for secure upgrade with security annotations only #40957
Merged
sberyozkin
merged 1 commit into
quarkusio:main
from
michalvavrik:feature/websockets-next-eager-sec-checks
Jun 11, 2024
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
21 changes: 21 additions & 0 deletions
21
...ent/src/main/java/io/quarkus/security/deployment/RegisterClassSecurityCheckBuildItem.java
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,21 @@ | ||
package io.quarkus.security.deployment; | ||
|
||
import org.jboss.jandex.AnnotationInstance; | ||
import org.jboss.jandex.DotName; | ||
|
||
import io.quarkus.builder.item.MultiBuildItem; | ||
|
||
/** | ||
* Registers security check against {@link io.quarkus.security.spi.ClassSecurityCheckStorageBuildItem} | ||
* for security annotation instances passed in this build item. | ||
*/ | ||
final class RegisterClassSecurityCheckBuildItem extends MultiBuildItem { | ||
|
||
final DotName className; | ||
final AnnotationInstance securityAnnotationInstance; | ||
|
||
RegisterClassSecurityCheckBuildItem(DotName className, AnnotationInstance securityAnnotationInstance) { | ||
this.className = className; | ||
this.securityAnnotationInstance = securityAnnotationInstance; | ||
} | ||
} |
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 So, in the example above,
open()
is secured andecho
is not ? It would be unexpected IMHO.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.
In the example above "open" and "echo" are not secured, but HTTP upgrade is secured. The HTTP upgrade happens before "open" and "echo", therefore they are only not secured if you inject "Endpoint" class as a bean into another CDI bean and call these methods directly.
That is:
if we were to secure
echo
, it would mean for every single message is performed authorization despite known result (you know it will pass because the HTTP upgrade is secured).I can point you to tests that asserts security is not relaxed where not documented.
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 Michal, these are low level technical details that HTTP upgrade happens before
onOpen
, to me, ononOpen
actually represents a successful HTTP upgrade completion, even if it is not quite a correct picture.Let me clarify how it aligns with #40534.
So there we have an HTTP security policy securing an upgrade:
and then we have
so
@RolesAllowed
must be placed on theecho
method to ensure the current security identity is present and matches the sec constraint beforeecho
is called.Let's say, with your PR, I only want that
echo
is accessed by the non-anonymous security identity.Are you saying we must do:
to have
echo
secured ?Also, does
works for a secure HTTP upgrade ? And if yes, should users also duplicate @RolesAllowed("admin") on the
echo
method for theecho
be secured ?I guess, all I'm asking, why can't we have a single
@Authenticated
at the class level, and not require users duplicate across various methods like onOpen, onEcho, etc, if all users want is, for ex, an authenticated access ?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.
Nope,
@Authenticated
declared on an endpoint means that no callback can be called for non-anonymous security identity. In other words, we secure the HTTP upgrade and if the check fails then no method declared on the endpoint is invoked.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.
It's the same principle, i.e. no need to duplicate the annotation.
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.
Can you suggest a message @sberyozkin ? It's optional, but I'd appreciate it. Otherwise I'll try to rewrite it, but I don't know if it will fit your suggestion.
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
May be this is the source of the confusion on my behalf and simply dropping this message will help ? See, I'm not thinking as a user in terms of CDI beans, when I see an example like
I expect that the callback
echo
andonOpen
methods are secured, I don't want to inject this endpoint anywhere, it is like a JAX-RS resource, we don't inject it somewhere else...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.
Which is why reading
Placing a security annotation on an endpoint bean will not secure bean methods, only the HTTP upgrade.
confuses me a lotThere 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.
Anyway, I don't consider it as a blocker and minor updates to docs can be backported later if agreed to, so @mkouba @gsmet please merge if all looks good to you otherwise
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 think small follow-up docs PR where we can iterate would be better than do it on this PR as CI takes longer and I think we need more than attempt. +1 to merge this