Jan,
On 2010/04/26, at 12:56, Jan Goyvaerts wrote:
On Mon, Apr 26, 2010 at 13:47, Viktor Klang <[email protected]>
wrote:
Well... I am kind of expecting it does *something* to enforce its
own security model. :-)
That's why I'm wondering why it doesn't intercept internal method
calls (due to bugs for instance) while it does intercept the
interface calls.
Should I conclude this is the expected, as designed, behavior ? My
question really is just that: While counterintuitive (for me) is
this the way it is meant to work: only the remote method calls are
secured. Not the local/internal/... ones. Right ?
I think this behaviour is mostly a side-effect of how the app servers
generally implement security (by using a proxy/interceptor chain).
Generally a proxy is not able to intercept self-invocation.
I've had a quick glance at the EJB specification and it isn't terribly
specific about what is the expected behaviour in this case. From
section 17.1 of the EJB 3.0 spec:
At runtime, a client will be allowed to invoke a business method
only if the principal associated with the client call has been
assigned by the Deployer to have at least one security role that is
allowed to invoke the business method or if the Bean Provider or
Application Assembler has specified that security authorization is
not to be checked for the method (i.e., that all roles, including
any unauthenticated roles, are permitted). See Section 17.3.2.
The language used ("a client will be allowed...") suggests that the
self-invocation case is not covered within the spec. Since it's not in
the spec, it's bound to be container-dependent as well, which may or
may not be a problem for you.
I would suggest that you add a programmatic security check at the
start of the relevant methods, using the method isCallerInRole(String)
from the interface javax.ejb.EJBContext. It's ugly, but guaranteed to
work. :)
Luís Miranda
--
You received this message because you are subscribed to the Google Groups "The Java
Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
