Transactions and security - EJB 3 in Action - page 253

reapplying the annotation at the method level. For example, the BidManagerBean could
be restricted to only administrators and specific methods opened up for nonadministrators
such as getBids . But using a mixture of security roles on a class can quickly become
convoluted. It's perhaps better to use a separate bean.
@PermitAll and @DenyAll annotations
The @PermitAll and @DenyAll annotations are self-explanatory—either everyone has
access or no one does. The @PermitAll annotation is used in listing 6.7 to instruct
the container that any user can retrieve the current bids for a given item. You should use
this annotation sparingly, especially at the class level, because it's possible to inadvertently
leave security holes if it's used carelessly.
The @DenyAll annotation renders either a class or method completely inaccessible by any
role. This annotation isn't terribly useful because blocking all access to a method makes
the method unusable. But using the equivalent @DenyAll XML configuration would en-
able you to disable methods for all roles without altering a line of code. This is useful after
you've deployed the application and want to disable functionality.
@RunAs
The @RunAs annotation is similar to the sudo command on Unix systems. On a Unix sys-
tem you'd use sudo to execute a command as another user; very often that other user is
an administrator. This enables tasks to be executed with a different set of privileges. These
other sets of privileges may be more or less restrictive. For example, the cancelBid
method in listing 6.7 might need to invoke a statistics-tracking EJB that manages histor-
ical records and removes a record that had been created. In this hypothetical situation, the
statistics-tracking EJB requires an ADMIN role. By using the @RunAs annotation, you can
temporarily assign a CSR an ADMIN role so that the statistics-tracking EJB thinks an ad-
ministrator is invoking the method:
@RunAs("ADMIN")
@RolesAllowed({"CSR"})
public void cancelBid(Bid bid, Item item) {...}
This annotation should be used sparingly. Like the @PermitAll annotation, it can open
up unforeseen security holes in the software. Now that you understand declarative security,
let's investigate programmatic security.