The EJB Cookbook is a resource for the practicing EJB developer. It is a systematic collection of EJB 'recipes'. Each recipe describes a practical problem and its background; it then shows the code that
solves it, and ends with a detailed discussion.

This unique book is written for developers who want quick, clean, solutions to frequent problems--or simply EJB development ideas. Easy to find recipes range from the common to the advanced. How do you secure a message-driven bean? How do you generate EJB code? How can you improve your entity bean persistence layer?

What's inside:

• EJB 2.1 features
• CMP and BMP bean problems
• EJB web service endpoints
• Transactions and security
• Solving EJB client problems
• Testing EJB applications
• Exception handling best practices
• Messaging solutions
• EJB code generation and logging
  

This manuscript is not yet finished. Your comments will be appreciated by the authors and the publisher.

7.4 Disabling methods for certain users

Problem:

You want to prevent certain clients from invoking certain EJB methods.

Background:

You want to allow an EJB client to find and use a particular EJB, but you want to expose only a limited set of methods to that client. You want to hide a set of business methods, and possibly even particular home interface methods. EJBs use method permissions to further guarantee that the correct users are accessing methods.

Recipe:

Create security roles for your EJBs (see recipe 7.2 for creating security roles). Use the <method-permission> tag to set up method permissions for those roles. Assume an EmployeeBean contains getters and setters for the attributes firstName and lastName. The EmployeeBean has declared two roles, ADMIN and READ ONLY, in its deployment descriptor. The following grants access to those with the ADMIN role to all methods within an EJB:

<ejb-jar>

  <enterprise-beans>
    <!-- Bean data here -->
  </enterprise-beans>

  <assembly-descriptor >
    <method-permission>
      <role-name>
        ADMIN
      </role-name>
    <method>
      <ejb-name>EmployeeBean</ejb-name>
      <method-name>*</method-name>
    </method>
    </method-permission>
  </assembly-descriptor>

</ejb-jar>

To map the READ ONLY role to the correct method permissions (only allowing use of the getter methods), use the following:

<method-permission>
   <role-name>
     READ ONLY
   </role-name>
   <method>
     <ejb-name>EmployeeBean</ejb-name>
     <method-name>getFirstName</method-name>
   </method>
   <method>
     <ejb-name>EmployeeBean</ejb-name>
     <method-name>getLastName</method-name>
   </method>
</method-permission>

To disable all security checks for all clients of an EJB for a particular method, use the <unchecked/> tag:

<method-permission>
   <unchecked/>
   <method>
     <ejb-name>EmployeeBean</ejb-name>
     <method-name>*</method-name>
   </method>
</method-permission>

Analysis:

Security roles are useful in and of themselves, but they would hardly be worth the trouble if you could use them only for the isCallerInRole() method from the EJBContext class. The EJB deployment descriptor also allows you to map security roles to actual EJB methods. The <method-permission> tag builds a many-to-many relationship between roles and methods, where a role is given access permission to certain methods.

The <method-permission> tag contains an optional <description> element, at least one <role-name> element, and at least one <method> element. To grant a role permission to use a method, you name the role in the <role-name> element, and name the method in the <method> element (using its <ejb-name> and <method-name> elements). The recipe demonstrates this in two ways. It names specific methods for the READ ONLY role, allowing only access to getter methods. It also uses an * as a wildcard, indicating that the role ADMIN can access all methods within the EmployeeBean EJB. The only acceptable use of the wildcard is by itself. You cannot use something like get* for a method name; only a single * will work.

Finally, the recipe provides an example of the <unchecked/> method permission. If a method permission is declared unchecked, the method can be invoked by any client of any role. In other words, no security checks will occur when a client invokes the specified method. An unchecked method permission overrides all other permissions that might be specified for that method.

All methods from the EJB's remote, home, and super interfaces can be set up with permissions. Any method that is excluded from the method permissions list cannot be accessed by any role. In addition, the <method> element allows you to describe methods in more detail. This is important if your bean contains overloaded methods. Within the method element, you can use the <method-param> tag to specify parameter types, or use the <method-intf> tag to specify which interface (possible values are Home, Remote, LocalHome, or Local) in which the method is declared.

Related:

• 2.10 Generating and maintaining method permissions
• 7.2 Assigning and determining client security roles

Ben Sullins is a senior Java developer with extensive experience working with EJB. Mark Whipple has fifteen years' experience and a strong background in networked applications. He has been a member of several standards bodies, including the IETF. Ben and Mark are coauthors of Manning's JMX in Action. They both live in Dallas, Texas