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
