On Mon, Apr 26, 2010 at 13:47, Viktor Klang <[email protected]> wrote:
> > > On Mon, Apr 26, 2010 at 1:42 PM, Jan Goyvaerts <[email protected]>wrote: > >> >> >> On Mon, Apr 26, 2010 at 13:31, Viktor Klang <[email protected]>wrote: >> >>> >>> >>> On Mon, Apr 26, 2010 at 11:47 AM, Jan Goyvaerts >>> <[email protected]>wrote: >>> >>>> I'm currently rewriting an EJB security course and I'm having an >>>> "enterprisy" question for the EJB connoisseurs out there. :-) >>>> >>>> I've written a basic example showing the problem. What happens is >>>> counterintuitive but maybe it's the way it is meant to work. >>>> >>> >>> You mean the compiler should enforce that methods called from your >>> methods only include other methods permissible to call from within the roles >>> or permissions declared? >>> >> >> No. Obviously the example shows a situation that is a bug. It should pop >> up at runtime of course. :-) >> >> What I'm wondering is why the *call *of the method is not stopped. I'm >> obviously accessing code that I'm not supposed to. >> > > But for that to work the appserver would have to hook into the classloading > and either enforce the semantics, or weave in checks before each call that > has some security annotations. > (To either give errors at load time or give errors at runtime) > > But I might misunderstand you. > 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 ? > > >> >> >>> >>>> >>>> MY QUESTION: Is this the way it is meant to work ? If so, can somebody >>>> direct me to a resource/article/... explaining this ? >>>> >>>> MANY thanks !!! >>>> >>>> Jan >>>> >>>> ============================================== >>>> >>>> *Consider the session bean* >>>> >>>> @Session >>>> @DenyAll >>>> @DeclareRoles({"god","mortal"}) >>>> class Knowledge { >>>> >>>> @PermitAll >>>> public String commonKnowledge() { >>>> String response = "Belgian chocolate is best ! "; >>>> response += secretKnowledge(); *<<< call to this method is NOT >>>> blocked for a "mortal" user !!* >>>> return response; >>>> } >>>> >>>> @RolesAllowed({"admin"}) >>>> public String secretKnowledge() { >>>> return "The meaning of everything is 42"; >>>> } >>>> >>>> } >>>> >>>> When calling both methods with a "mortal" user, only the call to the >>>> second method is blocked. The call to the first completes without error. >>>> Although one would expect it to block too as it is accessing a method >>>> requiring the "god" role. At first sight, only the very first method call >>>> is >>>> guarded. It's on GlassFish 3.1 btw... >>>> >>>> >>>> >>>> >>>> -- >>>> 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]<javaposse%[email protected]> >>> . >>> For more options, visit this group at >>> http://groups.google.com/group/javaposse?hl=en. >>> >> >> -- >> 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]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > -- 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.
