Uploaded image for project: 'RESTEasy'
  1. RESTEasy
  2. RESTEASY-1850

RoleBasedSecurityFeature -- 401 vs 403

XMLWordPrintable

      I may be completely off-base, but using Resteasy with Undertow (outside of WildFly), I seem to find that using @DenyAll on a class and @RolesAllowed on a method, when there is no authenticated user, the RoleBasedSecurityFilter throws a 403 instead of a 401.

      As there is no auth to check, I think the correct should be a 401 to cause the user to think about authorizing, where 403 is "we know who you are, and you are not allowed".

      I've created my own impl, which looks like this, and reacts the way I expect:

          @Override
          public void filter(ContainerRequestContext requestContext) throws IOException {
              SecurityContext context = ResteasyProviderFactory.getContextData(SecurityContext.class);
              if (denyAll) {
                  if ( context == null || context.getUserPrincipal() == null ) {
                      throw new NotAuthorizedException(Response.status(401).entity("Not authorized").type("text/html;charset=UTF-8").build());
                  }
                  throw new ForbiddenException(Response.status(403).entity("Access forbidden: role not allowed").type("text/html;charset=UTF-8").build());
              }
              if (permitAll) {
                  return;
              }
      
              if (rolesAllowed != null) {
                  if ( context != null && context.getUserPrincipal() != null ) {
                      for (String role : rolesAllowed) {
                          if (context.isUserInRole(role)) return;
                      }
                      throw new ForbiddenException(Response.status(403).entity("Access forbidden: role not allowed").type("text/html;charset=UTF-8").build());
                  }
                  throw new NotAuthorizedException(Response.status(401).entity("Not authorized").type("text/html;charset=UTF-8").build());
              }
              return;
          }
      

      In my case, even without an authorized user, there is a context, hence the checking for the user principal.

            Unassigned Unassigned
            bmcwhirt@redhat.com Bob McWhirter
            Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: