This is a problem with the security architecture that I have talked about in
the past.
The problem is that we can not apply declarative authorization (access control)
to bean identities, it can only be applied to beans methods and types (or
deployments). This problem is further aggravated by the fact that in EJB 1.1
the roles declared in the bean code are statically defined (can not very at run
time).
The use of JAAS might solve the problem for now, but would need to be
introduced into the bean code explicitly, which raises the question of whether
it should be an spec supported resource or not. I'm not sure how to solve this
problem but I know for a fact that identity level authorization [authorizing a
Manager (role) access to a specific Branch (entity identity) ] is a pervasive
requirement in real world systems and ignoring it may be convent but is not
certainly not prudent.
In a previous EJB project that I worked on, we had to introduce a third party
authorization system into the architecture to solve this problem. It meant that
the beans had to use a third party API within the bean code itself to access
finer grained authorization rules (based on the identity of the bean being
accessed). Its messy and crude and certainly not in keeping with the spirit of
CTMs (Component Transaction Monitors) which emphasize declarative programming
of services over explicit API usage.
Richard
--
Richard Monson-Haefel
Author of Enterprise JavaBeans
Published by O'Reilly & Associates
( http://www.monson-haefel.com )
Chuck Zheng wrote:
> Hello everyone,
>
> We all know and love method-permission declarative security in
> deployment descriptor. For example: In MortgageApplication's DD,
> we can say only BranchManager Role can execute approveMortgage method.
>
> But if this is a large bank, quite often bank policy forbides manager
> of Branch 1 to approve application lodged at Branch 2, A manager
> can only approve application lodged in his/her branch.
>
> I have seen this type of rules in many large enterprise systems.
> The effect is that most rules cannot be fully enforced with
> method-permission, they need to be further qualified with
> programs. This does not go down well with J2EE/EJB's recommendation.
> I end up writing proprietory framework to manage them. In doing so,
> I found EJBContext.isCallerInRole() is bit too low level.
>
> Since this is such a common occurence, I am sure lots of other people
> have delt with it too. So I wonder any common solution has been
> found particular successful. Any thoughts given to these area in
> future evolution of EJB/J2EE.
>
> cheers
> chuck
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
