Securing Web Applications In JBoss

Okay! Now, we have learnt some commonly used login modules. These login modules can be used by any Java EE application, so it’s time to show a concrete example. In this first section, we will show how to apply a login module into a web application in order to provide a basic web authentication.

Turning on web authentication requires, at first, defining the security-constraints into the web application configuration file (web.xml):The previous configuration will add a security constraint on any JSP/Servlet of the web application that will restrict access to users authenticated with the role Manager.

Next configuration tweak needs to be performed on JBoss web deployment’s descriptor: WEB-INF/jboss-web.xml. There you need to declare the security domain, which will be used to authenticate the users.

Pay attention to the security-domain element. It is necessary to prefix the domain name with java:/jaas/ and the name itself must be exactly the same as the one you typed into the security domain's name attribute. The following diagram resumes the whole configuration sequence applied to a Database login module:

Once you have deployed your application, the outcome of this action should be a blocking popup, requesting user authentication.

Logging in with “admin/admin” will grant access to the application with the Manager role.

Securing EJBs

Securing applications by means of a web login form is the most frequent option in Enterprise applications. Nevertheless, the HTTP protocol is not the only choice available to access applications. For example, EJBs can be accessed by remote clients using RMI-IIOP protocol. In such a case, you should further refine your security policies by restricting access to the EJB components, which are usually involved in the business layer of your applications.

How does security happen at EJB level?

Authentication must be performed before any EJB method is called. Authorization, on the other hand, occurs at the beginning of each EJB method call.

One vast area of improvement introduced in Java EE 5 concerns the use of annotations, which can be also used to perform the basic security checks. The available annotations are five:

@org.jboss.ejb3.annotation.SecurityDomain: It specifies the Security Domain, which is associated with a specific class.
@javax.annotation.security.RolesAllowed: It specifies the list of roles permitted to access method(s) in an EJB.

@javax.annotation.security.RunAs: It assigns a role dynamically to the EJB during the invocation of the method. It can be used, for example, if we need to allow a temporarily permission to access certain methods.

@javax.annotation.security.PermitAll: When specified, this annotation allows all roles to access a particular bean method. The purpose of this annotation is to widen security access to some methods in situation where you don’t exactly know what role will access the EJB. (imagine that some modules have been developed by the third party and they access your EJB with some not well identified roles).

@javax.annotation.security.DenyAll: When specified, this annotation denies access to all roles. Same considerations as for @PermitAll. In the following example, we are restricting access to the EJB named SecureEJB only

to the authorized role, Manager:
import org.jboss.ejb3.annotation.SecurityDomain;
import javax.annotation.security.RolesAllowed;
@Stateless
@SecurityDomain(“mysqlLogin”)

Annotations can also be applied at method level; for example, if we needed a special role named SuperUser for inserting a new User, then we would tag the method as follows:

@RolesAllowed( { “SuperUser” })
public void createUser(String country,String name) {
User customer = new User ();
customer.setCountry(country);
customer.setName(name);
em.persist(customer);
}
@RolesAllowed( { “Manager” })
public class SecureEJB {
. . . . . .
}

Securing web services

Web services authorization can be basically carried out in two ways, depending if we are dealing with a POJO-based web Service or EJB-based web services.

Frequently asked Jboss Interview Questions

Security changes to POJO Web Services are identical to those we have introduced for Servlets or JSP, consisting in defining the security-constraints into web.xml and login modules into jboss-web.xml.

If you are using a web client to access your web service that’s all you need to get authenticated. If you are using a standalone client you will need, in turn, to specify the credentials to the JAX-WS Factory as shown in this snippet:

JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
factory.getInInterceptors().add(new LoggingInInterceptor());
factory.getOutInterceptors().add(new LoggingOutInterceptor());
factory.setServiceClass(POJOWebService.class);
factory.setAddress(“https://localhost:8080/pojoService”);
factory.setUsername(“admin”);
factory.setPassword(“admin”);
POJOWebService client = (POJOWebService) factory.create();
client.doSomething();

What about EJB-based Web Services? The configuration is slightly different; because the security domain is not specified into the web descriptors, we have to provide it by means of annotations:

@Stateless
@WebService(targetNamespace = “https://www.packtpub.com/”,
serviceName = “SecureEJBService”)
@WebContext(authMethod = “BASIC”,
secureWSDLAccess = false)
@SecurityDomain(value = “mysqldomain”)
public class SecureEJB {
. . . .
}

As you can see, the @WebContext annotation basically reflects the same configuration options of POJO-based Web Services, with BASIC authentication and unrestricted WSDL access.

The @SecurityDomain annotation should be familiar to you, because we have introduced it to illustrate how to secure an EJB. As you can see, it’s a replacement for the information contained in the jboss-web.xml file, except that the security domain is referenced by mysqldomain directly.

Securing the AS 7 management interfaces

One of the most obvious tasks for the system administrator who cares about security is restricting access to the server management interfaces. Without a security policy, every user can gain access to the application server and modify its properties.

The attribute which is used to switch on security on the management interface is a security-realm which needs to be defined within the security-realms section:
With the default configuration, the properties are stored in the mgmtusers. properties which can be found in the configuration directory of your server.

By default, this management realm expects the entries to be in the following format:

username=HEX( MD5( username ‘:’ realm ‘:’ password))

This means that each user is associated with an hex-encoded hash that consists of the username, the name of the realm, and the password.

To add new users to the property file, you can use a utility script contained in the bin folder of the AS 7.1 installation named add-user.sh (Linux) or add-user.bat (Windows). As you can see from the following screenshot, the add-user shell requires three pieces of information for the new user:

Realm: This is the name of the realm used to secure the management interfaces. If you just press Enter, the user will be added in the default realm named ManagementRealm.

Username: This is the username we are going to add (it needs to be alphanumeric).

Password: This is the password field which needs to be different from the username.

Here, we have just added the user francesco in the default realm, resulting in the following property added to mgmt-users.properties of your standalone and domain configuration:

francesco=5b9b0917f340b6a9842651867b3deb6f You can now connect to a remote AS 7 management interface using this user:

 

 

 

For the sake of completeness, you can also add users using a non-interactive shell, which could be convenient when you need to add a batch of users on your server distribution. This approach works by passing the username, password, and optionally the realm name to the add-user script:

add-user.bat myuser mypassword realm1