Enthuware

Hello

It allows programmatic access to the security context in a message driven bean.
There is no direct client for a MDB. So there is no security context.

But I have a getCallerprincipal and isCallerInRole in the MessageDrivenContext
And I can use the @Runsas annotation.

So there is a security context ?

In the MDB there is no client security principal propagation from the client. It runs in the container security context not the client. Bean provider or Application Assembler may use annotations or deployment descriptors to set the security context for the message listener methods. Thus you can use the standard tools to detect security context of the method. MessageDrivenContext extends EJBContext.

The explaination in the answer

In the MDB there is no client security principal propagation from the client. It runs in the container security context not the client. Bean provider or Application Assembler may use annotations or deployment descriptors to set the security context for the message listener methods. Thus you can use the standard tools to detect security context of the method. MessageDrivenContext extends EJBContext

I am not sure about the statement in bold , is it talking about setting the identity using @RunAs annotation ?

This identity, I believe is used to propagate the security context to other components called from Message listener method.

if we use EJBContext methods like isCallerInRole or getCallerPrincipal in message listener method itself, I believe they will still use the security context of container.

There are actually two serious bugs in the explanation:

In the MDB there is no client security principal propagation from the client. It runs in the container security context not the client.

This is not true; according to the EJB 3.1 specification section 5.4.13 Security Context of Message-Driven Mean Methods:

A caller principal may propagate into a message-driven bean’s message listener methods. Whether this occurs is a function of the specific message-listener interface and associated messaging provider, but is not governed by this specification.

Secondly, as stated by rkbansal83, the @RunAs annotation / deployment descriptor is used to propagate the security context to other components called from Message listener method:
See section 17.3.4.1 Run-as:

Establishing a run-as identity for an enterprise bean does not affect the identities of its callers[...]. The run-as identity establishes the identity the enterprise bean will use when it makes calls.

So, it's wrong to say: because bean provider or Application Assembler may use annotations or deployment descriptors to set the security context for the message listener methods, you can use getCallerPrincipal and isCallerInRole in a MDB.

You are right. This has now been fixed.

thank you for your feedback!
-Paul.