Security for MDB

[Deepika Joshi]

I am not able to understand how security works with MDB

MDB is not invoked by client instead it is invoked by container.

    
@MessageDrivenBean
public class myMDB implements MessagListener{
       @Resource
       EJBContext ctx;

       @RolesAllowed("Admin")
       public void onMessage(Message m)
       {    // method is invoked by container not by a user, so how security works here
       }

       or
       public void onMessage(Message m)
       {
                MyObj obj = (MyObj) m.getObject();
                String role = obj.getRole();
                
                if(ctx.isCallerInRole(role))
                {   // here I can imagine role value but not sure abot ctx, is it correct way ?
                }
       }

}

Above code is not from any technical source/book but is my doubt.

Thanks.

[Deepika Joshi]

Can someone help me to understand how secutiry works for MDB?

[Christophe Verré]

isCallerInRole is not allowed to be called from an MDB, so I guess that @RolesAllowed is not allowed to be used either.

[Deepika Joshi]

isCallerInRole is not allowed to be called from an MDB,

true I missed to recollect this.

EJB 3 In Action, page 208

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.


I am not sure how security works for MDB?

[Christophe Verré]

I am not sure how security works for MDB?

MDBs are allowed to call getCallerPrincipal, although I don't know what we could do with that. MDBs are also allowed to use the @RunAs annotation.

[Amol Katyare]

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.

[Christophe Verré]

I think without configuring credentials, by default getCallerPrincipal.getName() retruns "Anonymous".

Can you tell us where you got that information from ?

[Amol Katyare]

from one of the oracle forum

[Christophe Verré]

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").

17.2.5.1 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.

[Hong Anderson]

Amol Katyare wrote:
In a nutshell, security works in MDB not taking into account client's credentials but with JMS provider's credential mappings.

Do you know how to set credential?

[Amol Katyare]

It depends on which application server you are using. You may need to check out documentation for that.