On Mon, Apr 26, 2010 at 1:56 PM, Jan Goyvaerts <[email protected]>wrote:
> > > 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. :-) > /*DISCLAIMER, I AM NOT AN EJB EXPERT*/ It's EJB, do you expect it to work in an intuitive way? ;-) > > 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. > My guess: Because it doesn't have any compiler plugin, it doesn't do load-time verification and it doesn't do instrumentation. > > 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 the general idea is to use the Java Security Manager for that. But from what I've heard, the Java Security Manager is craptastic. > > >> >> >>> >>> >>>> >>>>> >>>>> 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]<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.
