Another thing I thought of today was some sort of intelligent EntityValue that restricts gets or sets based on permissions defined on the security aware delegator. Stuff like that could pass through to form widgets which would automatically hide fields or make them read only.
And what about defining permission requirements on request-maps in the controller? They could automatically be applied at every stage of the request, service calls, screen/form renders and delegator calls. Then you could specify a required permission in once place only but if needed also in various other places where you want to increase the granularity.
Regards Scott On 3/05/2009, at 6:59 AM, Andrew Zeneski wrote:
Are you saying that we attach some logic to the authorization API which returns an EntityCondition object to limit the data returned in queries? This goes well with the idea I had to add an EntityUtil.filterByPermission() method. However, I don't think this is something which would replace scripts (or services) for permissions, but would be something along with it to make queries more secure. If we can come up with a generic way to implement this (or maybe only somewhat generic) I think it would be really useful.So far here are the list of other things which have been discussed and all work well with the current proposal:1. SimpleRoleCheckDa - A simple role check dynamic access class. This would include some new tables to associate table name and role type IDs for simple role based checking. You would associate the table (i.e. ContentRole) with the permission as well as valid roles (ADMIN, OWNER, etc). The simple class can be attach to any permission which only requires very simple role based checks.2. EntityUtil.filterByPermission() - A new method which (like filterByDate) takes a list of GenericValue objects and removes the ones which the user does not have permission to perform the operation on. The permission string would be passed and parsed using the value for the entity. Nice way to pull out data a user should not see, but limited as it will not work with the ELI.3. Associate EntityCondition with permissions (correct me if I am wrong here) to have a unified way of limiting data in queries. If this is possible, the filterByPermission might not be necessary.Andrew On May 2, 2009, at 8:02 AM, Scott Gray wrote:One thing that came to mind during our "discussion" today and I'm not sure how feasible it is but I'll throw it out there anyway: Most record based permission checks come to down querying the database for related records to check various roles and whatnot right? So what if instead of querying the database independently we provided some sort of security wrapped delegator to the applications that intercepts database queries and automatically appends the required entity expressions to the query.If it is a findOne/getRelatedOne query and no result is returned then you throw some sort of authorization exception because obviously the user didn't fit the criteria of someone able to view the record. If it's a findList/getRelated then only the permissible records would be returned.So instead of writing scripts for permissions we would write some sort of entity expression. Just a thought.Regards Scott On 2/05/2009, at 1:30 PM, Andrew Zeneski wrote:I think everyone needs to step back just a bit. Yes, some code was written, but nothing that drastically changes anything. Actually, I paid very close attention to make sure that this could sit on the side lines so it could be evaluated. Very little effort has been put into the real work of migrating the applications, but that is going to change soon...So, instead of discussing what should or should not have been done, look at the fact that this entire effort is sitting in the community's lap right this minute. But instead of reviewing what is there, pointing out weaknesses offering suggestions or anything constructive at all, the discussion is solely around whether or not code should have been implemented or not. Let's face it, these documents have been in front of you for over a week, and there was not a single objection or concern raised until today. I have only a limited amount of free time, and if I am going to following this effort through to the end, it needs to have a steady progression. So to be frank, get over it.Code is being worked on actively for this effort, and I am expecting more involvement as soon as the API is finalized. That said, if you do have something to add, wish to see or just want to be involved, now is the time to be proactive! Otherwise the effort will push forward with the people who are indeed interested in improving security in OFBiz.Andrew On May 1, 2009, at 8:38 PM, Adrian Crum wrote:--- On Fri, 5/1/09, Scott Gray <[email protected]> wrote:Some of these questions in the discussions so far give me the feeling that the write up Andrew put in confluence hasn't been read, is that the case? Anyway I'm a +1 for the new auth framework, I think it give us more power AND simplicity. Will it need improvement over time? of course it will but I think it's a much better base to work from.I don't know if you were around at the time, but I was. One of the "weaknesses" Andrew is trying to fix with this latest effort is the permissions services - another design he introduced a couple years ago. Everyone went along with it and re-wrote code to use service permissions. (I spent several weekends just converting the accounting component over to the new security implementation). Now we're being told "Oops, that design is limited, let me try again."Why would anyone have any objection to opening this up to the community before we start writing code? Maybe there are others who see weaknesses in the new design. Give them a chance to offer input.-Adrian
smime.p7s
Description: S/MIME cryptographic signature
