The Importance of Securing Web Services

Secure your RESTful applications against common vulnerabilities with this book and eBook.

(For more resources related to this topic, see here.)

In the upcoming sections of this article we are going to briefly explain several concepts about the importance of securing web services.

The importance of security

The management of securities is one of the main aspects to consider when designing applications.

No matter what, neither the functionality nor the information of organizations can be exposed to all users without any kind of restriction. Suppose the case of a human resource management application that allows you to consult wages of their employees, for example, if the company manager needs to know the salary of one of their employees, it is not something of great importance. But in the same context, imagine that one of the employees wants to know the salary of their colleagues, if access to this information is completely open, it could generate problems among employees with varied salaries.

Security management options

Java provides some options for security management. Right now we will explain some of them and demonstrate how to implement them. All authentication methods are practically based on credentials delivery from the client to the server. In order to perform this, there are several methods:

  • BASIC authentication

  • DIGEST authentication

  • CLIENT CERT authentication

  • Using API keys

The Security Management in applications built with Java including those ones with RESTful web services, always rely on JAAS.

Basic authentication by providing user credentials

Possibly one of the most used techniques in all kind of applications. The user, before gaining functionality over the application is requested to enter a username and password both are validated in order to verify if credentials are correct (belongs to an application user). We are 99 percent sure you have performed this technique at least once, maybe through a customized mechanism, or if you used JEE platform, probably through JAAS. This kind of control is known as basic authentication.

In order to have a working example, let’s start our application server JBoss AS 7, then go to bin directory and execute the file add-user.bat (.sh file for UNIX users). Finally, we will create a new user as follows:

As a result, we will have a new user in JBOSS_HOME/standalone/configuration/application - file.

JBoss is already set with a default security domain called other; the same one uses the information stored in the file we mentioned earlier in order to authenticate. Right now we are going to configure the application to use this security domain, inside the folder WEB-INF from resteasy-examples project, let's create a file named jboss-web.xml with the following content:

<?xml version="1.0" encoding="UTF-8"?> <jboss-web> <security-domain>other</security-domain> </jboss-web>

Alright, let's configure the file web.xml in order to aggregate the securities constraints. In the following block of code, you will see on bold what you should add:

<?xml version="1.0" encoding="UTF-8"?> <web-app version="3.0" xmlns="" xmlns:xsi="" xsi:schemaLocation=""> <!-- Roles --> <security-role> <description>Any rol </description> <role-name>*</role-name> </security-role> <!-- Resource / Role Mapping --> <security-constraint> <display-name>Area secured</display-name> <web-resource-collection> <web-resource-name>protected_resources</web-resource-name> <url-pattern>/services/*</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <description>User with any role</description> <role-name>*</role-name> </auth-constraint> </security-constraint> <login-config> <auth-method>BASIC</auth-method> </login-config> </web-app>

From a terminal let's go to the home folder of the resteasy-examples project and execute mvn jboss-as:redeploy. Now we are going to test our web service as we did earlier by using SoapUI. We are going to perform request using the POST method to the URL

SOAP UI shows us the HTTP 401 error; this means that the request wasn't authorized. This is because we performed the request without delivering the credentials to the server.

Digest access authentication

This authentication method makes use of a hash function to encrypt the password entered by the user before sending it to the server. This makes it obviously much safer than the BASIC authentication method, in which the user’s password travels in plain text that can be easily read by whoever intercepts. To overcome such drawbacks, digest MD5 authentication applies a function on the combination of the values of the username, realm of application security, and password. As a result we obtain an encrypted string that can hardly be interpreted by an intruder.

Now, in order to perform what we explained before, we need to generate a password for our example user. And we have to generate it using the parameters we talked about earlier; username, realm, and password. Let’s go into the directory of JBOSS_HOME/modules/org/picketbox/main/ from a terminal and type the following:

java -cp picketbox-4.0.7.Final.jar org.jboss.
security.auth.callback.RFC2617Digest username
MyRealmName password

We will obtain the following result:

RFC2617 A1 hash: 8355c2bc1aab3025c8522bd53639c168

Through this process we obtain the encrypted password, and use it in our password storage file (the JBOSS_HOME/standalone/configuration/ We must replace the password in the file and it will be used for the user username. We have to replace it because the old password doesn't contain the realm name information of the application.

Next, We have to modify the web.xml file in the tag auth-method and change the value FORM to DIGEST, and we should set the application realm name this way:

<login-config> <auth-method>DIGEST</auth-method> <realm-name>MyRealmName</realm-name> </login-config>

Now, let's create a new security domain in JBoss, so we can manage the authentication mechanism DIGEST. In the file JBOSS_HOME/standalone/configuration/standalone.xml, on the section <security-domains>, let's add the following entry:

<security-domain name="domainDigest" cache-type
="default"> <authentication> <login-module code="UsersRoles" flag="required">
<module-option name="usersProperties" value="${jboss.server.config.dir}
/"/> <module-option
name="rolesProperties" value="${jboss.server.config.dir}/"/> <module-option name="hashAlgorithm"
value="MD5"/> <module-option name=
"hashEncoding" value="RFC2617"/> <module-option name="hashUserPassword" value="false"/> <module-option name="hashStorePassword" value="true"/> <module-option name="passwordIsA1Hash" value="true"/> <module-option name="storeDigestCallback" value=""/> </login-module> </authentication> </security-domain>

Finally, in the application, change the security domain name in the file jboss-web.xml as shown in the following snippet:

<?xml version="1.0" encoding="UTF-8"?> <jboss-web> <security-domain>java:/jaas/domainDigest</security-domain> </jboss-web>

We are going to change the authentication method from BASIC to DIGEST in the web.xml file. Also we enter the name of the security realm; all these changes must be applied in the tag login-config, this way:

<login-config> <auth-method>DIGEST</auth-method> <realm-name>MyRealmName</realm-name </login-config>

Now, restart the application server and then redeploy the application on JBoss. To do this, execute the next command on the terminal:

mvn jboss-as:redeploy

Authentication through certificates

It is a mechanism in which a trust agreement is established between the server and the client through certificates. They must be signed by an agency established to ensure that the certificate presented for authentication is legitimate, it is known as CA.

This security mechanism needs that our application server uses HTTPS as communication protocol. So we must enable HTTPS. Let's add a connector in the standalone.xml file; look for the following line:

<connector name="http"

Add the following block of code:

<connector name="https" protocol="HTTP/1.1" scheme="https"
socket-binding="https" secure="true"> <ssl password="changeit" certificate-key-file="${jboss.server.config.dir}/server.keystore" verify-client="want" ca-certificate-file="${jboss.server.config.dir}/server.truststore"/> </connector>

Next we add the security domain:

<security-domain name="RequireCertificateDomain"> <authentication> <login-module code="CertificateRoles" flag="required"> <module-option name="securityDomain"
value="RequireCertificateDomain"/> <module-option name="verifier" value=""/> <module-option name="usersProperties" value=
"${jboss.server.config.dir}/"/> <module-option name="rolesProperties" value=
"${jboss.server.config.dir}/"/> </login-module> </authentication> <jsse keystore-password="changeit" keystore-url=
"file:${jboss.server.config.dir}/server.keystore" truststore-password="changeit" truststore-url
="file:${jboss.server.config.dir}/server.truststore"/> </security-domain>

As you can see, we need two files: and, both are empty and located in the JBOSS_HOME/standalone/configuration path.

We are going to add the <user-data-constraint> tag in the web.xml in this way:

<security-constraint> ...<user-data-constraint> <transport-guarantee>CONFIDENTIAL</transport-guarantee> </user-data-constraint> </security-constraint>

Then, change the authentication method to CLIENT-CERT:

<login-config> <auth-method>CLIENT-CERT</auth-method> </login-config>

And finally change the security domain in the jboss-web.xml file in the following way:

<?xml version="1.0" encoding="UTF-8"?> <jboss-web> <security-domain>RequireCertificateDomain</security-domain> </jboss-web>

Now, restart the application server, and redeploy the application with Maven:

mvn jboss-as:redeploy

API keys

With the advent of cloud computing, it is not difficult to think of applications that integrate with many others available in the cloud. Right now, it's easy to see how applications interact with Flickr, Facebook, Twitter, Tumblr, and so on through APIKeys usage. This authentication method is used primarily when we need to authenticate from another application but we do not want to access the private user data hosted in another application, on the contrary, if you want to access this information, you must use OAuth.

Today it is very easy to get an API key. Simply log into one of the many cloud providers and obtain credentials, consisting of a KEY and a SECRET, the same that are needed to interact with the authenticating service providers. Keep in mind that when creating an API Key, accept the terms of the supplier, which clearly states what we can and cannot do, protecting against abusive users trying to affect their services.

The following chart shows how this authentication mechanism works:


In this article, we went through some models of authentication. We can apply them to any web service functionality we created.

As you realize, it is important to choose the correct security management, otherwise information is exposed and can easily be intercepted and used by third parties. Therefore, tread carefully.

Resources for Article:

Further resources on this subject:

Books to Consider

comments powered by Disqus