According to my understanding the user name and the password would be
sent to the back end for Authentication using a stateless session bean.
And in return to the web tier the method will return a unique ID for
that user and some other information too. Like the user group and Level
of access the specific user has. This information could be cashed in the
web tier and then used with every other method call as a parameter so
that no need for authenticating the user again. For example in our
application we have a title bar where all this information is kept as
hidden fields and used in subsequent request or method calls. In my
opinion too authenticating the user for each and every method call will
be an over kill.
Or in the example you have given below what you have mentioned is
deleting a user. So one alternative could be the action delete user
could be written in a Back End Stored Procedure and stateless session
bean will call the SP with the right parameters to delete the record. In
that case the SP could first authenticate the user and then based on the
result the deletion action could be performed I think without having two
back end calls. However I think casing in the web tier the information
needed and then using that in subsequent method calls will reduce the
network traffic a lot.
Senthoor
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]] On Behalf Of Matthew Hixson
Sent: Wednesday, September 26, 2001 5:52 AM
To: [EMAIL PROTECTED]
Subject: Re: representing login info with entity beans?
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".
===========================================================================
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".
