Like transaction management, authentication can be either
declarative or programmatic, each of which provides a different level of control
over the authentication process. In addition, like the transaction management
features discussed in this chapter, security applies to session beans and MDBs, and
not the JPA entities.
This is what my understanding is. Please correct if am wrong.
isCallerInRole() - Not allowed in MDB.
Reason is obvious - No client available for security check to be performed.
getCallerInPrincipal() and @RunAs - Allowed.
Reason - No security context passed onto onMessage() but JMS agent/provider can allow user to configure credentials that EJBContainer may pass onto MDB. I think without configuring credentials, by default getCallerPrincipal.getName() retruns "Anonymous". Consider a case if onMessage() is further performing certain task (e.g. calling a service from other domain that require authenticate users only or doing persistence related stuffs) wherein it has to have certain role associate with it. I guess, then we can assign desired role for MDB.
In a nutshell, security works in MDB not taking into account client's credentials but with JMS provider's credential mappings.
I think that it really depends on what the container wants to set it to. There's no guarantee that the Principal's name will be anonymous in this case. (I tried on Glassfish and it returned "ANONYMOUS").
18.104.22.168 Use of getCallerPrincipal The meaning of the current caller, the Java class that implements the java.security.Principal interface, and the realm of the principals returned by the getCallerPrincipal method depend on the operational environment and the configuration of the application.