My vote for this would be to use something like #2 with the service implementation, and perhaps just use the response code (success or error or whatever) to return the result.
The reason for this is that I'm guessing we'll be looking at a large number of such services over time and we need a good way to make it flexible and manageable, which for logic is what the Service Engine is all about.
-David On Jan 5, 2007, at 9:13 PM, 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
