Java Reference
In-Depth Information
accessible only if certain strict security criteria are met. To meet this concern, a @Secured
interceptor binding may be created. But when discussing this new binding, someone points
out that part of being secure is also auditing this business logic. So it's decided that auditing
may happen to business logic that's not secure, but secure business logic is required also to
be audited without fail. This is a perfect use case for interceptor binding. Let's take a look
at what the @Secured interceptor binding will look like:
When defining the @Secured interceptor, use @InterceptorBinding to make it
an interceptor binding. Then use @Audited as well to add an additional interceptor
binding to @Secured . This means that the interceptors linked to @Secured and the
interceptors linked to @Audited will both be applied when the @Secured interceptor
binding is used on an EJB class or method. For example, consider the following Secur-
ityCheckInterceptor :
@Secured @Interceptor
public class SecurityCheckInterceptor {
@AroundInvoke
public Object checkSecurity(InvocationContext context)
throws Exception {
// Check security here, proceed if OK
return context.proceed();
}
}
Now apply this interceptor binding to the removeBid() method of the BidService
bean—a method that should never be executed without very specific security, and should
also be audited if needed for verification purposes later:
@Stateless
public class BidService {
...
@Secured
public void removeBid(Bid bid) {
bidDao.removeBid(bid);
Search WWH ::




Custom Search