Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v619)
In-Reply-To: <25460B96-0770-11D9-B720-000A9595E440@clara.co.uk>
References: <Pine.BSF.4.58L0.0409131435340.83810@io.frii.com>
 <20040913204713.GA1888@sweetums.ce1.client2.attbi.com>
 <Pine.BSF.4.58L0.0409131511341.83810@io.frii.com>
 <414610CF.4080302@gluecode.com>
 <1550B555-0721-11D9-B720-000A9595E440@clara.co.uk>
 <73ADFF2C-0730-11D9-8BB0-000D93C5B79C@gluecode.com>
 <3A0EF59C-075C-11D9-B720-000A9595E440@clara.co.uk>
 <9C6785AE-0763-11D9-8BB0-000D93C5B79C@gluecode.com>
 <25460B96-0770-11D9-B720-000A9595E440@clara.co.uk>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <B7D207A1-082F-11D9-8B96-000A9595E440@clara.co.uk>
Content-Transfer-Encoding: 7bit
From: Ken Horn <ken.horn@clara.co.uk>
Subject: Re: JNDI provider / remote jndi
Date: Thu, 16 Sep 2004 23:28:22 +0100
To: dev@geronimo.apache.org

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