Accessing an Enterprise Bean Caller’s Security Context

In general, security management should be enforced by the container in a manner that is transparent to the enterprise bean’s business methods. The security API described in this section should be used only in the less frequent situations in which the enterprise bean business methods need to access the security context information, such as when you want to restrict access to a particular time of day.

The javax.ejb.EJBContext interface provides two methods that allow the bean provider to access security information about the enterprise bean’s caller:

• getCallerPrincipal, which allows the enterprise bean methods to obtain the current caller principal’s name. The methods might, for example, use the name as a key to information in a database.

  The following code sample illustrates the use of the getCallerPrincipal method:

  @Stateless public class EmployeeServiceBean implements EmployeeService {
      @Resource SessionContext ctx;
      @PersistenceContext EntityManager em;
  
      public void changePhoneNumber(...) {
          ...
          // obtain the caller principal.
          callerPrincipal = ctx.getCallerPrincipal();
  
          // obtain the caller principal's name.
          callerKey = callerPrincipal.getName();
  
          // use callerKey as primary key to find EmployeeRecord
          EmployeeRecord myEmployeeRecord =
              em.find(EmployeeRecord.class, callerKey);
  
          // update phone number
          myEmployeeRecord.setPhoneNumber(...);
  
          ...
      }
  }

  In this example, the enterprise bean obtains the principal name of the current caller and uses it as the primary key to locate an EmployeeRecord entity. This example assumes that application has been deployed such that the current caller principal contains the primary key used for the identification of employees (for example, employee number).

• isCallerInRole, which the enterprise bean code can use to allow the bean provider/application developer to code the security checks that cannot be easily defined using method permissions. Such a check might impose a role-based limit on a request, or it might depend on information stored in the database.

  The enterprise bean code can use the isCallerInRole method to test whether the current caller has been assigned to a given security role. Security roles are defined by the bean provider or the application assembler and are assigned by the deployer to principals or principal groups that exist in the operational environment.

  The following code sample illustrates the use of the isCallerInRole method:

  @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(...);
           }
           ...
       }
       ...
   }

You would use programmatic security in this way to dynamically control access to a method, for example, when you want to deny access except during a particular time of day. An example application that uses the getCallerPrincipal and isCallerInRole methods is described in Example: Securing an Enterprise Bean with Programmatic Security.