Adrian,I took a look at this as well thinking this would be the ideal place to start. After looking at what was there today, it seemed like a ton of work to make this happen. We HAVE to maintain backwards compatibility (for a while) but I think this could be doable.
I do like the idea of keeping security centralized. Have the base security implementation, and then another security for services seems a little redundant.
One of my main concerns is to make sure this is extendable by any/all applications. Meaning the content permissions, workeffort permissions, etc can all be implemented the same way.
This *could* be done by specifying the name of the security class for each application (web.xml).
Even though this is probably more complex than what I had proposed, it may be a better way to go. I would like to push this discussion further so and get more feedback/ideas from the rest of the community.
Off subject for a moment, I have an LDAP server sitting in my sandbox. This is a partial integration with the ApacheDS project. Right now the container loads and provides LDAP services (reverse of what you were talking about), but it still needs integration with Party and Security via the Entity Engine. The reason I bring this up is if this integration was complete we technically *could* make LDAP authentication the default, allowing a simple configuration to change the LDAP server. I guess this would be a topic in itself.
Andrew On Jan 8, 2007, at 12:06 PM, 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, thenObject 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
smime.p7s
Description: S/MIME cryptographic signature
