Securing an Enterprise Bean Using Declarative Security and Annotations (The Java EE 6 Tutorial, Volume I)

The Java EE 6 Tutorial, Volume I

Securing an Enterprise Bean Using Declarative Security and Annotations

Declarative security enables the application developer to specify which users are authorized to access which methods of the enterprise beans, and to authenticate these users with basic, or username-password, authentication.

Frequently, the person who is developing an enterprise application is not the same person who is responsible for deploying the application. When an application developer uses declarative security to define method permissions and authentications mechanisms, they are passing along to the deployer a security view of the enterprise beans contained in the EJB JAR. When a security view is passed on to the deployer, the deployer uses this information to define method permissions for security roles. If you don’t define a security view, the deployer will have to determine what each business method does to determine which users are authorized to call each method.

A security view consists of a set of security roles, a semantic grouping of permissions that a given type of users of an application must have to successfully access the application. Security roles are meant to be logical roles, representing a type of user. You can define method permissions for each security role. A method permission is a permission to invoke a specified group of methods of the enterprise beans’ business interface, home interface, component interface, and/or web service endpoints. After method permissions are defined, username-password authentication will be used to verify the identity of the user.

It is important to keep in mind that security roles are used to define the logical security view of an application. They should not be confused with the user groups, users, principals, and other concepts that exist in the Enterprise Server. An additional step is required to map the roles defined in the application to users, groups, and principals that are the components of the user database in the file realm of the Enterprise Server. These steps are outlined in Mapping Security Roles to Enterprise Server Groups.

The following sections show how an application developer uses declarative security to either secure an application or to create a security view to pass along to the deployer.

Specifying Authorized Users by Declaring Security Roles

This section discusses how to use annotations to specify the method permissions for the methods of a bean class. If you'd like more information on these annotations, refer to JSR-250 Common Annotations for the Java Platform.

Method permissions can be specified on the class, the business methods of the class, or both. Method permissions can be specified on a method of the bean class to override the method permissions value specified on the entire bean class. The following annotations are used to specify method permissions:

@DeclareRoles

This annotation is used to specify all of the roles that will be used by the application, including roles not specifically named in a RolesAllowed annotation. The set of security roles used by the application is the total of the security roles defined in the @DeclareRoles and @RolesAllowed annotations.

The @DeclareRoles annotation is specified on a bean class, where it serves to declare roles that can be tested (for example, by calling isCallerInRole) from within the methods of the annotated class. When declaring the name of a role used as a parameter to the isCallerInRole(String roleName) method, the declared name must be the same as the parameter value.

Here is some example code that demonstrates the use of the DeclareRoles annotation.
```
@DeclareRoles("BusinessAdmin")
public class Calculator {
	public void convertCurrency() {
		if(x.isUserInRole("BusinessAdmin")) {
			//....
		}
	}
	//...
}
```
The syntax for declaring more than one role is as shown in the following example:
```
@DeclareRoles({"Administrator", "Manager", "Employee"})
```
@RolesAllowed("list-of-roles")

The @RolesAllowed annotation specifies the security roles permitted to access method(s) in an application. This annotation can be specified on a class or on method(s). When specified at the class level, it applies to all methods in the class. When specified on a method, it applies to that method only, and overrides any values specified at the class level.

To specify that no roles are authorized to access method(s) in an application, use the @DenyAll annotation. To specify that a user in any role is authorized to access the application, use the @PermitAll annotation.

When used in conjunction with the @DeclareRoles annotation, the combined set of security roles are used by the application.

Here is some example code that demonstrates the use of the RolesAllowed annotation.
```
@RolesAllowed("AllUsers")
public class Calculator {
	@RolesAllowed("Administrator")
	public void setNewRate(int rate) {
	//..
}
```
@PermitAll

The @PermitAll annotation specifies that all security roles are permitted to execute the specified method(s). The user is not checked against a database to ensure that this user is authorized to access this application.

This annotation can be specified on a class or on method(s). Specifying this annotation on the class means that it applies to all methods of the class. Specifying it at the method level means that it applies to only that method.

Here is some example code that demonstrates the use of the PermitAll annotation.
```
import javax.annotation.security.*;
@RolesAllowed("RestrictedUsers")
public class Calculator {
	@RolesAllowed("Administrator")
	public void setNewRate(int rate) {
		//...
	}
	@PermitAll
	public long convertCurrency(long amount) {
		//...
	}
}
```
@DenyAll

The @DenyAll annotation specifies that no security roles are permitted to execute the specified method(s). This means that these methods are excluded from execution in the Java EE container.

Here is some example code that demonstrates the use of the DenyAll annotation.
```
import javax.annotation.security.*;
@RolesAllowed("Users")
public class Calculator {
	@RolesAllowed("Administrator")
	public void setNewRate(int rate) {
		//...
	}
	@DenyAll
	public long convertCurrency(long amount) {
		//...
	}
}
```

Example 24–1 Declaring Roles using @DeclareRoles

The following code snippet demonstrates the use of the @DeclareRoles annotation with the isCallerInRole method. In this example, the @DeclareRoles annotation declares a role that the enterprise bean PayrollBean uses to make the security check using isCallerInRole("payroll") to verify that the caller is authorized to change salary data.

@DeclareRoles("payroll")
@Stateless public class PayrollBean implements Payroll {
    @Resource SessionContext ctx;

    public void updateEmployeeInfo(EmplInfo info) {

        oldInfo = ... read from database;

        // The salary field can be changed only by callers
        // who have the security role "payroll"
        if (info.salary != oldInfo.salary &&
            !ctx.isCallerInRole("payroll")) {
                throw new SecurityException(...);
        }
        ...
    }
    ...
}

Example 24–2 Declaring Roles using @RolesAllowed

The following example code illustrates the use of the RolesAllowed annotation:

@RolesAllowed("admin")
public class SomeClass {
    public void aMethod () {...}
    public void bMethod () {...}
    ...
}

@Stateless public class MyBean extends SomeClass implements A  {

    @RolesAllowed("HR")
    public void aMethod () {...}

    public void cMethod () {...}
    ...
}

In this example, assuming aMethod, bMethod, and cMethod are methods of business interface A, the method permissions values of methods aMethod and bMethod are @RolesAllowed("HR") and @RolesAllowed("admin") respectively. The method permissions for method cMethod have not been specified.

To clarify, the annotations are not inherited by the subclass per se, they apply to methods of the superclass which are inherited by the subclass.

Mapping Security Roles to Enterprise Server Groups

The Enterprise Server assigns users to principals or groups, rather than to security roles. When you are developing a Java EE application, you don’t need to know what categories of users have been defined for the realm in which the application will be run. In the Java EE platform, the security architecture provides a mechanism for mapping the security roles defined in the application to the users, principals, or groups defined in the runtime realm. The deployer will work with the security view provided by the application developer to implement this mapping.

One way to declare a mapping between a security role used in the application and one or more groups and/or principals defined for the applicable realm of the Enterprise Server is to use the security-role-mapping element in the runtime deployment descriptor (sun-application.xml, sun-web.xml, or sun-ejb-jar.xml.) This is the method to use when the role name defined in the application does not match the group or principal name defined for the Enterprise Server. An example of this role mapping can be found in Part VII, Security, in The Java EE 6 Tutorial, Volume II.

In the tutorial, the role names used in the application are the same as the group names defined on the Enterprise Server. Under these circumstances, you can enable a default principal-to-role mapping on the Enterprise Server using the Admin Console. To enable the default principal-to-role-mapping, follow these steps:

Start the Enterprise Server, then the Admin Console.
Expand the Configuration node.
Select the Security node.
On the Security page, check the Enabled box beside Default Principal to Role Mapping.

Specifying an Authentication Mechanism and Secure Connection

When method permissions are specified, basic, username-password, authentication will be invoked by the Enterprise Server.

If you would like to specify a different type of authentication, or to require a secure connection using SSL, you would specify this information in an application deployment descriptor. Using application deployment descriptors is discussed in Part VII, Security, in The Java EE 6 Tutorial, Volume II.

Example: Securing an Enterprise Bean

This section discusses how to configure an enterprise bean for username-password authentication. When a bean that is constrained in this way is requested, the server requests a user name and password from the client and verifies that the user name and password are valid by comparing them against a database of authorized users on the Enterprise Server.

If the topic of authentication is new to you, please refer to the section titled Specifying an Authentication Mechanism.

This example demonstrates security by starting with the unsecured enterprise bean application, cart, which is found in the directory tut-install/examples/ejb/cart/ and is discussed in The cart Example.

In general, the following steps are necessary to add username-password authentication to an existing application that contains an enterprise bean.

Create an application like the one in The cart Example.
If you have not already done so, complete the steps inSetting Up Your System for Running the Security Examples to configure your system for running the tutorial applications.
Modify the source code for the enterprise bean, CartBean.java, to specify which roles are authorized to access which protected methods. This step is discussed in Annotating the Bean.
Build, package, and deploy the enterprise bean, then build and run the client application by following the steps in Building, Deploying, and Running the Secure Cart Example Using NetBeans IDE or Building, Deploying, and Running the Secure Cart Example Using Ant.

Annotating the Bean

The source code for the original cart application was modified as shown in the following code snippet (modifications in bold, method details are removed to save space). The resulting file can be found in the following location:

tut-install/examples/ejb/cart-secure/cart-secure-ejb/src/java/cart/
ejb/CartBean.java

The code snippet is as follows:

package cart.ejb;

import cart.util.BookException;
import cart.util.IdVerifier;
import java.util.ArrayList;
import java.util.List;
import javax.ejb.Remove;
import javax.ejb.Stateful;
import javax.annotation.security.RolesAllowed;

@Stateful
public class CartBean implements Cart {

    String customerName;
    String customerId;
    List<String> contents;

    public void initialize(String person) throws BookException {
        if (person == null) {
            throw new BookException("Null person not allowed.");
        } else {
            customerName = person;
        }

        customerId = "0";
        contents = new ArrayList<String>();
    }

    public void initialize(String person, String id) throws BookException {
        if (person == null) {
            throw new BookException("Null person not allowed.");
        } else {
            customerName = person;
        }

        IdVerifier idChecker = new IdVerifier();

        if (idChecker.validate(id)) {
            customerId = id;
        } else {
            throw new BookException("Invalid id: " + id);
        }

        contents = new ArrayList<String>();
    }

    @RolesAllowed("TutorialUser")
    public void addBook(String title) {
        contents.add(title);
    }

    @RolesAllowed("TutorialUser")
    public void removeBook(String title) throws BookException {
        boolean result = contents.remove(title);
        if (result == false) {
            throw new BookException("\"" + title + "\" not in cart.");
        }
    }

    @RolesAllowed("TutorialUser")
    public List<String> getContents() {
        return contents;
    }

    @Remove()
    @RolesAllowed("TutorialUser")
    public void remove() {
        contents = null;
    }
}

The @RolesAllowed annotation is specified on methods for which you want to restrict access. In this example, only users in the role of TutorialUser will be allowed to add and remove books from the cart, and to list the contents of the cart. An @RolesAllowed annotation implicitly declares a role that will be referenced in the application; therefore, no @DeclareRoles annotation is required. The presence of the @RolesAllowed annotation also implicitly declares that authentication will be required for a user to access these methods. If no authentication method is specified in the deployment descriptor, the type of authentication will be username-password authentication.

Building, Deploying, and Running the Secure Cart Example Using NetBeans IDE

Follow the instructions for building, deploying, and running the secure cart example by following the instructions in Building, Packaging, Deploying, and Running the cart Example,

Building, Deploying, and Running the Secure Cart Example Using Ant

Follow the instructions for building, deploying, and running the secure cart example by following the instructions in Building, Packaging, Deploying, and Running the cart Example. Enter your user name and password when prompted to do so.