Head First EJB

What can you do?

Who really is responsible for making the program secure? How does it happen? There’s good news and bad news with EJB security.

1. Security in EJB is easy. It’s about AUTHORIZATION.

   • Most of the time, you don’t put any security-related code into your bean classes.

   • In fact, the Bean Provider does not even think about security, except in very special cases we’ll look at in the last part of this chapter.

   • Security in EJB is about saying WHO can call WHAT. You can restrict access for each individual method in your application, to only those individuals that are in a privileged ‘role’ (Director, Payroll Admin, Payroll Assistant, etc.)

   • The EJB part of the security—the part that specifies the roles, and the methods those roles can access—is done declaratively, in the deployment descriptor, using simple XML tags.

   • At the EJB level, it really is as simple as saying, “The setSalary() method can be accessed by ONLY Directors and Payroll Administrators.”

2. Security in EJB is abstract. It’s NOT about AUTHENTICATION.

   • The EJB spec makes it very easy to define roles, and to assign roles to methods in order to control access to the methods. But the spec says NOTHING about how the system will KNOW which real human beings belong to those roles. Somewhere outside of the EJB deployment descriptor (and outside the specification) you still have to say that Jack O’Bryan is in the Director role (and probably other roles as well). Or say that all Payroll Managers in company XYZ are qualified to be in the ...