The following issue has been updated:
Updater: Ken Horn (mailto:[EMAIL PROTECTED])
Date: Sun, 19 Sep 2004 10:11 AM
Comment:
OK - thanks for the information, looks like it's a non-issuse in Geronimo.
Not sure how to close the issue -- probs don't have access.
Changes:
description changed from 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.
to 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.
---------------------------------------------------------------------
For a full history of the issue, see:
http://issues.apache.org/jira/browse/GERONIMO-305?page=history
---------------------------------------------------------------------
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: Sun, 19 Sep 2004 10:11 AM
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
