cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <>
Subject Re: rich client db security in an untrusted environment
Date Sat, 26 Apr 2008 14:27:51 GMT
I think Tomislav's assessment of the ROP security is pretty accurate  
in a sense that by default ROP has strong authentication mechanism and  
weak authorization mechanism. So any authenticated user has full  
select and modify access to all mapped entities. Although with some  
planning and a bit of effort, a user can implement a reasonable  
security policy to prevent authenticated users against elevating their  
permission levels... I am thinking along these lines:

* Wrap and/or subclass ClientServerChannel to apply security policies  
to all incoming queries / commit requests.
* Only allow NamedQueries and RelationshipQueries to be passed via ROP  
(most certainly no SQLTemplates or EJBQLQueries).
* For RelationshipQuery check that source ObjectId is in the server- 
side DataContext cache already.
* Disable onSync calls if the application is read-only.

(I wanted to implement a basic security template in Cayenne with  
configurable checks like I described above, just didn't have enough  
motivation to do it yet).

>> In this case I have complete autonomy deciding how we're going to
>> build the application, but what would I do if I couldn't use ROP  
>> (say,
>> no servlet container available)?

Servlet container these days is just a bunch of Java classes. It's not  
like you need to install WebSphere or anything. Take a look at Jetty  
for example. You can instantiate a servlet container in your main  
method with a few lines of code.

>> Other possibilities?

Like Kevin said, any web services/RPC technology would work. You can  
make them very secure, by defining a full set of allowed operations  
via a set of "business" interfaces (and then use something like SOAP  
to expose them). But then you'd lose all the ObjectContext niceties.  
 From the original message looks like there is an understanding of  
this tradeoff.


On Apr 26, 2008, at 4:58 PM, Kevin Menard wrote:

> You could always use some other RPC mechanism.  RMI or XML-RPC / SOAP.
> These would serve as another wrapper that would keep all DB  
> operations on
> the server for sure.  At the end of the day though, you'd really  
> have to
> consider what you're actually gaining over ROP.  ROP does have its  
> flaws
> (open up JIRAs as you come across them please), but it doesn't  
> expose your
> DB as a going concern -- only ObjEntities and ObjAttributes are  
> accessible.
> It's a Web service that you can apply all of your JEE security  
> practices to.
> -- 
> Kevin
> On 4/25/08 8:29 AM, "Tomi N/A" <> wrote:
>> Hi everyone,
>> I am working on the architecture of a future system and am stuck at  
>> security.
>> The stack is GNU/linux, postgresql, cayenne and tomcat.
>> Alongside the web application, I will have a WebStart-capable swing
>> client which accesses the (remote) database.
>> I don't want the db username or password  ever to be known outside of
>> the database server.
>> The only solution I came up with is using ROP (don't know if any of
>> it's limitations are going to hurt): the user enters his/her
>> _application_ credentials which are sent to tomcat, tomcat verifies
>> the credentials using JDBCRealm (reading from the application
>> database) and allows the client to use the cayenne web service.
>> Theoretically, a malicious user might write his own swing app and log
>> in using a valid username/password combination to do whatever he  
>> likes
>> in the database (having the complete db mapping at his disposal).  
>> This
>> worries me, but it might be good enough for now (as the attacker
>> wouldn't be able to compromise the database without valid
>> credentials).
>> In this case I have complete autonomy deciding how we're going to
>> build the application, but what would I do if I couldn't use ROP  
>> (say,
>> no servlet container available)? Other possibilities?
>> I very much welcome opinions and comments.
>> Regards,
>> Tomislav

View raw message