By default, all endpoints are public and available to all callers. There are two ways that you can map access checkers for use with an endpoint. Using the @Endpoint annotation security property allows you to specify the access checker to be used for the endpoint. You can also use an XML configuration file to specify the access checker for a URL and HTTP method.

Note: It is best to use the security property of the @Endpoint annotation to define security mappings. Security mappings defined in the @Endpoint annotation can be overridden by configuration in the accessControllers.xml file.

Using Endpoint Annotations

By default, an endpoint is public and available to any caller. However, the @Endpoint annotation has a security property that allows you to specify an access checker for the endpoint. The value of the security property should be the ID of the access checker as defined in the accessControllers.xml file, for example, allow-all, deny-all, https, etc. Additionally, the @Endpoint annotation isPrivate can be set to true to automatically enable a deny-all access checker for the endpoint.

Once you have configured the security property, on startup, the RestResourceRegistry detects any security mappings defined for the endpoint. For example:

@Path("/{productId}")
@GET
@Endpoint(id="productById", security="logged-in")
public RepresentationModel singularGet(@Context HttpServletRequest servletRequest,
    @PathParam("productId") String pProductId){
    // endpoint implementation
}

Note: Security mappings that are defined with the @Endpoint annotation can be overridden by configurations defined in the accessControllers.xml file.

Using XML Annotations

Access control mappings can be created using XML. XML configurations allows you to map an access checker to a URL and a set of HTTP methods. For example

<access-controllers>
  <access-control-mapping id="test-orders-logged-in"
      url="/public/v1/test/orders/{}" accessController="logged-in"
      httpMethods="GET,PUT"/>
  <access-control-mapping id="test-products-deny-all"
      url="/public/v1/test/products" accessController="deny-all"
      httpMethods="PUT"/>
</access-controllers>

This allows the AccessControlService to paste the XML file and create AccessControlItems, which hold details of the access control mappings.

Cross-Site Request Forgery Protection Filters

The CsrfProtectionFilter provides server-side protection against cross-site request forgery attacks. When you register this filter with the Jersey application, the filter looks for X-Requested-By to be set on the header of every request that changes state. Register the filter as a provider in the ApplicationService Nucleus component:

providerInstances+=/atg/dynamo/service/jaxrs/security/CsrfProtectionFilter

If the header is not found, Jersey returns a 400 Bad Request response to the client.


Copyright © 1997, 2017 Oracle and/or its affiliates. All rights reserved. Legal Notices