You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Current rules of MicroProfile-JWT is that when MP-JWT is enabled, all of the application requires a JWT for requests to be successful. It should be possible to allow specific parts (endpoints or paths) of the application to not require a JWT.
While use of javax.annotation.security.PermitAll seems the most obvious, consider this usecase:
In the above fictitious scenario, the user clearly intends that red and blue can be invoked by a user with the artist role and green can be invoked by a user regardless of role. In all cases, the code clearly expects there to be an authenticated user.
When we discuss this feature we need to enable users to define:
No Authentication: What requires no authentication at all and therefore can be invoked without a JWT
No Authorization: What requires authentication (a JWT), but does not require a specific role
The second case is for overriding class-level uses of @RolesAllowed and is the original intent of @permitAll. Whether or not this requires a user to be logged in -- the first case -- is not addressed or covered.
If @RolesAllowed, @permitAll and @Denyall are determined to be strictly for authorization, then new annotations need to be created to denote if authentication is required.
The text was updated successfully, but these errors were encountered:
@dblevins Hi David, I've suggested to clarify that for the purpose of this spec @PermitAll allows for the authentication-only flow. I'll create a PR and CC to you
Current rules of MicroProfile-JWT is that when MP-JWT is enabled, all of the application requires a JWT for requests to be successful. It should be possible to allow specific parts (endpoints or paths) of the application to not require a JWT.
While use of javax.annotation.security.PermitAll seems the most obvious, consider this usecase:
In the above fictitious scenario, the user clearly intends that red and blue can be invoked by a user with the
artist
role and green can be invoked by a user regardless of role. In all cases, the code clearly expects there to be an authenticated user.When we discuss this feature we need to enable users to define:
The second case is for overriding class-level uses of @RolesAllowed and is the original intent of @permitAll. Whether or not this requires a user to be logged in -- the first case -- is not addressed or covered.
If @RolesAllowed, @permitAll and @Denyall are determined to be strictly for authorization, then new annotations need to be created to denote if authentication is required.
The text was updated successfully, but these errors were encountered: