The entity-filtering feature offered by the Jersey framework allows you to conveniently filter out any non-relevant data from the response entity. To use this feature, create custom entity-filtering annotations based on @org.glassfish.jersey.message.filtering.EntityFiltering and apply them on model entity fields that you want to filter out conditionally. Later, while generating a response for the REST API call, runtime will match the entity filtering annotation present on the resource method with the annotation present on the entity fields and include only those matching fields in the response content.

The Jersey framework has extended this filtering feature to use with security annotations. You can filter out entities, or specific entity attributes, from the response body by using security annotations (@PermitAll, @RolesAllowed, and @DenyAll). Jersey offers this support via the org.glassfish.jersey.message.filtering.SecurityEntityFilteringFeature provider. Let's take an example that uses this feature to shape the response content, based on user roles.

The very first step is to add a dependency to the Jersey entity filtering JAR. If you use Maven, the dependency entry in pom.xml may look like the following:

<dependency> 
  <groupId>org.glassfish.jersey.ext</groupId> 
  <artifactId>jersey-entity-filtering</artifactId> 
  <version>${jersey.version}</version> 
</dependency> 

The next step is to register the SecurityEntityFilteringFeature provider in the application. Here is an example:

//Other imports are not shown for brevity 
import org.glassfish.jersey.server.ResourceConfig; 
 
@javax.ws.rs.ApplicationPath("webresources") 
public class ApplicationConfig extends ResourceConfig { 
    public ApplicationConfig() { 
   
      register(org.glassfish.jersey.message.filtering. 
          SecurityEntityFilteringFeature.class);   
      //Rest of the code goes here 
      register("com.packtpub.rest.ch6.security.resources");  
      register(org.glassfish.jersey.server.filter. 
          RolesAllowedDynamicFeature.class); 
  } 
} 

Once you have configured the required things as discussed previously, the next step is to identify the field in the response entity object class definition that needs to be filtered out based on the user role. For instance, in the following example, you want to include the totalEmployees field of the Department entity in the response object only if the requesting user is in the administrator's or manager's role. You can achieve this by annotating the getTotalEmployees() method that returns totalEmployees with the @RolesAllowed({"manager", "admin"}) annotation, as shown in the following lines:

//imports are omitted for brevity 
@XmlRootElement 
public class Department implements Serializable { 
  private Short departmentId; 
  private String departmentName; 
  private Integer totalEmployees; 
  private Integer managerId; 
 
  @RolesAllowed({"manager", "admin"}) 
   public Integer getTotalEmployees() { 
        return totalEmployees; 
   } 
  //All other getters and setters are not shown for brevity 
 
} 

The REST API method returning the discussed Department entity may look like the following:

@GET 
@Path("departments/{id}") 
@RolesAllowed({"users","manager","admin"}) 
@Produces("application/json") 
public Department findDepartment(@PathParam("id") Short id) { 
   Department dept= findDepartmentEntity(id); 
   return dept; 
} 

At runtime, when a request for a department resource reaches the application (for example, /departments/10), the security entity filtering feature will check for user roles, and the totalEmployees attribute will be included in the entity response body only if the user role matches with the values given for the @RolesAllowed annotation that we had set in the getTotalEmployees() method in the Department model class.

For instance, with the previously described settings, when a normal user (not belonging to a manager's or admin's role) accesses the REST resource URI, departments/300, the totalEmployees attribute will not be rendered in the response entity body:

{"departmentId":300,"departmentName":"Administration", 
"managerId":200}