Chapter 43. Securing Jakarta RESTful Web Services and RESTEasy

Because RESTEasy is deployed as a servlet, you must use standard web.xml constraints to enable authentication and authorization.

Unfortunately, web.xml constraints do not mesh very well with Jakarta RESTful Web Services in some situations. The problem is that web.xml URL pattern matching is very very limited. URL patterns in web.xml only support simple wildcards, so Jakarta RESTful Web Services resources like:

/{pathparam1}/foo/bar/{pathparam2}

Cannot be mapped as a web.xml URL pattern like:

/*/foo/bar/*

To get around this problem you will need to use the security annotations defined below on your Jakarta RESTful Web Services methods. You will still need to set up some general security constraint elements in web.xml to turn on authentication.

RESTEasy supports the @RolesAllowed, @PermitAll and @DenyAll annotations on Jakarta RESTful Web Services methods. By default though, RESTEasy does not recognize these annotations. You have to configure RESTEasy to turn on role-based security by setting the appropriate parameter. NOTE!!! Do not turn on this switch if you are using Jakarta Enterprise Beans. The Jakarta Enterprise Beans container will provide this functionality instead of RESTEasy. To configure this switch as a context-param, do this:


<web-app>
...
   <context-param>
      <param-name>resteasy.role.based.security</param-name>
      <param-value>true</param-value>
   </context-param>
</web-app>

See Section 3.4, “Configuration” for more information about application configuration.

There is a bit of quirkiness with this approach. You will have to declare all roles used within the RESTEasy war file that you are using in your Jakarta RESTful Web Services classes and set up a security constraint that permits all of these roles access to every URL handled by the Jakarta RESTful Web Services runtime. You'll just have to trust that RESTEasy Jakarta RESTful Web Services authorizes properly.

How does RESTEasy do authorization? Well, its really simple. It just sees if a method is annotated with @RolesAllowed and then just does HttpServletRequest.isUserInRole. If one of the @RolesAllowed passes, then allow the request, otherwise, a response is sent back with a 401 (Unauthorized) response code.

So, here's an example of a modified RESTEasy WAR file. You'll notice that every role declared is allowed access to every URL controlled by the RESTEasy servlet.


<web-app>

   <context-param>
      <param-name>resteasy.role.based.security</param-name>
      <param-value>true</param-value>
   </context-param>

   <security-constraint>
      <web-resource-collection>
         <web-resource-name>Resteasy</web-resource-name>
         <url-pattern>/security</url-pattern>
      </web-resource-collection>
       <auth-constraint>
         <role-name>admin</role-name>
         <role-name>user</role-name>
      </auth-constraint>
  </security-constraint>

   <login-config>
      <auth-method>BASIC</auth-method>
      <realm-name>Test</realm-name>
   </login-config>

   <security-role>
      <role-name>admin</role-name>
   </security-role>
   <security-role>
      <role-name>user</role-name>
   </security-role>

   ...
</web-app>