I should have included more information with my original post. One of the
other things we're wanting to do is come up with a flexible
_authorization_ model. This requires that the body of a method like
deleteUser(int id) of the statefull session bean would need the identity
information to see if the actor (current web user) has permission to
perform the action (deletion) on the object (specific user).
Administrator A may be able to delete users from group 1, but
administrator B might only have permission to delete users from group 2.
We want to prevent admin B from deleting users in group 1. Before you
ask, no, this cannot be solved by AppServer's ability to see if the caller
is within a specific role.
Doing this authorization-per-method-call (which I don't really like, but
I haven't found a way around it yet) requires that the statefull session
bean know who the actor is among other things. If this identity and
authorization information were cached in the web tier it would have to be
transmitted with every method call, which is something I'd like to
prevent.
Nothing is set in stone yet and I'm trying to figure out how to solve
this problem elegantly. Any thoughts on this problem would be greatly
appreciated.
-M@ (off to get more coffee...)
--
Matt Hixson
Aventail Corporation
Seattle, Washington
www.aventail.com
On Tue, 25 Sep 2001, Kenneth D. Litwak wrote:
> Maybe I don't understand the requirement, but wouldn't a front controller on
> the web tier be a more suitable place to cache the result of authentication,
> using a session area perhaps?
>
> Ken
> >
> >On Wed, 26 Sep 2001, Evan Ireland wrote:
> >
> >> Matthew,
> >>
> >> What about having a 'timeout' instance variable inside a stateful
> >> session bean that you check, only going to the DBMS if the timeout
> >> has occurred?
> >>
> >> If your admin user changes something, is it ok to have a possible
> >> time delay before this takes effect (e.g. 1 minute or 10 minutes).
> >> If so, the stateful session bean can work out ok.
> >
> >Our requirements on this are still a bit fuzzy so I'm not sure if the
> >timeout method would work for us. I will keep it in mind though.
> > Thanks for the input,
> > -M@
> >
> >> Matthew Hixson wrote:
> >>
> >> > Do you do authentication on every single method call? That is what we're
> >> > thinking about doing. The problem is that if we place a boolean flag
> >> > inside a statefull session bean to indicate that the user has been
> >> > authenticated (using another stateless session bean) then that flag can
> >> > become dirty if an administration app decides to disable that user's
> >> > account.
> >> > This dirtiness problem can be gotten around by using a stateless session
> >> > bean to authenticate the user, but making a trip to the db on every method
> >> > call just to authenticate the user (let alone how many db calls it might
> >> > take to perform the business logic) seems rather expensive.
> >> > I was thinking that it might make sense to represent the user's
> >> > authentication information with an entity bean. This way administration
> >> > software that manages users' accounts and client software that
> >> > authenticates the users can be kept in sync. If a user is logged in to
> >> > our web application and an administrator disable's that user's account
> >> > then the next action attempted by the user would be disabled. We much
> >> > prefer this over allowing the user to keep doing whatever they want until
> >> > they logout and attempt to login again.
> >> > Anyone care to comment on this problem?
> >> > -M@
> >> >
> >> > --
> >> > Matt Hixson
> >> > Aventail Corporation
> >> > Seattle, Washington
> >> > www.aventail.com
> >> >
> >> > On Tue, 25 Sep 2001, Senthoorkumaran wrote:
> >> >
> >> >
> >> >>I think using a session bean in this case is better. Keep it stateless
> >> >>too if possible. What we have done is written a Oracle package which
> >> >>will authenticate the user and at the same time will returns some
> >> >>necessary field to the front end in the same call which we will be
> >> >>working with. For example the use name and password could be passed and
> >> >>may be if it is authorized user we could send back
> >> >>SessionTimeoutInterval, FirstName, LastName.
> >> >>
> >> >>We are using session bean for this purpose and it works well.
> >> >>
> >> >>Senthoor
> >> >>
> >> >>
> >> >> -----Original Message-----
> >> >>From: A mailing list for Enterprise JavaBeans development
> >> >>[mailto:[EMAIL PROTECTED]] On Behalf Of Matthew Hixson
> >> >>Sent: Tuesday, September 25, 2001 5:46 AM
> >> >>To: [EMAIL PROTECTED]
> >> >>Subject: representing login info with entity beans?
> >> >>
> >> >>I am working on a project where we need to repeatedly authenticate
> >> >>access
> >> >>to a session bean method. Due to some technical restrictions we can't
> >> >>use
> >> >>cookies to authenticate a session. Some piece of client software may
> >> >>need
> >> >>to access the same session bean method a hundred times in a row, but we
> >> >>have no way of knowing (from the server side) whether or not those
> >> >>requests are coming from the same client. There also may be many
> >> >>clients
> >> >>accessing the same method at the same time.
> >> >> Username and password information is stored in a database. Would it
> >> >>significantly increase performance to represent the username/password
> >> >>information with an entity bean so that the container can cache that
> >> >>information instead of making a trip to the db each time?
> >> >> Anyone else out there had to solve a similar problem?
> >> >> -M@
> >> >>
> >> >>--
> >> >>Matt Hixson
> >> >>Aventail Corporation
> >> >>Seattle, Washington
> >> >>www.aventail.com
> >> >>
> >> >>========================================================================
> >> >>===
> >> >>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".
> >> >>
> >> >>
> >> >
> >> > ===========================================================================
> >> > 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".
> >> >
> >> >
> >> >
> >> >
> >>
> >
> >===========================================================================
> >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".
> >
>
===========================================================================
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".
