Java Reference
In-Depth Information
6.4.5. EJB programmatic security
Declarative security is powerful but there are situations where you need more control over
security. For example, you might want to alter the behavior of a method based on the user's
role or even the username. In addition, you may want to check whether the user is the mem-
ber of two groups or make sure that a user is in one group but not in another group. With
programmatic security, you can handle such use cases. Before we delve into it, it should be
noted that programmatic security and declarative security aren't mutually exclusive. Unlike
transaction management, a class isn't marked as using either declarative or programmatic
security as was the case with transaction management.
Programmatic security is accessed via the SessionContext . From this you can retrieve
the Principal and/or check whether the caller to a method is executing in a specific
role. The next listing contains the bid-cancelling scenario we discussed in the last section,
except it's reimplemented using programmatic security.
Listing 6.8. Securing bid cancellation using programmatic security
The listing first injects the EJB context . The isCallerInRole method of the
EJBContext is used to see if the underlying authenticated principal has the CSR role
. If it does not, you throw a java.lang.SecurityException notifying the user
about the authorization violation . Otherwise, the bid-cancellation method is allowed to
proceed normally. Next we'll discuss both of the the security management-related methods
provided in the EJB context, namely isCallerInRole and getCallerPrincipal .
isCallerInRole and getCallerPrincipal
Programmatic security is relatively straightforward. It's composed of the two securityre-
lated methods that you access via the javax.ejb.EJBContext interface as follows:
Search WWH ::

Custom Search