On 2010/04/26, at 14:11, Jan Goyvaerts wrote:
Hey Luis,
That will work for sure, but everything that has to be implemented
explicitly is liable to bugs. And this is what you don't want with
security related systems. :-)
It's probably what Viktor says that is best : OAP or some kind of
annotation processor to include a check prior to calling this method.
Well, at least now I know this is "normal" behavior. Thanks a lot
guys !!! :-)
Jan
That's definitely better. If you do go the AOP route, make sure that
whatever AOP you use actually ends up doing compile-time or load-time
weaving. Spring AOP, for example, defaults to a proxy-based
implementation.
On Mon, Apr 26, 2010 at 14:46, 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. :)
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
.
--
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
.
--
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.
