Download Jersey 2.1 User Guide

Security
container, you need to setup the <security-constraint>, <auth-constraint> and user to
roles mappings in order to pass correct information to the SecurityContext.
14.1.1.2. SecurityContext in ContainerRequestContext
The
SecurityContext
can
be
retrieved
also
from
ContainerRequestContext
[http://jax-rs-spec.java.net/nonav/2.0/apidocs/javax/ws/rs/container/ContainerRequestContext.html] via
getSecurityContext() method. You can also set the SecurityContext into the
request using method setSecurityContext(SecurityContext). If you set a new
SecurityContext in the ContainerRequestFilter [http://jax-rs-spec.java.net/nonav/2.0/apidocs/javax/
ws/rs/container/ContainerRequestFilter.html] into the ContainerRequestContext, then this
security context will be used for injections in resource classes (wrapped into the proxy). This way
you can implement a custom authentication filter that may setup your own SecurityContext
to be used. To ensure the early execution of your custom authentication request filter, set the filter
priority to AUTHENTICATION using constants from Priorities [http://jax-rs-spec.java.net/nonav/2.0/
apidocs/javax/ws/rs/Priorities.html]. An early execution of you authentication filter will ensure that all
other filters, resources, resource methods and sub-resource locators will execute with your custom
SecurityContext instance.
14.1.2. Authorization - securing resources
14.1.2.1. Security resources with web.xml
In cases where a Jersey application is deployed in a Servlet container you can rely only on the standard
Java EE Web application security mechanisms offered by the Servlet container and configurable via
application's web.xml descriptor. You need to define the <security-constraint> elements in the
web.xml and assign roles which are able to access these resources. You can also define HTTP methods
that are allowed to be executed. See the following example.
Example 14.3. Injecting SecurityContext into singletons
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<security-constraint>
<web-resource-collection>
<url-pattern>/rest/admin/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>
<security-constraint>
<web-resource-collection>
<url-pattern>/rest/orders/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>customer</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>my-defaul-realm</realm-name>
</login-config>
The example secures two kinds of URI namespaces using the HTTP Basic Authentication. rest/admin/
* will be accessible only for user group "admin" and rest/orders/* will be accessible for "customer"
147