The following comment has been added to this issue:
Author: David Jencks
Created: Thu, 16 Sep 2004 4:12 PM
Body:
--Comments inline.
In order to protect JDBC datasource and JMS destinations / connection
factories, that are bound into the cluster JNDI tree, from j2ee client access,
provide a mechanism to simply prevent access.
--this is how geronimo currently works, so I'm not sure what you are
requesting. In a cluster (not currently implemented), each cluster member
would have the same configuration deployed on it, so there would be no reason
to ask another cluster member what's in jndi.
Note the points below relate to datastores, but they apply equally well to
other objects like authenticated JMS end-points -- secure JNDI access in
general.
--jms endpoints are deployed as administered objects. They can only be made
accessible in a components java:comp/env context. If a jms provider wishes to
provide some kind of remotable jndi context with endpoints bound in it, that's
up the the jms provider. AFAIK any remote access to administered objects in a
j2ee container is entirely outside the specs.
The request is to provide a mechanism to protect objects in jndi from being
accessed from outside the server(s) VM (obviously optional, but should be
simple to enforce).
--Right now we don't really have a remotely accessible jndi implementation in
_geronimo_. There is an openejb implementation that you can explicitly
configure ejbs to be bound into. Nothing else is bound there right now.
Internal java:comp/env lookups do not depend on this in any way, and it is
entirely unnecessary to bind anything into this context for an application
(e.g. web + ejb + connector) that does not need remote access to ejbs.
Here are some notes from a thread on the dev list (15 sept):
On Weblogic (WLS), the datastore on the default drivers is serializable (it's
bound to the clustered jndi, via a ClusterRemoteRef), and so a servlet / ejb /
client app can grab the ds from jndi ( using JNDI Reference / ObjectFactory
stuff). The ds reference in the client can then create a direct db connection
from the code to the db.
--I've always thought this was an incredibly bad idea and have yet to see any
reason to implement something like this.
So key questions are:
* are datasources / JMS objects by default serializable (does Geronimo use
something like the wls remote ref or is the raw driver datastore used?)
--j2eeca connection factories are made available in the java:comp/env context
for individual j2ee components. It is possible to configure binding into an
in-vm "geronimo:" context as well. It is not possible to bind them into
anything remotely accessible.
* can client apps access the server jndi tree?
--they can get the openejb remote jndi context to look up ejbs. They can't get
the "geronimo:" context. We don't have application-clients yet, but any
connection factory they might get will be deployed locally on the client. The
java:comp/env context for an application client will not use a global jndi
context in any way (at least if I have any input on the subject).
* if yes for the previous q, is there a way to bind an object that isn't
remotely accessible?
Suggested implementations:
* a different jndi tree - perhaps a different context factory etc
* a fixed branch of the tree with is not exported / visible to out-of-process
clients
* a naming convention
* WLS style local-only roles & run-as
Depending on the JNDI impl, any are ok -- the first is probably best, but most
hassle for users, while the next two are easier to use, but may be hacky to
implement nicely (and raises questions about being able to sandbox apps/areas
to only see bits they want.. can of worms?).
The role based one seems more j2ee, but is a pain to configure since I think
you need the facade stuff mentioned earlier.
--I'm afraid I don't understand your suggestions very clearly, and I'm not very
familiar with WLS. I often get somewhat confused by jndi discussions:-( If
you want a feature that is different from what is currently implemented in
geronimo could you explain how it differs from geronimo rather than WLS?
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/GERONIMO-305?page=comments#action_53153
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/GERONIMO-305
Here is an overview of the issue:
---------------------------------------------------------------------
Key: GERONIMO-305
Summary: JNDI local (intra cluster) access
Type: New Feature
Status: Unassigned
Priority: Major
Project: Apache Geronimo
Components:
core
Assignee:
Reporter: Ken Horn
Created: Thu, 16 Sep 2004 3:31 PM
Updated: Thu, 16 Sep 2004 4:12 PM
Description:
In order to protect JDBC datasource and JMS destinations / connection
factories, that are bound into the cluster JNDI tree, from j2ee client access,
provide a mechanism to simply prevent access.
Note the points below relate to datastores, but they apply equally well to
other objects like authenticated JMS end-points -- secure JNDI access in
general.
The request is to provide a mechanism to protect objects in jndi from being
accessed from outside the server(s) VM (obviously optional, but should be
simple to enforce).
Here are some notes from a thread on the dev list (15 sept):
On Weblogic (WLS), the datastore on the default drivers is serializable (it's
bound to the clustered jndi, via a ClusterRemoteRef), and so a servlet / ejb /
client app can grab the ds from jndi ( using JNDI Reference / ObjectFactory
stuff). The ds reference in the client can then create a direct db connection
from the code to the db.
So key questions are:
* are datasources / JMS objects by default serializable (does Geronimo use
something like the wls remote ref or is the raw driver datastore used?)
* can client apps access the server jndi tree?
* if yes for the previous q, is there a way to bind an object that isn't
remotely accessible?
Suggested implementations:
* a different jndi tree - perhaps a different context factory etc
* a fixed branch of the tree with is not exported / visible to out-of-process
clients
* a naming convention
* WLS style local-only roles & run-as
Depending on the JNDI impl, any are ok -- the first is probably best, but most
hassle for users, while the next two are easier to use, but may be hacky to
implement nicely (and raises questions about being able to sandbox apps/areas
to only see bits they want.. can of worms?).
The role based one seems more j2ee, but is a pain to configure since I think
you need the facade stuff mentioned earlier.
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
