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
> > > >
> > > >
> > > >
> >
