Securing JBoss AS 7

Security is a key element of any Enterprise application. You must be able to control and restrict who is permitted to access your applications and what operations users may perform.

The Java Enterprise Edition (Java EE) specification defines a simple role-based security model for Enterprise Java Beans (EJBs) and web components. The implementation of JBoss security is delivered by PicketBox framework (formerly known as JBoss security), which provides the authentication, authorization, auditing, and mapping capabilities to Java applications.

Because the number of topics that are concerned with security could cover a book by themselves, we had to confine our focus on those that are likely to interest the majority of administrators and developers. More in detail, we will cover the following topics:

• A short introduction to Java security API
• The foundation of JBoss AS 7 security subsystem
• Defining login modules and their integration with the Enterprise components ( for example, web applications EJB)
• How to secure the AS 7 management interfaces
• How to use the Secure Sockets Layer (SSL) to encrypt web applications

Approaching Java security API

Java EE security services provide a robust and easily configured security mechanism for authenticating users and authorizing access to application functions and associated data. To better understand the topics related to security, we should, at first, give some basic definitions:

Authentication is the process by which it’s verified who is currently executing an application, regardless of whether it’s an EJB or a Servlet). Authentication is usually performed by means of a login form contained in a web application or standalone application.

Authorization is the process by which you can verify that users have the rights (permissions) to access system resources. Authorization, therefore, presupposes that authentication has occurred, otherwise it would be impossible to grant any access control if you don’t know who the user is.

In Java EE, the component containers are responsible for providing application security. A container, basically, provides two types of security: declarative and programmatic. Let’s see them all:

Declarative security expresses an application component’s security requirements by means of deployment descriptors and/or annotations. Because deployment descriptor information contained in an external file, it can be changed without the need to modify the source code.

For example, Enterprise JavaBeans components use an EJB deployment descriptor that must be named ejb-jar.xml and placed in the META-INF folder of the EJB JAR file.

Web components use a web application deployment descriptor named web.xml located in the WEB-INF directory.

Programmatic security is embedded in an application and is used to make security decisions. It can be used when declarative security alone is not sufficient to express the security model of an application. The Java EE security API allows the developer test whether or not the current user has access to a specific role, using these calls:

isUserInRole() for Servlets, JSPs (adopted in
javax.servlet.http.HttpServletRequest)
isCallerInRole() for EJBs (adopted in javax.ejb.SessionContext)
In add ition, there are other API calls that provide access to the user’s identity, such
as:
getUserPrincipal() for Servlets, JSPs (adopted in
javax.servlet.http.HttpServletRequest)
getCallerPrincipal() for EJBs (adopted in javax.ejb.SessionContext)

Rather than embedding security into your business component, the JEE security model is declarative: this means that you describe the security roles and permissions in a standard XML descriptor. This isolates security from business-level code because security tends to be more a function of where the component is deployed than an
inherent aspect of the component’s business logic.

The default implementation of the declarative security model is based on Java Authentication and Authorization Service (JAAS) login modules and subjects. The security proxy layer allows custom security that cannot be described using the declarative model to add an EJB in a way that is independent of the EJB business
object.

Frequently asked Jboss Interview Questions

JBoss uses the PicketBox framework, which builds on top of the Java Authentication and Authorization Service, and secures all the Java EE technologies running in the application.

JBoss AS 7 security subsystem

JBoss security is qualified as an extension to the application server and it’s included by default, both in standalone servers and in domain servers:

The following is the default security subsystem contained in the server configuration file:As you can see, the configuration is pretty short as it relies largely on default values, especially for high-level structures such as the security management area.

By defining your own security management options, you could, for example, override the default Authentication/Authorization managers with your implementations. Because it’s likely that you will not require to override these interfaces, we will rather concentrate on the security-domain element, which is a core aspect of JBoss security.

A security domain can be imagined as a Customs Office for foreigners. Before the request crosses JBoss AS borders, the security domain performs all the required authorization and authentication checks, and eventually notifies the caller if he/she can proceed or not.

Security domains are generally configured at server startup or in a running server and subsequently bound to the JNDI tree under the key java:/jaas/. Within the security domain, you can configure login authentication modules so that you can easily change your authentication provider by simply changing its login module. The following table describes all the available login modules, including a short description of them:

Activating a login module is a two-step procedure:

1. First you need to define the login module within your standalone.xml/domain.xml configuration file.
2. Then you need to tell your applications to use a login module to perform authentication and authorization.

Using the UserRoles login module

The UserRoles is one of the simples security domain which can be implemented for testing purposes in your applications. It is based on two files:

• users.properties—containing the list of username and passwords
• roles.properties—containing the mapping between the users and the roles

Here is a sample UserRoles configuration, which stores the security files in the application server configuration directory:All you need to do to get running with your security domain, is adding the two files into the specified path (for the standalone by default JBOSS_HOME/standalone/configuration) with some credentials within it. For example, the users.properties could be:
admin=admin
And the roles.properties:
admin=Manager
This means that authenticating with the admin/admin credentials would assign the role of manager to the user.