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



Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to