Re: security

[Andrew Lindesay <ap...@lindesay.co.nz>]

Hello;

This was the same kind of problem I envisaged being the case with a  
similar technology -- WebObjects.  I know this isn't a WebObjects  
list, but I _think_ the same principals may apply.  I can't see how,  
at the application-server side that you can control authorisation  
around data access if data access is automatically vended for an  
object-graph over the wire.  You do want to control security at the  
user interface level as well of course or it would be confusing for  
the users, but it would not seem to me to be good to rely on the  
clients always being well behaved or not having security-related bugs.

At a basic level; in my applications, I have employed the application- 
server as a JSON-RPC provider with various end-points and methods to  
be accessed from JSON-RPC clients. Some of the methods require a  
session to access and thus can keep an object-graph between requests  
on the server-side.  Each method has some sort of logic (factored out  
or not) to check authorisation (nearly always using the session in  
some way) in order to process some inbound request.  If data objects  
are returned to the client from methods then they are serialised into  
JSON and the client is able to communicate back to the server using  
global-ids.  This approach works well for me _so_far_ although I am  
sure it's not exactly the same level of elegance of having the object- 
graph in the client-side.

cheers.

>> I am wondering about security (user, query, role level).  What  
>> approaches
>> have been taken by those using ROP for a some time?
>
> We are implementing this in our Swing (Cayenne ROP) application at  
> the moment. The best framework we've seen is the acegisecurity  
> library. Quite robust and very useful. In our case though it is not  
> quite what we need so we are going to roll our own using some ideas  
> from that library.
>
> We've found in our Swing app that we want to tie security to GUI  
> widgets and not database entities. In other words, we thought about  
> security at a Cayenne level which would have been quite easy once  
> https://issues.apache.org/cayenne/browse/CAY-400 gave us user  
> definable properties. However we had major issues about how that  
> would map to the GUI. We want some users to be able to edit  
> students in our system, but not to be able to see certain financial  
> data related to that student. They might be able to see other  
> financial data relating to courses though. It wasn't possible to  
> express this as a simple set of table or field properties at the  
> Cayenne level.
>
> So the approach we are taking is to relate security to Swing panels  
> and tabs, creating add/edit/view type rights which automatically  
> flow down to the editable fields within those panels.
>
> You didn't mention whether your app was Swing or web based...

___
Andrew Lindesay
www.lindesay.co.nz