Skip to end of metadata
Go to start of metadata

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:

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:

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:

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:

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:

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:

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

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Jul 28, 2013

    Why not make the default of <missing-method-permissions-deny-access> false? That way it would be exactly like the previous situation where a security domain was specified, only now with the security domain defaulted.

    Another question is if this entire setting up of a separate security domain for EJB beans is even needed in the case of local EJB beans that are called from local web components.

  2. Jul 28, 2013

    p.s. <jboss:jboss> doesn't seem to work for jboss-ejb3.xml. Shouldn't this be <jboss:ejb-jar>? e.g.

  3. Sep 27, 2013

    When does a bean become a secured bean?

    Is having a single security annotated method enough for a bean to be a secured bean?