Is PermitAll misused?

Siva asked on X about the usage of PermitAll in Vaadin: x.com

I never thought about that because I don’t use @PermitAll, but I agree that @PermitAll also allows anonymous users outside of Vaadin.

That means that Vaadin misuses the annotation as in the Vaadin context anonymous users are not allowed.

What are your opinions?

Does it allow anonymous users in JavaEE? The javadoc here PermitAll (Java EE 6 ) is not super clear on that.

The annotation is supposed to mean the same thing and work the same way on views and endpoints as it would work on methods/classes when using EE

That’s an excellent question, and what I read from the Spec Jakarta EE doesn’t know the concept of an anonymous user.

That means Jakarta EE and Spring are not using the concepts equally. From a Vaadin point of view, where the default runtime is Spring Boot, I would assume the same behavior in Vaadin as in Spring Boot.

In other words, @PermitAll should do the same as in the VaadinWebSecurity configuration.

Looking at Security Annotations and Authorization in GlassFish and the Java EE 5 SDK, for @PermitAll it says

Indicates that the given method or all business methods of the given EJB are accessible by everyone.

So probably, it should act exactly as @AnonymousAllowed.

I wonder if the current Vaadin meaning, that is similar to Spring authenticated(), should be achieved with and empty list in @RolesAllowed, but I cannot find any documentation about this case

On EJBs (I know they are dead) it was as follows:

  • No annotation → unauthenticated access allowed (anonymous)
  • PermitAll → all roles allowed

So Spring and Jakarta EE are different.

2 Likes

I must revise my statement from above.

The EJB spec says: Jakarta® Enterprise Beans, Core Features

The PermitAll annotation specifies that all security roles, including any unauthenticated roles, are permitted to execute the specified method(s).

That means anonymous access is allowed.

That said, I would argue that Vaadin is wrong about the usage of PermitAll and the AnonymousAllowed annotation is superfluous.

2 Likes

I also have a vague recollection that we made @PermitAll be consistent with something else that was around at that time.

But now when it’s already used in one way, it would be a very dangerous breaking change to make it more permissive. That would be the case even in a major version since the change wouldn’t lead to any directly noticeable errors and we cannot assume that all developers read the release notes. We would basically have to explicitly disallow the use of @PermitAll for one or two major versions to weed out most usage and then re-introduce support with different semantics only after that.

That’s understandable.

I discussed this with a professor, friend of mine, who teaches Java EE and Spring Boot. We are of the opinion that Spring Security uses PermitAll incorrectly and that the concept of anonymous users is a strange one.

For this reason, I think the way Vaadin implements PermitAll is appropriate!

@PermitAll grants access to all authenticated users, right? So whats wrong with that?

@PermitAll in Spring Security grants access to all authenticated users including the anoymous user which is the user if no user is logged in.

So the semantics of Spring Security and Vaadin is not the same.

Really? I have tested it, i was logged out and visited a view wich has @PermitAll, i was forwarded to Login Form

Yes that’s what Vaadin is doing.

But if you have for example a Spring REST Endpoint that is configured with PermitAll then you’ll have access if you are not logged in.

Ah okay. But yeah makes sense IMHO Vaadin uses it for frontend, when used in backend Spring interprets @PermitAll in another way. Strange but good to know!