JBoss Community Archive (Read Only)

JBoss AS 7.2

Securing EJBs

Overview

The Java EE spec specifies certain annotations (like @RolesAllowed, @PermitAll, @DenyAll) which can be used on EJB implementation classes and/or the business method implementations of the beans. Like with all other configurations, these security related configurations can also be done via the deployment descriptor (ejb-jar.xml). We won't be going into the details of Java EE specific annotations/deployment descriptor configurations in this chapter but instead will be looking at the vendor specific extensions to the security configurations.

Security Domain

The Java EE spec doesn't mandate a specific way to configure security domain for a bean. It leaves it to the vendor implementations to allow such configurations, the way they wish. In JBoss AS7 the use of @org.jboss.ejb3.annotation.SecurityDomain annotation allows the developer to configure the security domain for a bean. Here's an example:

import org.jboss.ejb3.annotation.SecurityDomain;

import javax.ejb.Stateless;

@Stateless

@SecurityDomain("other")

public class MyBean ...

{

....

The use of @SecurityDomain annotation lets the developer to point the container to the name of the security domain which is configured in the EJB3 subsystem in the standalone/domain configuration. The configuration of the security domain in the EJB3 subsystem is out of the scope of this chapter.

An alternate way of configuring a security domain, instead of using annotation, is to use jboss-ejb3.xml deployment descriptor. Here's an example of how the configuration will look like:

<?xml version="1.0" encoding="UTF-8"?>
<jboss:jboss
        xmlns="http://java.sun.com/xml/ns/javaee"
        xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:s="urn:security:1.1"
        version="3.1" impl-version="2.0">

    <assembly-descriptor>
        <s:security>
			<!-- Even wildcard * is supported -->
            <ejb-name>MyBean</ejb-name>
            <!-- Name of the security domain which is configured in the EJB3 subsystem -->
            <s:security-domain>other</s:security-domain>
        </s:security>
    </assembly-descriptor>
</jboss:jboss>

As you can see we use the security-domain element to configure the security domain.

The jboss-ejb3.xml is expected to be placed in the .jar/META-INF folder of a .jar deployment or .war/WEB-INF folder of a .war deployment.

Absence of security domain configuration but presence of other security metadata

Let's consider the following example bean:

@Stateless
public class FooBean {

	@RolesAllowed("bar")
	public void doSomething() {
		..
	}
...
}

As you can see the doSomething method is configured to be accessible for users with role "bar". However, the bean isn't configured for any specific security domain. Prior to JBoss AS 7.2.x version the absence of an explicitly configured security domain on the bean would leave the bean unsecured, which meant that even if the doSomething method was configured with @RolesAllowed("bar") anyone even without the "bar" role could invoke on the bean.

Starting, JBoss AS 7.2.x, the presence of any security metadata (like @RolesAllowed, @PermitAll, @DenyAll, @RunAs, @RunAsPrincipal) on the bean or any business method of the bean, makes the bean secure, even in the absence of an explicitly configured security domain. In such cases, the security domain name is default to "other". Users can explicitly configure an security domain for the bean if they want to using either the annotation or deployment descriptor approach explained earlier.

Access to methods without explicit security metadata, on a secured bean

Consider this example bean:

@Stateless
public class FooBean {

	@RolesAllowed("bar")
	public void doSomething() {
		..
	}


	public void helloWorld() {
		...
    }
}	

As you can see the doSomething method is marked for access for only users with role "bar". That enables security on the bean (with security domain defaulted to "other"). However, notice that the method helloWorld doesn't have any specific security configurations.

Starting, JBoss AS 7.2.x version, such methods which have no explicit security configurations, in a secured bean, will be treated similar to a method with @DenyAll configuration. What that means is, no one is allowed access to the helloWorld method. This behaviour can be controlled via the jboss-ejb3.xml deployment descriptor at a per bean level or a per deployment level as follows:

<?xml version="1.0" encoding="UTF-8"?>
<jboss:jboss
        xmlns="http://java.sun.com/xml/ns/javaee"
        xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:s="urn:security:1.1"
        version="3.1" impl-version="2.0">

    <assembly-descriptor>
        <s:security>
			<!-- Even wildcard * is supported where * is equivalent to all EJBs in the deployment -->
            <ejb-name>FooBean</ejb-name>
            <s:missing-method-permissions-deny-access>false</s:missing-method-permissions-deny-access>
        </s:security>
    </assembly-descriptor>
</jboss:jboss>

Notice the use of <missing-method-permissions-deny-access> element. The value for this element can either be true or false. If this element isn't configured then it is equivalent to a value of true i.e. no one is allowed access to methods, which have no explicit security configurations, on secured beans. Setting this to false allows access to such methods for all users i.e. the behaviour will be switched to be similar to @PermitAll.

This behaviour can also be configured at the EJB3 subsystem level so that it applies to all EJB3 deployments on the server, as follows:

<subsystem xmlns="urn:jboss:domain:ejb3:1.4">
...
            <default-missing-method-permissions-deny-access value="true"/>
...
</subsystem>

Again, the default-missing-method-permissions-deny-access element accepts either a true or false value. A value of true makes the behaviour similar to @DenyAll and a value of false makes it behave like @PermitAll

JBoss.org Content Archive (Read Only), exported from JBoss Community Documentation Editor at 2020-03-13 13:27:52 UTC, last content change 2013-02-10 15:00:12 UTC.