You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@geronimo.apache.org by de...@geronimo.apache.org on 2004/09/17 01:13:38 UTC

[jira] Commented: (GERONIMO-305) JNDI local (intra cluster) access

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):

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?

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