:::: MENU ::::
Browsing posts in: JAX-RS

JAX-RS Implementations

When you are going to start any kind of implementation by using JAX-RS, it’s important to keep in mind that version is the right to integrate with your current needs. Next, you will have a brief description about the main three JAX-RS implementations on the market:

Jersey – It is the open source reference implementation of JAX-RS. Jersey is built, assembled, and installed using Maven. The main project site, https://jersey.java.net/, contains a download button that links to instructions on how to get started with Jersey, its prerequisites, and links to samples. Jersey is also shipped with the application server GlassFish.

Apache CXF – It is a popular open source web services framework. It was originally just a SOAP stack, but they recently added support for JAX-RS. The CXF philosophy is that different web service styles can coexist. You’ll see a lot of this when you use the framework to write your RESTful web services. Apache CXF has a few nice extensions to JAX-RS that I’d like to point out.

JBoss RESTEasy – It is Red Hat’s implementation of JAX-RS and is the project I lead and run at Red Hat. It is licensed under the GNU Lesser General Public License (LGPL) and can be used in any environment that has a servlet container. Many of its features overlap with other JAX-RS implementations, so I’ll highlight only distinguishing features Here.


Authentication & Authorization in JAX-RS

Authorization
While authentication is about establishing and verifying user identity, authorization is about permissions. Is my user allowed to perform the operation it is invoking? None of the standards-based Internet authorization protocols discussed so far deals with authorization. The server and application know the permissions for each user and do not need to share this information over a communication protocol. This is why authorization is the domain of the server and application.

JAX-RS relies on the servlet and Java EE specifications to define how authorization works. Authorization is performed in Java EE by associating one or more roles with a given user and then assigning permissions based on that role. While an example of a user might be “Bill” or “Monica,” roles are used to identify a group of users, for instance, “adminstrator,” “manager,” or “employee.” You do not assign access control on a peruser basis, but rather on a per-role basis.

To enable authentication, you need to modify the WEB-INF/web.xml deployment descriptor of the WAR file your JAX-RS application is deployed in. Authorization is enabled through XML or by applying annotations to your JAX-RS resource classes. To see how all this is put together, let’s do a simple example. We have a customer database
that allows us to create new customers by posting an XML document to the JAX-RS resource located at the URI /customers. We want to secure our customer service so that only administrators are allowed to create new customers.

The <login-config> element defines how we want our HTTP requests to be authenticated for our entire deployment. The <auth-method> subelement can be BASIC, DIGEST, or CLIENT_CERT. These values correspond to Basic, Digest, and Client Certificate authentication, respectively.

The <login-config> element doesn’t turn on authentication. By default, any client can access any URL provided by your web application with no constraints. To enforce authentication, you must specify a URL pattern you want to secure. In our example, we use the <url-pattern> element to specify that we want to secure the /customers URL.

The <http-method> element says that we only want to secure POST requests to this URL. If we leave out the <http-method> element, all HTTP methods are secured. In our example, we only want to secure POST requests, so we must define the <httpmethod> element.

Next, we have to specify which roles are allowed to POST to /customers. In the web.xml file example, we define an <auth-constraint> element within a <securityconstraint>.


Securing JAX-RS

Many RESTful web services will want secure access to data and functionality they provide. This is especially true for services that will be performing updates. They will want to prevent sniffers on the network from reading their messages. They may also want to fine-tune which users are allowed to interact with a specific service and disallow certain actions for specific users. The Web and the umbrella specification for JAX-RS, Java EE, provide a core set of security services and protocols that you can leverage from within your RESTful web services. These include:

Authentication Authentication is about validating the identity of a client that is trying to access your services. It usually involves checking to see if the client has provided an existing user with valid credentials, such as a password.
Authorization – Once a client is authenticated, it will want to interact with your RESTful web service. Authorization is about deciding whether or not a certain user is allowed to access and invoke on a specific URI. For example, you may want to allow write access (PUT/POST/DELETE operations) for one set of users and disallow it for others. Authorization is not part of any Internet protocol and is really the domain of your servlet container and Java EE.
Encryption – When a client is interacting with a RESTful web service, it is possible for hostile individuals to intercept network packets and read requests and responses if your HTTP connection is not secure. Sensitive data should be protected with cryptographic services like SSL. The Web defines the HTTPS protocol to leverage SSL and encryption.