Well the way we 'try' to solve it is completely independent of the usual application
server provided security. We perform the login in servlets/jsp, obtain a userId from
the database and store it in the http-session. Whenever an EJB-method is invoked we
pass the User-Id to the session bean, which performs security checks and delegates the
'work' to entity beans according to the privileges of the user.
We tried passing the User-Id to the entity bean itself, which ain't very 'clean' but
should provide a significant increase in performance. But being unable to pass
parameters to methods like ejbRemove we are now investigating how the system performs
using an additional session bean.
On Tue, Aug 29, 2000 at 07:27:34AM -0700, Will Glozer wrote:
> I am currently working on the security design for our application and seem
> to be working on the same issues that you are. I intend to provide a
> complete ACL based security infrastructure at the EJB level. J2EE's
> method level security is far from sufficient for my purposes. For example:
> SessionEJB.createPurchaseOrder(store, ...); access to that method is
> determined by the user's permissions at the _store_ level, not the
> method itself. I would be interested in further discussion outside of the
> bounds of this list, if anyone else is interested.
>
> My current thought is to use the EJBContext.getUserPrincipal() to identify
> the Principal, and then use that information to look up the proper ACLs
> (most likely entity EJBs), and then check the appropriate permissions for
> the Principal. Naturally I don't want to be passing the Principal to every
> method invocation, and the API appears to already provide a nice way. Tying
> my own infrastructure into the J2EE server itself could be a problem
> however,
> especially if other servers don't have the nice API that Orion does.
>
> Regards,
> Will
>
