Page 1 of 1

About Question enthuware.oce-ejbd.v6.2.533 :

Posted: Wed Dec 06, 2017 7:10 pm
by dfigueira
Hi,

I'm not clear about the sentence:

"If the security identity has not been established getCallerPrincipal() will return a non-null principal that corresponds to container’s representation of the unauthenticated identity."

But as the specification describes, the getCallerPrincipal() corresponds to the caller principal and not the run-as principal, if any, so the MDB caller will be the container and the caller would be something as "ANONYMOUS" or not-null.

I am not sure If the security identity can, in fact, be established to a MDB call.

Regards,
DF

Re: About Question enthuware.oce-ejbd.v6.2.533 :

Posted: Wed Dec 06, 2017 9:12 pm
by admin
Can you tell me where the specification says what you have quoted, "But as the specification describes, the getCallerPrincipal() corresponds to the caller principal and not the run-as principal, if any, so the MDB caller will be the container and the caller would be something as "ANONYMOUS" or not-null."

The statement given in the explanation is not talking about run-as principal either. It is talking about whatever principal corresponds to "container’s representation of the unauthenticated identity", which could by anonymous also. Depends on the container.

HTH,
Paul.

Re: About Question enthuware.oce-ejbd.v6.2.533 :

Posted: Thu Dec 07, 2017 7:00 am
by dfigueira
Section 17.2.5.1 from the spec.

"Note that getCallerPrincipal returns the principal that represents the caller of the enterprise bean, not the principal that corresponds to the run-as security identity for the bean, if any."

Anyway, regarding your answer, there is no security identity to be established for a MDB because they are called from the container is it true?

Regards,
DF

Re: About Question enthuware.oce-ejbd.v6.2.533 :

Posted: Thu Dec 07, 2017 7:57 am
by admin
No, as per Section 5.4.13:
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.
The Bean Provider can use the @RunAs metadata annotation (or corresponding deployment descriptor element) to define a run-as identity for the enterprise bean. The run-as identity applies to the bean’s message listener methods and timeout methods.
Thus, the getCallerPrincipal will not return null but whatever it returns depends on how the container implements this feature.

Hope this is clear.

Re: About Question enthuware.oce-ejbd.v6.2.533 :

Posted: Thu Dec 07, 2017 11:14 am
by dfigueira
It is clear what you transcript from the spec but it is not in accordance with your justification in the question:
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.
It is possible for some JMS provider implementation but is not governed by this specification and is not even a requirement.
The Bean Provider can use the @RunAs metadata annotation (or corresponding deployment descriptor element) to define a run-as identity for the enterprise bean. The run-as identity applies to the bean’s message listener methods and timeout methods.
The Bean Provider can set roles for the MDB methods to call other methods.

Re: About Question enthuware.oce-ejbd.v6.2.533 :

Posted: Fri Dec 08, 2017 11:10 pm
by admin
I am not sure where is "RunAs" getting into picture here. The sentence that you quoted in your first post, "If the security identity has not been established getCallerPrincipal() will return a non-null principal that corresponds to container’s representation of the unauthenticated identity.", is correct. This sentence is not talking about RunAs. It is talking about "container’s representation of the unauthenticated identity". So I am not sure why you think it is incorrect or not clear.

HTH,
Paul.