[ http://nagoya.apache.org/jira/browse/GERONIMO-305?page=history ]
Aaron Mulder closed GERONIMO-305:
---------------------------------
Resolution: Invalid
Submitted requested issue be closed
> JNDI local (intra cluster) access
> ---------------------------------
>
> Key: GERONIMO-305
> URL: http://nagoya.apache.org/jira/browse/GERONIMO-305
> Project: Apache Geronimo
> Type: New Feature
> Components: core
> Reporter: Ken Horn
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://nagoya.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
