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
- Re: Security hole? DataSource via JNDI Jun Inamori
- Re: Security hole? DataSource via JNDI Eric Richardson
jonas_patch.zip