WAS v8.5 > End-to-end paths > Web services - RESTful servicesImplement secure JAX-RS applications
The IBM runtime environment for Java API for RESTful Web Services (JAX-RS) is driven by a servlet derived from the Apache Wink project. Within the WebSphere Application Server environment, the lifecycle of servlets is managed in the web container. Therefore, the security services offered by the web container are applicable to REST resources deployed in WAS.
We can define and add security constraints on the REST resources using the same tooling used to assemble REST applications. These constraints are captured in the J2EE web deployment descriptor associated with the application. The following list describes security definitions that we can include in the deployment descriptor:
- User authentication when invoking REST resources embodied in the application, including
- HTTP basic authentication
- Form login authentication
- Authorization control over REST resources as defined by the URL patterns for the resources
- Use of SSL for transport when invoking REST resources
- Programmatic use of the SecurityContext object to determine user identity and roles
All the security mechanisms supported by the web container are applicable to REST resources, including the use of the Kerberos-based SPNEGO authentication mechanism.
- Configure the development environment.
Before you start developing JAX-RS applications, set up your development environment by adding the JAX-RS libraries on the classpath.
- Set up a development environment for JAX-RS applications
- Development and assembly tools
- Directory conventions
- Define the resources in JAX-RS web applications.
Resources are the basic building block of a RESTful service. Resources can contain static or dynamically updated data. Examples of resources from an online book store application include a book, an order from a store, and a collection of users. By identifying the resources in the application, we can make the service more useful and easier to develop.
- Define the resources in RESTful applications
- Define the URI patterns for resources in RESTful applications
- Define resource methods for RESTful applications
- Define the HTTP headers and response codes for RESTful applications
- Define media types for resources in RESTful applications
- Define parameters for request representations to resources in RESTful applications
- Define exception mappers for resource exceptions and errors
- Configure the JAX-RS application
We can configure JAX-RS applications in multiple ways depending on your needs. To take advantage of the Java EE 6 functionality, we can use the annotation scanning capabilities. By using annotation scanning, we can omit a JAX-RS javax.ws.rs.core.Application subclass or have a minimally defined javax.ws.rs.core.Application subclass. Alternatively, we can specify the IBM JAX-RS servlet or filter to use the functionality available in the IBM JAX-RS servlet and filter.
Using one of the JAX-RS v1.1 configuration methods, we can omit a javax.ws.rs.core.Application subclass in the application or have a javax.ws.rs.core.Application subclass that returns an empty set of classes to inform the JAX-RS runtime environment to find and use all the JAX-RS classes in the application. You might want to use this method when we do not want to have to manually add every relevant JAX-RS class to a javax.ws.rs.core.Application subclass as you develop the application.
By specifying the specific IBM JAX-RS servlet and filter, we can take advantage of and ensure specific IBM JAX-RS behavior. For example, using the IBM JAX-RS filter can be helpful in developing a web application with a mix of JAX-RS resources and JSP files with the same URL patterns.
Even though there is a JAX-RS V1.1 configuration method that supports the use of an optional web.xml file, to specify security constraints or roles, or to take advantage of other features enabled using a web.xml file, specify the information in a web.xml file.
Choose one of the following three methods to configure your JAX-RS application:
- Configure JAX-RS applications using JAX-RS 1.1 methods
- Configure web.xml for JAX-RS servlets
- Configure web.xml for JAX-RS filters
- Secure JAX-RS applications within the web container
Using the security services available to the web container, we can secure REST resources by configuring security mechanisms that define user authentication, transport security, authorization control, and user to role mappings.
- Secure JAX-RS resources using annotations
We can secure JAX-RS resources using annotations that specify security settings. We can use @PermitAll, @DenyAll and @RolesAllowed annotations to override the configuration of security constraints defined in web.xml.
- (optional) Secure downstream JAX-RS resources
We can secure downstream JAX-RS resources by configuring the BasicAuth method for authentication and using the LTPA JAX-RS security handler to take advantage of single sign-on for user authentication.
- (optional) Secure JAX-RS clients using SSL
We can secure the communications between your JAX-RS application and clients that invoke the application using SSL transport layer security.
- Assemble JAX-RS web applications.
After you develop the Java class files for the JAX-RS web application and edit web.xml to enable the JAX-RS servlet, you are ready to assemble the application. Assemble the web application into a WAR package. We can assemble the WAR package into an EAR package, if required.
- Deploy JAX-RS web applications
After we have assembled your JAX-RS web application, you need to deploy your Web archive (WAR) package or the EAR package onto the application server.
- Administer the secure JAX-RS application.
After we have implemented security mechanisms such as basic HTTP authentication or role-based authorization constraints on your REST resources, we can use the dmgr console to administer your JAX-RS applications by mapping defined roles to users, groups, or special subjects.