Programming Tutorials

Container-Managed or Declarative Security

The security management that defines method permissions is usually declared in the enterprise bean's deployment descriptor. Container-managed security makes an enterprise bean more flexible, since it isn't tied to the security roles defined by a particular application.

A security role is a name given to a grouping of information resource access permissions that are defined for an application. Associating a principal with this security role grants the associated access permissions to that principal as long as the principal is "in" the role.

Here is an excerpt from a deployment descriptor (ejb-jar.xml) for an entity bean that is using container-managed security:

<assembly-descriptor>
...
  <security-role>
    <role-name>adm_role</role-name>
  </security-role>
  <method-permission>
    <description>only remote access</description>
    <role-name>adm_role</role-name>
    <method>
      <ejb-name>EntityBMP</ejb-name>
      <method-intf>Remote</method-intf>
      <method-name>withdraw</method-name>
    </method>
  </method-permission>
...
</assembly-descriptor>

The <method-permission> element identifies the only security role that is allowed to invoke the withdraw method on the remote interface. The <method- permission> element consists of an optional description, a list of security role names, and a list of method elements. The <security-role> element contains the definition of a security role used by the bean. The security roles used in the <method-permission> element must be defined in the <security-role> elements of the deployment descriptor, and the methods must be defined in the enterprise bean's interfaces.

You should also note that errors in bean code programming are less likely to be a factor in causing security holes when using container-managed security, because the container implements the security mechanism. These features make container-managed method access the preferred security method.

Bean-Managed or Procedural Security

However, programmatic (procedural) access control is sometimes necessary to satisfy fine-grained or application-specific conditions. Enterprise beans can programmatically manage their own security by using the isCallerInRole() and getCallerPrincipal() methods contained on the EJB's context object. The isCallerInRole() method tests whether the caller has a given security role, returning true if the caller has and false if not. The getCallerPrincipal() method returns the java.security.Principal that identifies the caller.

Here is an excerpt of code from a EJB that uses these methods in a bean-managed security situation:

...
  public void deposit(double amt) {
    if (amt >= 10000) {
      if (entityContext.isCallerInRole("admin")) {
        this.balance += amt;
      } else {
        log("REJECTED deposit(" + amt + ") by user "
          +entityContext.getCallerPrincipal().getName());
        throw new EJBException(
          "You do not have permission to deposit $10,000 or more");
      }
    } else {
      this.balance += amt;
    }
    log("deposit(" + amt + ") by user "
      +entityContext.getCallerPrincipal().getName()
      +" balance="+this.balance);
  }
...

The deposit() method above uses the isCallerInRole() method to determine whether the caller depositing more than $10,000 is in the "admin" role. If the caller is in this role, the operation is accepted and the balance is updated. If the caller is not in the "admin" role, the operation is rejected and an exception is thrown.

The enterprise bean developer is responsible for defining all the security role names that are used in the bean code. Each of these role names must be added to the deployment descriptor in the form of a <security-role-ref> element. Part of this element is the <role-link> element that associates the role name to a security role defined elsewhere in the descriptor file.

Security roles are defined with the element <role-name>. The following deployment descriptor fragment defines a role name admin, which is associated via a <role-link> element to role adm_role.

....
<enterprise-beans>
    ...
    <entity>
        <ejb-name>EntityBMP</ejb-name>
        <ejb-class>EntityBMPBean.class</ejb-class>
        ...
        <security-role-ref>
            <role-name>admin</role-name>
            <role-link>adm_role</role-link>
        </security-role-ref>
        ...
    </entity>
</enterprise-beans>
   .....

In this EJB deployment descriptor, the EntityBMPBean class uses the symbolic name admin to check permissions. In the assembly descriptor section of the deployment descriptor, the security role adm_role is defined as follows:

....
<assembly-descriptor>
    <security-role>
        <role-name>adm_role</role-name>
    </security-role>
</assembly-descriptor>
....

For completeness, here is an excerpt from the WebLogic deployment descriptor <weblogic-ejb-jar.xml> file that resolves the role to an actual principal:

<weblogic-ejb-jar>
....
   <security-role-assignment>
     <role-name>adm_role</role-name>
     <principal-name>system</principal-name>
   </security-role-assignment>
....
</weblogic-ejb-jar>

This use of the deployment descriptor to define a role name and associating it with a role link allows different enterprise beans to use different internal names to refer to the same cluster of permissions. For example, another bean can still refer to the adm_role internally using the string adm instead of admin. A <security- role-ref> is able to associate that bean's adm reference to the security role adm_role.

You should also note that a user or principal is allowed to belong to multiple roles simultaneously. In doing so, the user/principal will benefit from the union set of permissions that those roles grant.

Security Not Covered by the EJB Specification

As opposed to access control, authentication and communication security are not specified in the EJB security guidelines. These aspects of security are left to the proprietary application server or the container.