On Mon, Apr 26, 2010 at 2:46 PM, Luís Miranda <[email protected]>wrote:
> 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. :) > I guess you could also use AOP to intercept and surround all calls to protected methods with a isCallerInRole > > 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]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > -- Viktor Klang | "A complex system that works is invariably | found to have evolved from a simple system | that worked." - John Gall Akka - the Actor Kernel: Akkasource.org Twttr: twitter.com/viktorklang -- 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.
