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: > Andy, > > 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. > > Example: > Object A wants to modify Object B. > > Implementation: > 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 > > security. > > > > 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). > > > > Andrew > > > > > > -- Kind Regards Andrew Sykes <[EMAIL PROTECTED]> Sykes Development Ltd http://www.sykesdevelopment.com
