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
-----Original Message-----
From: WebDev [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 29, 2000 2:07 AM
To: Orion-Interest
Subject: Re: How does the <env-entry> tags work?
Magnus,
Thanks for your prompt reply. We thought about the method you described but
there are a few things, we are worried about using this approach. First
would be the overhead involved instantiating additional session beans,
assuming stateful beans would fit the best, assigning one stateful session
bean per user session to handle security and calling the required
entity/session bean(s). The big drawback would be that this would require
immense system ressources, database connections might 'run out' (we're using
Interbase 6.0 SS on Linux and experienced a lack of connections at say 15
concurrent users even when using a pooled connection, which might not be an
orion issue but rather related to Interbase), plus assuming the
'inter-beans' calls in the same container require marshalling via rmi
(PLEASE prove me wrong on this one ;) thus an additional performance loss
which we would avoid implementing the security in entity beans.
Being relatively new to J2EE one of the big rumours is to avoid stateful
session beans at all because of performance issues and re-modelling the
controller of the application by means of stateless session
beans/servlets/http-session management. Again, please prove me wrong, but
due to the lack of documentation it is pretty unknown how orion internally
handles such cases (do calls from bean to bean in the same container require
marshalling? How do stateful session beans perform?)
One more thing about the system we are implementing. The point we can't use
security as orion provides it - even with its dynamic user/group management
- is because we have to restrict access to an entity bean's methods
depending on the user requesting it and of the instance of the bean. To
illustrate it, user A may have access to say all methods of bean B if bean B
contains data X, but only may have access to say 2 methods if the very same
bean contains data Y.
TIA,
Markus & Wolf
On Mon, Aug 28, 2000 at 10:28:53PM +0200, Magnus Rydin wrote:
> Hi there, sorry for not understanding that you were talking about the
> descriptors.
> Why dont you logon through a sessionbean that handles all the fine-grained
> security stuff you want it to have?
> Normal procedure would be to have a page acting as a logon form, that will
> then call a session bean with the values you want, say username/password.
> Then lets say that sessionBean returns another sessionbean, that can only
be
> created with a ValidUserObject (given by the first sessionBean if
> authentication was ok).
> Now ,the returned sessionbean could hold all the methods you want to
enable
> for valid users..
>
> I cant get my head arround why you do not want to send in the identifying
> values through a method..
>
> Another way of sending data between the layers would of course be by using
> JMS messaging.. But how would you make a 'session' out of it?
>
> Hopefully, someone else on this list gets a better grip on what it is that
> you want to accomplish, as I fear that this is not totaly clear to me.
>
> WR
>
> > -----Original Message-----
> > From: WebDev [mailto:[EMAIL PROTECTED]]
> > Sent: den 28 augusti 2000 21:55
> > To: Orion-Interest
> > Subject: Re: How does the <env-entry> tags work?
> >
> >
> > Magnus,
> >
> > We are trying to find a way to handle user authorization at
> > the entity-bean level to be able to restrict access to
> > methods at the lowest level.
> > However we dont want to use users/group in the J2EE 'manner'
> > but rather provide our own user-management. Orion got a
> > wonderful interface to dynamically add/remove users and
> > groups but it isn't as fine grained as we'd prefer to have it.
> >
> > Our first problem was to 'transfer' the logged in user-id
> > from the servlet layer to the ejb-layer, thus we tried to
> > send it via the sessioncontext/entitycontext and failed
> > because we can insert values into the properties via
> > <Properties>.put( "myUser", szUser ) and send it using
> > InitialContext( <Properties> ).lookup( ... ) but are unable
> > to retieve them at the bean (resulting in an empty property set).
> >
> > We tried as well to declare the property we want to set in
> > the <env-entry> tag in the deployment descriptor but are
> > unable to alter the value from a servlet/jsp and send the new
> > value back to the ejb always resulting in the value we
> > defined in the deployment descriptor (assuming now its
> > readonly). Is it correct, that you can not put any properties
> > into the sessioncontext in the servlet and retrieve it inside
> > the sessionbean??? Are there any methods or workarounds to
> > send/store session (httpsession) specific information from
> > the servlet to a stateless session bean or entity bean? Or
> > other ways to send the UserId to a stateless
> > sessionbean/entity bean for verification without sending it
> > as method arguments???
> >
> > Maybe we are on a total wrong track. Our first try was to
> > send additional user information to an entity bean but we
> > failed on providing parameters to the ejbRemove/Load/Store
> > methods. Basically our problem is wanting to know who is
> > calling the entity bean and granting/denying access based on
> > the caller.
> >
> > In hope of a reply for this non-trivial-to-formulate-question :)
> > Wolf & Markus
> >
> > On Mon, Aug 28, 2000 at 01:49:19PM +0200, Magnus Rydin wrote:
> > > Hi there.
> > > I guess you are talking about the env-entry Tag from the
> > Taglib tutorial?
> > > The env-entry displays a environment entry.
> > > The environment entry is for the whole environment of your
> > app, so its not
> > > suitable for user specific data.
> > >
> > > If there is something you dont understand about that
> > lesson, please let me
> > > know and I'll try to improve it when I find the time.
> > > WR
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: WebDev [mailto:[EMAIL PROTECTED]]
> > > > Sent: den 28 augusti 2000 13:10
> > > > To: Orion-Interest
> > > > Subject: How does the <env-entry> tags work?
> > > >
> > > >
> > > > Does anyone know how this tag works & what it really does?
> > > >
> > > > Is it possible to define a property with that, so that I can pass
> > > > individual data (e.g. UserId) - and NOT UserGroups (like
> > > > SECURITY_PRINCIPAL)?
> > > >
> > > > What I'd like to do with that is passing data (set in the
> > > > client) to my
> > > > EJBs (Server)!
> > > >
> > > > Could maybe someone post a little example?
> > > >
> > > > Thanks in advance!
> > > > Wolf
> > > >
> > > >
> > > >
> >
