ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Crum <adri...@hlmksw.com>
Subject Re: Custom Security / Permissions
Date Mon, 08 Jan 2007 20:10:41 GMT
How about making a party, product, facility, gl account, etc immutable?

Andrew Sykes wrote:
> Adrian, Andy,
> I really like the idea of consolidating the security down to a single
> file, that would certainly make some implementations a whole lot easier!
> I've been trying to think of a good example of where the object security
> would be used, did you have a specific example in mind where this would
> be useful Adrian?
> - Andrew
> On Mon, 2007-01-08 at 09:06 -0800, Adrian Crum wrote:
>>Thanks for bringing this up. There have been some security implementation issues 
>>in the back of my head for a while now, and I guess this is a good time to bring 
>>them up.
>>1. I would like to see the security java class extended to handle things like 
>>this, PLUS have it extended to handle the permissions & password maintenance.

>>Here's why: if all security operations (CRUD permissions + authentication) were 
>>handled by a single java class, then that single class could be replaced with a 
>>custom implementation. The framework provides some of that capability 
>>(http://ofbizwiki.go-integral.com/Wiki.jsp?page=Securitydeveloper). What I'm 
>>picturing is something like moving the securityext services to the 
>>org.ofbiz.security.Security interface. In other words, the interface would 
>>create/update/delete permissions/passwords in addition to checking them.
>>If that was done, then I could do exactly what that wiki page says - extend 
>>org.ofbiz.security.Security, write my own security handler, and that's it. Right 
>>now I would have to write my own security handler PLUS write my own version of 
>>the securityext component.
>>If ALL security operations were handled through a single security interface, 
>>then I could swap out OFBiz's security scheme with, let's say, an LDAP version.
>>2. I would also like to see the security services handle the concept proposed in 
>>  https://issues.apache.org/jira/browse/OFBIZ-455. Right now that issue is "in 
>>my court" and I've been thinking a lot about it lately. What I've concluded is 
>>that I would be developing a set of services that parallel the security 
>>services. It would be better if the security services could accomodate this kind 
>>of parameterization.
>>This could be accomplished by extending the security interface to check 
>>permissions for ANY OBJECT, instead of just user login IDs. The main weakness in 
>>OFBiz's security implementation is the assumption that permission checking will 
>>be done only on users.
>>If that change was made, then any type of permissions checking can be performed.
>>Object A wants to modify Object B.
>>If Object A and Object B are members of the same permission context, then
>>   If Object A has modify permission in that context AND Object B has 
>>modify-able permission in that context, then
>>     Object A granted permission to modify Object B
>>Andrew Zeneski wrote:
>>>It is my believe and I am sure there are others who agree, the base  
>>>permission scheme in OFBiz just doesn't cut it for application  specific 
>>>What I want to propose and make an initial decision on is a generic  
>>>schema for developing custom security implementations for specific  
>>>application purposes.
>>>What I checked in to SVN today is an initial idea I have for  
>>>implementing this. I called it ServiceSecurity.java. In any service  
>>>definition you can specify a class to call to decide if a user has  
>>>permission to invoke the service.
>>>Since this is a generic interface this allows the following:
>>>1) A simple method implementation. We can implement this interface to  
>>>call a simple method which would return a boolean. Then security  
>>>permissions can be implemented using simple methods (i.e. there are a  
>>>number of these types of methods already in OFBiz today, so this  would 
>>>be a good first step).
>>>2) A service implementation. Having a interface service which returns  a 
>>>Boolean object to decide if the user has permission.
>>>3) A custom Java implementation. Create a new class which implements  
>>>this interface which has a single method hasPermission().
>>>The reason I went this direction was to provide a very generic and  
>>>flexible way to implement security. It has been brought to my  attention 
>>>that all we really need is to do this via a service, which  in turn 
>>>could be simple method, java or whatever.
>>>I am now opening the floor to discussion; should we stick with a  
>>>generic interface and implement various classes to handle different  
>>>options, change this only operate as a service call, or should we do  
>>>something completely different.
>>>As always the decision made here is never final, technologies may  
>>>change, new ideas arise, but what I really want to do now is settle  on 
>>>our initial plan of attack.
>>>To see what is there today, see the new ServiceSecurity.java  interface 
>>>and the permission section of a service definition  (services.xsd).

View raw message