1. Yes, I think I do, because one of our EJB Entities can be accessed by
different J2EE roles - such as Administrator, Animator, Salesman, and some
other in the future - that have not the same privileges. For example, a
method of one EJB Entity allows to create a new "attribute" (key/value for
marketing purpose) to an user, that implies the creation of a new record,
into a table UserAttributes, corresponding to this User. Only Administrator
and Salesman are allowed to add a new attribute to an user, nor Animator or
other.
I have heard that some J2EE servers provide security access for each method
of an EJB, but I don't think this is a standard that all J2EE servers
implement ? I think I have two solutions:
a. the first one would correspond to implement security in my method and
check whether the caller role is allowed to access this method or not. But
all the roles are not defined yet, some would be added in the future. So
this solution is not easy to maintain.
b. Because the method just inserts a new record in database (there isn't
real business work), the second solution would be to let database controls
security access. This is the reason why we want to use a mapping between
J2EE roles and database accounts. Jonathan Baker presents me a good way to
implement this: "Have each bean call directly to access a connection cache,
using a String variable for the JNDI name for that cache. Then, write a
stateless session bean that returns the JNDI name of the cache we need to
access, based on the role of the user. Call the stateless session bean, and
then use the name it provides to lookup the correct connection cache. This
will allow us to map the caches differently for each bean, but will
encapsulate the logic of choosing the JNDI name in a single place".
-----Message d'origine-----
De : A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]De la part de Sriram Narayan (CTS)
Envoy� : mercredi 22 novembre 2000 07:51
� : [EMAIL PROTECTED]
Objet : Re: EJB optimization and performance
hi dan
my thoughts: (pls do correct me if i've got it all wrong)
1. Do u really need to have a 1-1 mapping between J2EE roles and Database
accounts? AFAIK, there are 2 reasons to have multiple accounts: one for
different levels of access and the other for auditing who has done what.
When we use J2EE security, both the above requirements are satisfied at the
level of middleware itself. So, are there any dangers if u leave the task of
access control and auditing solely to the middleware and just go ahead with
one common connection pool for all ejbs? (ok, 2 DB accounts, one for
sys-admin and the other for all)
2. This question is on a different track. Assuming that multiple DB accounts
must exist, is it possible to do away with the alias between a J2EE role and
the db account name? Consider this, the appserver uses a set of 'realm
classes' to access the security realm. Generally the realm classes provide
information on user, password and group membership. Could these realm
classes be extended to provide the appropriate connection object based on
current role? (i am getting a feeling that i have only reworded ur original
question, but now that i have written it, i'll let it stay.)
awaiting ur response.
thanks
sriram
This e-mail and any files transmitted with it are for the sole use
of the intended recipient(s) and may contain confidential and privileged
information.
If you are not the intended recipient, please contact the sender by reply
e-mail and
destroy all copies of the original message. Any unauthorised review, use,
disclosure,
dissemination, forwarding, printing or copying of this email or any action
taken in
reliance on this e-mail is strictly prohibited and may be unlawful.
Visit us at http://www.cognizant.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".
