Skip to content
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

@PermitAll is misleading #10362

Closed
MarcusBiel opened this issue Jun 30, 2020 · 8 comments · Fixed by #18979
Closed

@PermitAll is misleading #10362

MarcusBiel opened this issue Jun 30, 2020 · 8 comments · Fixed by #18979
Assignees
Labels
Milestone

Comments

@MarcusBiel
Copy link

The @permitAll annotation is misleading and has cost me some effort to figure out its meaning -
perimit all implies that this opens up an endpoint for all requests - but what is actually meant is
@PermitAllRoles or @PermitAllExistingRoles or something like that.

@MarcusBiel MarcusBiel added the kind/enhancement New feature or request label Jun 30, 2020
@MarcusBiel
Copy link
Author

@emmanuelbernard
Copy link
Member

So so I guess it's related to #10361 you tried to use @PermitAll for that. Maybe the doc improvement can segway the two points of clarifying Permit all and the section about a unauthenticated subpath

@MarcusBiel
Copy link
Author

Sure

@sberyozkin
Copy link
Member

sberyozkin commented Jul 24, 2020

Hi @MarcusBiel Can you clarify again please what exactly was misleading here ?
Both @PermitAllRoles and @PermitAllExistingRoles interpretations look identical to me :-), this is a standard annotation which has been around forever, I never really use it, but I guess it means: whatever roles, if any, the identity has will be sufficient for the @PermitAll annotated method be invoked, not really sure what Quarkus docs need to clarify

@MarcusBiel
Copy link
Author

@sberyozkin as stated initially, @permitAll to me means that this method is open, permitted to EVERYONE, so like not authenticated. But it actually means permitted to all authenticated roles.

stuartwdouglas added a commit to stuartwdouglas/quarkus that referenced this issue Jul 24, 2021
@stuartwdouglas
Copy link
Member

So the issue here is that JAX-RS comes after the HTTP authentication layer. If you have configured HTTP level authentication then it will be run before the request has actually reached the JAX-RS layer.

We can't 'push up' the JAX-RS level constrains into the HTTP layer, because JAX-RS pre-matching filters can change the endpoint that the request is mapped to, so you can't be sure which endpoint will actually be invoked.

I am adding a quarkus.security.jaxrs.default-roles-allowed property that you can use to do what you are after. If you set quarkus.security.jaxrs.default-roles-allowed=** this will require authentication for every endpoint by default, but will be overridden by annotations if they are present.

stuartwdouglas added a commit to stuartwdouglas/quarkus that referenced this issue Jul 24, 2021
@MarcusBiel
Copy link
Author

@stuartwdouglas quarkus.security.jaxrs.default-roles-allowed - sounds like a great improvement, since my lisr of public paths (quarkus.http.auth.permission.public.paths=) is getting longer and longer. Any idea in which version this will be available?

@stuartwdouglas
Copy link
Member

Should be 2.2

stuartwdouglas added a commit to stuartwdouglas/quarkus that referenced this issue Jul 25, 2021
@quarkus-bot quarkus-bot bot added this to the 2.2 - main milestone Jul 26, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants