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.
-- KevinOn 4/25/08 8:29 AM, "Tomi N/A" <hefes..mail.com> 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
This archive was generated by hypermail 2.0.0 : Sat Apr 26 2008 - 09:58:58 EDT