Hi,
I see few problems with the suggestions below from a J2EE server perspective.
The whole idea of a server is to share resources. If connection pools and other
resources are setup for a server then control of these resources is a deployment
issue. The developer requests a resource via the deployment descriptor and the
deployment person associates that resource with the correct resources. This is
the security gateway to the server.
These pools of resources should be available to servlets, JSP, and other legacy
code such as existing object to relational mapping code. In fact, we spent
several man months modifying existing code to try and make it coexist in a J2EE
server. The several man months was justified by the fact that several man years
of existing production code does not go away quickly.
The fact that an interface can be casted to an implementation and the
implementation has public methods that are sensative is an implementation issue.
Remember that if I write the security code perhaps for a login process then I
could grab passwords. Honesty and Code reviews are the only truely safe way to
make sure code is well behaved.
Now, if the code is mobile, it can be isolated via codebase and treated with
special security policies. Also certainly code that comes from EAR or WAR can be
limited via the java.policy file.
Please consider interoperability when making changes to the code base.
Thanks,
Eric :-)
Jun Inamori wrote:
> Hi,
>
> As described in:
> 14.4.1.1 Programming interfaces for resource factory references
> of EJB Spec 1.1,
> JOnAS2.0 implements DataSourceFactory and ConnectionManager so that our
> bean instance can obtain the reference to DataSource through JNDI.
> Given the sign-on information for underlying database by the deployment
> descriptor, our beans can get JDBC connection just by 'getConnection()'
> without hard-coded user name and password.
> And this is what EJB Spec requires the Container.
> (See the italic-ed sentence of page 212)
> So, I think the current implementation fully complies with the spec.
>
> On the other hand, restricting the access to our database is the
> critical issue, especially for network programming.
> In addition to the fact that EJB is network oriented, EJB server may be
> used for multiple applications.
> For example, someone may start EJB-hosting service (something like
> web-hosting service) using JOnAS in the near future.
> This means the access privilege to the underlying database between bean
> instances is also important.
>
> The above is why I insist the implementation of DataSourceFactory and
> ConnectionManager.
> My desirable implementation is:
> 1: The ConnectionManager cannot be retrieved outside the JOnAS. The
> current implementation allows some hacker to know the username and
> password of our database.
> 2: ConnectionManager.getConnection() can be used only by the bean
> instance who has <res-auth>Container</res-auth> element in the
> deployment descriptor.
> 3: ConnectionManager.getConnection(String username,String password) can
> be used only by the bean instance who has
> <res-auth>Application</res-auth> element in the deployment descriptor.
>
> As for 1, the following code (outside our JOnAS) works given the JNDI
> name of our DataSource:
> Context con=new InitialContext();
> Object ds_obj=con.lookup(name);
> DataSource ds=(DataSource)ds_obj;
> String usr=((ConnectionManager)ds).getUserName());
> String pss=((ConnectionManager)ds).getPassword());
>
> The 3 above also ensures that only such a bean instance is allowed to
> log into the db with the privilege different than bean instances of
> container authentication. Most db software allows us to define the users
> with the different access privileges, and I've seen the actual system
> which depends on such a feature. Although this is not the EJB Spec
> intends, there may be a case that we need to give some specific beans
> the higher privilege.
>
> And Pool.openConnection(String user,Transaction tx) within
> ConnectionManager does not examine the username of PoolItem. It returns
> the PoolItem regardless the username.
>
> As you notice, I've posted some of my implementation for
> DataSourceFactory and related classes.
> My new code is very different than those. DataSourceFactory always
> returns ConnectionManager unless it is called outside JOnAS. But
> ConnectionManager.getConnection() or
> ConnectionManager.getConnection(String username,String password) returns
> null in inappropriate case.
> I attached the source code to this mail.
>
> After extracted, you will find my modified source files under the
> directory of 'modified_src'.
> The code fragments between:
> //Start:Jun Inamori (For authentication of DataSource)
>
> //End:Jun Inamori (For authentication of DataSource)
> are related ones.
>
> Any comments are welcome.
> --
>
> Happy Java programming!
>
> Jun Inamori
> OOP-Reserch
> E-mail: [EMAIL PROTECTED]
> URL: http://www.oop-reserch.com
>
> ------------------------------------------------------------------------
> Name: jonas_patch.zip
> jonas_patch.zip Type: Zip Compressed Data (application/x-zip-compressed)
> Encoding: base64
----
This list is cross-posted to two mail lists. To unsubscribe,
follow the instructions below for the list you subscribed to.
For objectweb.org: send email to [EMAIL PROTECTED] and
include in the body of the message "unsubscribe ejb-container-group".
For enhydra.org: send email to [EMAIL PROTECTED] and include
in the body of the message "unsubscribe ejb-container-group".
