You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Bruce Snyder <fe...@frii.com> on 2004/09/13 22:36:45 UTC
JNDI provider
What JNDI provider is Geronimo using?
Bruce
--
perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
The Castor Project
http://www.castor.org/
Apache Geronimo
http://incubator.apache.org/projects/geronimo.html
Re: JNDI provider / remote jndi
Posted by Ken Horn <ke...@clara.co.uk>.
JIRA added: 305
On 16 Sep 2004, at 00:37, Ken Horn wrote:
>
> On 15 Sep 2004, at 23:07, Dain Sundstrom wrote:
>
>> On Sep 15, 2004, at 2:14 PM, Ken Horn wrote:
>>
>>> On WLS, the datastore on the default drivers is serializable (it's
>>> bound to the clustered jndi, via a ClusterRemoteRef), and so an
>>> servlet / ejb / client app can grab the ds from jndi (this may be
>>> using JNDI Reference / Factory stuff). The ds can then create a
>>> direct db connection from the code to the db.
>>
>> Ah your talking WLS. Does this only work when you use weblogic's
>> drivers or does it work with any driver? I suppose we could do the
>> same thing. Does WLS handle moving the driver classes to the client
>> or does it assume you have all the classes you need on the client?
>>
>
> OK. Have tried it with a WLS datasource, backed by a Sybase driver.
> This seems (from ktrace output) to pull a sybase ds across the rmi
> (the client prog has no jdbc drivers) loader, all configured. So looks
> quite WLS specific.
>
> However, I also bound a raw SybDataSource instance into jndi, and
> pulled it out from the client (this needed the syb driver jar to
> provide the object factory to convert the javax.naming.Reference to a
> SybDataSource. This worked, so I think any jndi may have this problem
> / feature.
>
>>> Therefore, if I bind a datasource into jndi, and fail to protect it
>>> via some contorted config (what we've thought of so far, is facades
>>> calling runAs beans through local interfaces), any user that can
>>> authenticate, and can write a java client (or find one), can access
>>> the database direct.
>>
>> Assuming it has the permissions.... or does WLS serialize the
>> username and password?
>>
>
> Either of the methods above have the database logins already contained
> in the datasource... and by casting back to SybDS in the second method
> I can get the db password -- nice!
>
>>> I was wondering if the same is possible in Geronimo...
>>>
>>> So key questions are:
>>> * are datasources by default serializable (does Geronimo use
>>> something like the wls remote ref or is the raw driver datastore
>>> used?)
>>
>> Not currently, but if you want it start by adding a JIRA "New
>> Feature" issue.
>>
>
> I think DS's should probably be Serializable to permit this when
> desired, though I think they should generally avoid the password being
> seen. (not sure how, other than going back via the server..). I'll
> think about this some more before raising an issue.
>
>
>>> * can client apps access the server jndi tree?
>>
>> Not yet. Currently an client can only see EJBs with Remote
>> interfaces via JNDI.
>>
>
> Is that because only remote interfaces are bound into that JNDI
> impl/instance or some other deeper reason?
>
>>> * if yes for the previous q, is there a way to bind an object that
>>> isn't remotely accessible?
>>
>> N/A, but we may change the above so what do you suggest we do?
>>
>
> I think any of:
> * 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.
>
>> -dain
>>
>
> Ken
>
>>
>>
>
>
>
Re: JNDI provider / remote jndi
Posted by Ken Horn <ke...@clara.co.uk>.
On 15 Sep 2004, at 23:07, Dain Sundstrom wrote:
> On Sep 15, 2004, at 2:14 PM, Ken Horn wrote:
>
>> On WLS, the datastore on the default drivers is serializable (it's
>> bound to the clustered jndi, via a ClusterRemoteRef), and so an
>> servlet / ejb / client app can grab the ds from jndi (this may be
>> using JNDI Reference / Factory stuff). The ds can then create a
>> direct db connection from the code to the db.
>
> Ah your talking WLS. Does this only work when you use weblogic's
> drivers or does it work with any driver? I suppose we could do the
> same thing. Does WLS handle moving the driver classes to the client
> or does it assume you have all the classes you need on the client?
>
OK. Have tried it with a WLS datasource, backed by a Sybase driver.
This seems (from ktrace output) to pull a sybase ds across the rmi (the
client prog has no jdbc drivers) loader, all configured. So looks quite
WLS specific.
However, I also bound a raw SybDataSource instance into jndi, and
pulled it out from the client (this needed the syb driver jar to
provide the object factory to convert the javax.naming.Reference to a
SybDataSource. This worked, so I think any jndi may have this problem /
feature.
>> Therefore, if I bind a datasource into jndi, and fail to protect it
>> via some contorted config (what we've thought of so far, is facades
>> calling runAs beans through local interfaces), any user that can
>> authenticate, and can write a java client (or find one), can access
>> the database direct.
>
> Assuming it has the permissions.... or does WLS serialize the username
> and password?
>
Either of the methods above have the database logins already contained
in the datasource... and by casting back to SybDS in the second method
I can get the db password -- nice!
>> I was wondering if the same is possible in Geronimo...
>>
>> So key questions are:
>> * are datasources by default serializable (does Geronimo use
>> something like the wls remote ref or is the raw driver datastore
>> used?)
>
> Not currently, but if you want it start by adding a JIRA "New Feature"
> issue.
>
I think DS's should probably be Serializable to permit this when
desired, though I think they should generally avoid the password being
seen. (not sure how, other than going back via the server..). I'll
think about this some more before raising an issue.
>> * can client apps access the server jndi tree?
>
> Not yet. Currently an client can only see EJBs with Remote interfaces
> via JNDI.
>
Is that because only remote interfaces are bound into that JNDI
impl/instance or some other deeper reason?
>> * if yes for the previous q, is there a way to bind an object that
>> isn't remotely accessible?
>
> N/A, but we may change the above so what do you suggest we do?
>
I think any of:
* 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.
> -dain
>
Ken
>
>
Re: JNDI provider / remote jndi
Posted by Dain Sundstrom <ds...@gluecode.com>.
On Sep 15, 2004, at 2:14 PM, Ken Horn wrote:
> On WLS, the datastore on the default drivers is serializable (it's
> bound to the clustered jndi, via a ClusterRemoteRef), and so an
> servlet / ejb / client app can grab the ds from jndi (this may be
> using JNDI Reference / Factory stuff). The ds can then create a direct
> db connection from the code to the db.
Ah your talking WLS. Does this only work when you use weblogic's
drivers or does it work with any driver? I suppose we could do the
same thing. Does WLS handle moving the driver classes to the client or
does it assume you have all the classes you need on the client?
> Therefore, if I bind a datasource into jndi, and fail to protect it
> via some contorted config (what we've thought of so far, is facades
> calling runAs beans through local interfaces), any user that can
> authenticate, and can write a java client (or find one), can access
> the database direct.
Assuming it has the permissions.... or does WLS serialize the username
and password?
> I was wondering if the same is possible in Geronimo...
>
> So key questions are:
> * are datasources by default serializable (does Geronimo use something
> like the wls remote ref or is the raw driver datastore used?)
Not currently, but if you want it start by adding a JIRA "New Feature"
issue.
> * can client apps access the server jndi tree?
Not yet. Currently an client can only see EJBs with Remote interfaces
via JNDI.
> * if yes for the previous q, is there a way to bind an object that
> isn't remotely accessible?
N/A, but we may change the above so what do you suggest we do?
-dain
Re: JNDI provider / remote jndi
Posted by Ken Horn <ke...@clara.co.uk>.
On WLS, the datastore on the default drivers is serializable (it's
bound to the clustered jndi, via a ClusterRemoteRef), and so an servlet
/ ejb / client app can grab the ds from jndi (this may be using JNDI
Reference / Factory stuff). The ds can then create a direct db
connection from the code to the db.
Therefore, if I bind a datasource into jndi, and fail to protect it via
some contorted config (what we've thought of so far, is facades calling
runAs beans through local interfaces), any user that can authenticate,
and can write a java client (or find one), can access the database
direct.
I was wondering if the same is possible in Geronimo...
So key questions are:
* are datasources 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?
Ken.
On 15 Sep 2004, at 17:01, Dain Sundstrom wrote:
> On Sep 15, 2004, at 7:11 AM, Ken Horn wrote:
>
>> Quick question on remote JNDI access.
>>
>> Does the java: provider below one provide remote access -- ie j2ee
>> client app?
>>
>> For security reasons, we want to be able to bind some/all resources
>> for a given app into a jndi tree (by any reasonable means: subtree /
>> provider / naming convention) that cannot be accessed outside of the
>> cluster. This will stop users who can authenticate to the container,
>> being able to write a client app, to pull (for example) a database
>> connection out of jndi and bypass business rules to hit the db
>> directly.
>
> Ken,
>
> I don't see how a remote client would be able to "pull" a database
> connection from jndi, since database connection is not serializable.
>
> As for the meat of your question, I personally don't know the answer.
>
> -dain
>
>
>
Re: JNDI provider / remote jndi
Posted by Dain Sundstrom <ds...@gluecode.com>.
On Sep 15, 2004, at 7:11 AM, Ken Horn wrote:
> Quick question on remote JNDI access.
>
> Does the java: provider below one provide remote access -- ie j2ee
> client app?
>
> For security reasons, we want to be able to bind some/all resources
> for a given app into a jndi tree (by any reasonable means: subtree /
> provider / naming convention) that cannot be accessed outside of the
> cluster. This will stop users who can authenticate to the container,
> being able to write a client app, to pull (for example) a database
> connection out of jndi and bypass business rules to hit the db
> directly.
Ken,
I don't see how a remote client would be able to "pull" a database
connection from jndi, since database connection is not serializable.
As for the meat of your question, I personally don't know the answer.
-dain
Re: JNDI provider / remote jndi
Posted by Ken Horn <ke...@clara.co.uk>.
Quick question on remote JNDI access.
Does the java: provider below one provide remote access -- ie j2ee
client app?
For security reasons, we want to be able to bind some/all resources for
a given app into a jndi tree (by any reasonable means: subtree /
provider / naming convention) that cannot be accessed outside of the
cluster. This will stop users who can authenticate to the container,
being able to write a client app, to pull (for example) a database
connection out of jndi and bypass business rules to hit the db
directly.
Thanks for any help,
Ken.
On 13 Sep 2004, at 22:27, Jeremy Boynes wrote:
> Bruce Snyder wrote:
>
>> My apologies, I didn't ask this correctly. Where did we get the
>> JNDI implementation?
>
> There are actually a couple that we use based on different
> characteristics.
>
> The one for java: is located in o.a.g.naming and is designed for fast,
> read-only access - what happens with ENC lookups. A group of us wrote
> it.
>
> The one for geronimo: is in the same package and supports in-vm access
> and is used for EJB and resource bindings. IIRC David Jencks did most
> of that based on the java: code.
>
> For EJB remoting we are using the one from OpenEJB; this may change at
> some point to use other global naming services such as Eve.
>
> --
> Jeremy
>
>
>
Re: JNDI provider
Posted by Jeremy Boynes <jb...@gluecode.com>.
Bruce Snyder wrote:
>
> My apologies, I didn't ask this correctly. Where did we get the
> JNDI implementation?
>
There are actually a couple that we use based on different characteristics.
The one for java: is located in o.a.g.naming and is designed for fast,
read-only access - what happens with ENC lookups. A group of us wrote it.
The one for geronimo: is in the same package and supports in-vm access
and is used for EJB and resource bindings. IIRC David Jencks did most of
that based on the java: code.
For EJB remoting we are using the one from OpenEJB; this may change at
some point to use other global naming services such as Eve.
--
Jeremy
Re: JNDI provider
Posted by Bruce Snyder <fe...@frii.com>.
This one time, at band camp, David Blevins said:
DB>To lookup an EJB from a client you use org.openejb.client.RemoteInitialContextFactory
DB>
DB>Not sure if that was the provider you were talking about.
Thanks, David! Unfortunately I didn't ask this question very well.
DB>On Mon, Sep 13, 2004 at 02:36:45PM -0600, Bruce Snyder wrote:
DB>> What JNDI provider is Geronimo using?
My apologies, I didn't ask this correctly. Where did we get the
JNDI implementation?
Bruce
--
perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
The Castor Project
http://www.castor.org/
Apache Geronimo
http://incubator.apache.org/projects/geronimo.html
Re: JNDI provider
Posted by David Blevins <da...@visi.com>.
To lookup an EJB from a client you use org.openejb.client.RemoteInitialContextFactory
Not sure if that was the provider you were talking about.
-David
On Mon, Sep 13, 2004 at 02:36:45PM -0600, Bruce Snyder wrote:
> What JNDI provider is Geronimo using?
>
> Bruce
> --
> perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
>
> The Castor Project
> http://www.castor.org/
>
> Apache Geronimo
> http://incubator.apache.org/projects/geronimo.html