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.
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 WildFly 8, 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.|
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 WildFly 8, 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.
In WildFly 8, 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.
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.
In WildFly 8, 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