You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cayenne.apache.org by Aristedes Maniatis <ar...@ish.com.au> on 2013/05/16 01:49:17 UTC
ROP security
We have a ROP Cayenne application we'd like to lock down a bit more tightly. In particular, in a situation where we don't trust the client application hasn't been hacked, we'd like to restrict certain activity from the client. I'm thinking of:
1. preventing SQLTemplate/EJBQL queries completely
2. adding entity listeners to catch certain write behaviour (we can't do a lot about reading data since that's easy to do at the controller level, on the client, but pretty hard to construct rules at the model level on the server)
3. creating 'partial' object entities which are missing some attributes. Sort of hollow, but only hollow on some attributes.
Has anyone attempted anything similar to the above? (2) should be easy enough, but not sure about the other requirements.
Cheers
Ari
--
-------------------------->
Aristedes Maniatis
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001 fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: ROP security
Posted by Andrus Adamchik <an...@objectstyle.org>.
On May 16, 2013, at 6:01 PM, John Huss <jo...@gmail.com> wrote:
> https://www.dropbox.com/s/g247uxpalps5xse/AuthHessianService.java
Cool!
> because SelectQuery.getRoot() returns plain Object you have to screw around to figure out what it really is.
Here is an alternative:
query.getMetadata(entityResolver).getObjEntity();
> Also inspecting the qualifier is a little difficult, but generally that's not a
> great idea anyway - better to just add things to the qualifier even if it
> results in duplicate clauses.
Agreed. You just AND it with your own qualifier and the caller will never get more objects than he's supposed to.
Andrus
Re: ROP security
Posted by Aristedes Maniatis <ar...@maniatis.org>.
On 17/05/13 1:01am, John Huss wrote:
> Here's some code we started on to do this kind of thing. It never made it
> to production, but it was close. This just defines some methods that can
> be overridden to implement security based on your specific requirements.
>
> https://www.dropbox.com/s/g247uxpalps5xse/AuthHessianService.java
Thanks that very interesting.
>
> One thing I have found cumbersome is inspecting SelectQuery objects to
> figure out what they are - because SelectQuery.getRoot() returns plain
> Object you have to screw around to figure out what it really is. Also
> inspecting the qualifier is a little difficult, but generally that's not a
> great idea anyway - better to just add things to the qualifier even if it
> results in duplicate clauses.
In my case I also want to prevent users from deleting objects they should not be able to. So I can deal with that with a mixture of validation rules in the entities themselves and preventing SQLtemplate from being able to be used from the client.
Ari
>
> John
>
> On Wed, May 15, 2013 at 6:49 PM, Aristedes Maniatis <ar...@ish.com.au> wrote:
>
>> We have a ROP Cayenne application we'd like to lock down a bit more
>> tightly. In particular, in a situation where we don't trust the client
>> application hasn't been hacked, we'd like to restrict certain activity from
>> the client. I'm thinking of:
>>
>> 1. preventing SQLTemplate/EJBQL queries completely
>> 2. adding entity listeners to catch certain write behaviour (we can't do a
>> lot about reading data since that's easy to do at the controller level, on
>> the client, but pretty hard to construct rules at the model level on the
>> server)
>> 3. creating 'partial' object entities which are missing some attributes.
>> Sort of hollow, but only hollow on some attributes.
>>
>>
>> Has anyone attempted anything similar to the above? (2) should be easy
>> enough, but not sure about the other requirements.
>>
>>
>> Cheers
>> Ari
>>
>>
>>
>>
>> --
>> -------------------------->
>> Aristedes Maniatis
>> ish
>> http://www.ish.com.au
>> Level 1, 30 Wilson Street Newtown 2042 Australia
>> phone +61 2 9550 5001 fax +61 2 9550 4001
>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>>
>
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: ROP security
Posted by John Huss <jo...@gmail.com>.
Here's some code we started on to do this kind of thing. It never made it
to production, but it was close. This just defines some methods that can
be overridden to implement security based on your specific requirements.
https://www.dropbox.com/s/g247uxpalps5xse/AuthHessianService.java
One thing I have found cumbersome is inspecting SelectQuery objects to
figure out what they are - because SelectQuery.getRoot() returns plain
Object you have to screw around to figure out what it really is. Also
inspecting the qualifier is a little difficult, but generally that's not a
great idea anyway - better to just add things to the qualifier even if it
results in duplicate clauses.
John
On Wed, May 15, 2013 at 6:49 PM, Aristedes Maniatis <ar...@ish.com.au> wrote:
> We have a ROP Cayenne application we'd like to lock down a bit more
> tightly. In particular, in a situation where we don't trust the client
> application hasn't been hacked, we'd like to restrict certain activity from
> the client. I'm thinking of:
>
> 1. preventing SQLTemplate/EJBQL queries completely
> 2. adding entity listeners to catch certain write behaviour (we can't do a
> lot about reading data since that's easy to do at the controller level, on
> the client, but pretty hard to construct rules at the model level on the
> server)
> 3. creating 'partial' object entities which are missing some attributes.
> Sort of hollow, but only hollow on some attributes.
>
>
> Has anyone attempted anything similar to the above? (2) should be easy
> enough, but not sure about the other requirements.
>
>
> Cheers
> Ari
>
>
>
>
> --
> -------------------------->
> Aristedes Maniatis
> ish
> http://www.ish.com.au
> Level 1, 30 Wilson Street Newtown 2042 Australia
> phone +61 2 9550 5001 fax +61 2 9550 4001
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>
Re: ROP security
Posted by Andrus Adamchik <an...@objectstyle.org>.
An explicit security layer provided by Cayenne would be a great improvement to ROP.
I am currently working on something like this for [JS -> JAX-RS -> Cayenne] stack with AJAX requests dynamically converted to Cayenne ops, and hence also prone to client hacking attempts. This one is easier to secure than ROP, as you can attach rules to individual REST resources, and also sandbox the client to just send query qualifiers and orderings (while the actual query object is created on the server explicitly). But of course something similar can be achieved in ROP.
> 1. preventing SQLTemplate/EJBQL queries completely
This may be achieved with a wrapper around ClientServerChannel (can be created via DI customization) overriding 'onQuery'. I'd go with "deny all/allow SelectQuery, RelationshipQuery, ObjectIdQuery" rule. These 3 queries can be tightened up a bit too - you can filter on a root entity (and prefetch paths) and deny certain entities to certain roles. You may also add restricting qualifiers to SelectQuery (and apply the same to the results of RelationshipQuery and ObjectIdQuery). I am experimenting with this now in my REST framework.
> 2. adding entity listeners to catch certain write behaviour (we can't do a lot about reading data since that's easy to do at the controller level, on the client, but pretty hard to construct rules at the model level on the server)
Yeah, you can create a listener with methods tied to some custom annotation (e.g. @RequireRoleOnCommit or @DenyCommit) :
http://cayenne.apache.org/docs/3.1/cayenne-guide/lifecycle-events.html#callback-non-persistent (see '@interface Tag' example)
So a single listener can handle all entities without knowing nothing about them upfront. A similar listener can be implemented for PostLoad to inspect the returned data (see above). I suspect the PostLoad one will create a noticeable performance hit though. And like you said crafting the rules may be hard.
> 3. creating 'partial' object entities which are missing some attributes. Sort of hollow, but only hollow on some attributes.
While ROP does not support "server-only" attributes, you can probably stuff those with some dummy values (NULL?) before returning to the client.
Andrus
On May 16, 2013, at 2:49 AM, Aristedes Maniatis <ar...@ish.com.au> wrote:
> We have a ROP Cayenne application we'd like to lock down a bit more tightly. In particular, in a situation where we don't trust the client application hasn't been hacked, we'd like to restrict certain activity from the client. I'm thinking of:
>
> 1. preventing SQLTemplate/EJBQL queries completely
> 2. adding entity listeners to catch certain write behaviour (we can't do a lot about reading data since that's easy to do at the controller level, on the client, but pretty hard to construct rules at the model level on the server)
> 3. creating 'partial' object entities which are missing some attributes. Sort of hollow, but only hollow on some attributes.
>
>
> Has anyone attempted anything similar to the above? (2) should be easy enough, but not sure about the other requirements.
>
>
> Cheers
> Ari
>
>
>
>
> --
> -------------------------->
> Aristedes Maniatis
> ish
> http://www.ish.com.au
> Level 1, 30 Wilson Street Newtown 2042 Australia
> phone +61 2 9550 5001 fax +61 2 9550 4001
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>