Hey Guys,
Thank you for the responses.(mike,Eric, Amando and Andrus)
1. Overriding the validation function is definitely the way we'll go for the security checks on commit.
But, I will probably have to change the cayenne generation class(es) to include the generation of this code and the call to my validation module, as I need it to be done automatically (as client will be modeling its model for his/her own application and not us, developers).
2. Regarding the row level security access, what I need is based on some security group model to display some rows or not. I.e: users who are part of secGroup1 can see rows in the user table in this range: 0 < user_age <18 for instance (i.e: the minors). Usually, the way I have done in the past, is by dynamically creating views ( in this case for example, we would create a view based on the user table where the user_age>0 and user_age<18) and having the queries against the user table redirected to the correct view depending on the security group of the user requesting the information. Is there a way to dynamically create a view in Cayenne?
Another approach, simpler probably, would be to append the where clause to every single query against a specific objEntity. That would involve intercepting the queries to the all objEntity and applying this logic before executing the query. Is there a way to intercept the query to an objEntity? I was looking at the Observer..
3. Regarding the data domain, I understand the usefulness of it as you mentioned, but unfortunately it is all dynamic in my case...
Thkx
Mehdi-
-----Original Message-----
From: Andrus Adamchik [mailto:andru..bjectstyle.org]
Sent: Monday, May 17, 2004 1:17 PM
To: cayenne-use..bjectstyle.org
Subject: Re: Security Model?
As you see from other posts, there is more than one way to do things.
It is up to you to decide which one is more appropriate, considering
flexibility, performance implications and so on. So here is an overview
with a few important additions that haven't been mentioned.
1. Security checks on commit. As recommended by Eric, "validate*"
methods is a way to go, as the validation will be done at the object
level, so you can check both entity and row-level rules.
2. Security checks on object access. Mike's solution of overriding the
setters allows to apply the rules even before object is committed. I
can suggest a modified version of this solution that maybe more
appropriate if you don't want to go as a low as object properties -
override CayenneDataObject.setPersistenceState(..). This way you can
track persistent state transitions of individual objects and apply the
rules (e.g. when an object is transitioned between TRANSIENT and NEW,
between anything and DELETED, between anything and MODIFIED).
Note that "anything to COMMITTED" transition check won't work, as
objects has been committed to DB already by this point. Now I am
thinking that this is rather arbitrary and we may need to fix it.
3. Organizing Entities into DataDomains. This feature is often
overlooked, but DataDomains are there for the sole purpose of providing
coarse-grained access security. It has many advantages over other
approaches, as it is declarative and completely controlled by the
framework. There are a few limitations though. You can't go lower than
entity-level security. Also it is not as dynamic, i.e. you'll have to
define what entities are accessible within a given DataDomain upfront.
But if you can map your security roles to a set of entities,
DataDomains can be very helpful.
Defining "read-only" entities and entity qualifiers per DataDomain are
two "creative" ways to make DataDomains approach more flexible.
Andrus
On May 17, 2004, at 10:45 AM, Mehdi Bennani wrote:
> Hey Cayenners,
>
> I understand that Cayenne is a data modeling tool, and a security
> model may not be the main focus of the tool. But, I was just wondering
> if you guys thought of that at some point and what would be the best
> approach for it.
>
> By Security model, I mean a way for the developer to attach
> permissions to the different objEntities, so that only authorized
> users can update/delete/insert the objEntities. Also, eventually
> permissions on the rows in the database and so on... We have the need
> for that sort of implementation in our projects.
>
> We are thinking of build this model around the objEntities as the
> smallest level of granularity. It could certainely be used at the
> datacontext level also...
>
> So, I was wondering if you already had an idea on how/where this could
> be plugged in...
>
> Sincerely,
>
> Mehdi Bennani
> Software Engineer
> FreeBalance Inc.
> Visit the new FreeBalance website..www.FreeBalance.com
>
> T (613) 236-5150 ext.325
> F (613) 236-7785
> mbennan..reeBalance.com
This archive was generated by hypermail 2.0.0 : Mon May 17 2004 - 15:57:27 EDT