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
When we implemented the specification, we assumed that when an application is annotated with @LoginConfig, the whole application is protected and each request should be authenticated.
When implementing the MP Starter project, it seems that other vendors chose the opposite - e.g. only endpoints that have @RolesAllowed annotation need authentication.
Unfortunately the TCK does not test either approach - we pass the TCK tests as I am sure do other vendors.
I would like to hear a clarification on this approach. My 2 cents why I chose the approach we have implemented:
When an application is annotated, we can assume all endpoints require authentication
Endpoints annotated with RolesAllowed also require authorization
Endpoints annotated with PermitAll escape both authentication and authorization
This way we can configure endpoints in any combination of authentication, authorization or public access.
If we chose the reverse approach, I cannot find out how to implement an endpoint that is authenticated and not authorized (e.g. we allow any logged in user to access the endpoint).
Please add a TCK test that verifies the approach that is intended by this specification.
Thanks!
The text was updated successfully, but these errors were encountered:
I believe the way out of it (given that some implementations start dealing with the token only if the RBAC annotations are used) is to clarify that having @PermitAll is equivalent to the Authentication only mode.
When we implemented the specification, we assumed that when an application is annotated with
@LoginConfig
, the whole application is protected and each request should be authenticated.When implementing the MP Starter project, it seems that other vendors chose the opposite - e.g. only endpoints that have
@RolesAllowed
annotation need authentication.Unfortunately the TCK does not test either approach - we pass the TCK tests as I am sure do other vendors.
I would like to hear a clarification on this approach. My 2 cents why I chose the approach we have implemented:
RolesAllowed
also require authorizationPermitAll
escape both authentication and authorizationThis way we can configure endpoints in any combination of authentication, authorization or public access.
If we chose the reverse approach, I cannot find out how to implement an endpoint that is authenticated and not authorized (e.g. we allow any logged in user to access the endpoint).
Please add a TCK test that verifies the approach that is intended by this specification.
Thanks!
The text was updated successfully, but these errors were encountered: