Custom Security / Permissions

[Andrew Zeneski]

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

[Jacopo Cappellato]

Andy,

maybe hooking a service call (instead of a call to a Java method) would
be a more linear and standardized approach (the service could then be
implemented as a Java method or in minilang etc...); as a cons there
could be a small overhead for the service call but maybe it is an
acceptable cost to have. What do you think?

Please, consider that I just had a very cursory look at your work and so
this comment could be inappropriate... if so, just ignore it!

Jacopo

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
>
>
>

[Andrew Zeneski]

Jacopo,

No this comment is 100% appropriate and exactly what I am looking  
for. When I picked this design, I was thinking it may be easier for  
vertical applications to be able to simply implement an interface,  
and one of these stock implementations would be to call a server. I  
was thinking the default (if no class was defined) would be this.

However, I'm not sure if it makes such a big difference. Service vs  
implementing an interface. So, I guess the question should be; do we  
leave the interface (is there any reason to have it?) or change it to  
only accept a service?

Andrew



On Jan 8, 2007, at 9:04 AM, Jacopo Cappellato wrote:

> Andy,
>
> maybe hooking a service call (instead of a call to a Java method)  
> would be a more linear and standardized approach (the service could  
> then be implemented as a Java method or in minilang etc...); as a  
> cons there could be a small overhead for the service call but maybe  
> it is an acceptable cost to have. What do you think?
>
> Please, consider that I just had a very cursory look at your work  
> and so this comment could be inappropriate... if so, just ignore it!
>
> Jacopo
>
> 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
>

[Adrian Crum]

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
>
>
>

[Andrew Sykes]

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 <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

[Adrian Crum]

How about making a party, product, facility, gl account, etc immutable?


Andrew Sykes wrote:

> 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
>>>
>>>
>>>

[Andrew Sykes]

Adrian,

Thanks for that, I see what you mean.

However, if all the relevant services have proper security restrictions,
why would this be a problem?

Are you thinking about the possibility of someone doing something sneaky
at the ftl/bsh level?

Thanks
- Andrew

On Mon, 2007-01-08 at 12:10 -0800, Adrian Crum wrote:

> How about making a party, product, facility, gl account, etc immutable?
>
>
> Andrew Sykes wrote:
> > 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 <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

[Andrew Zeneski]

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, 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

[Andrew Zeneski]

Thinking about this a little more maybe we should consider breaking  
this down into two independent interfaces:

org.ofbiz.security.AuthenticationHandler
org.ofbiz.security.PermissionHandler

The auth handler would be responsible for creating authenticating a  
user. An initial implementation could rip out the code used today to  
obtain the UserLogin Object. It should be discussed if this should  
always return a UserLogin object due to the fact that there are  
hundreds of places where this object is required.

An LDAP implementation could obtain the data needed to create this  
object but then we may run into problems when the userLogin object is  
used to locate party data. Maybe LDAP is also a separate topic, but I  
think the requirements needed for this should be addressed during the  
design of the new security model.

Maybe we should investigate JAAS for this.

The permission handler would simply decide if the authenticated user  
has permission to perform the requested function.

This design would allow permissions to be extended without having to  
worry about authentication; as well as the reverse.

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, 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

[Adrian Crum]

Andy,

Thanks for the reply!

I pictured my proposals being a two-step approach. It seems to me that proposal
#1 - centralized security - would be fairly easy to implement. Backward
compatibility would be maintained on the service layer - where existing service
definitions would just point to the new java class(es).

Proposal #2 would take a lot of work, and like you said, much more discussion.

So, what's next? Where do we go from here? Is there anything I can do to help?

-Adrian


Andrew Zeneski wrote:

> 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, 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
>
>

[Adrian Crum]

Comments inline:

Andrew Zeneski wrote:
> Thinking about this a little more maybe we should consider breaking  
> this down into two independent interfaces:
>
> org.ofbiz.security.AuthenticationHandler
> org.ofbiz.security.PermissionHandler
>

As long as the PermissionHandler is set up to be "swappable" like the current
security scheme. When this is all done it would be cool if I can administer
OFBiz security permissions with my LDAP DS tools.

> The auth handler would be responsible for creating authenticating a  
> user. An initial implementation could rip out the code used today to  
> obtain the UserLogin Object. It should be discussed if this should  
> always return a UserLogin object due to the fact that there are  
> hundreds of places where this object is required.

That would be fine. So, authentication would be two steps: 1. authenticate
against configured authentication service, 2. if successful, build a UserLogin
object.

> An LDAP implementation could obtain the data needed to create this  
> object but then we may run into problems when the userLogin object is  
> used to locate party data.

True - the party data could get sticky because (if I follow you correctly) LDAP
has the capability to store personal information also. Which source of personal
info do you use - OFBiz's or LDAP's?

> Maybe LDAP is also a separate topic, but I  
> think the requirements needed for this should be addressed during the  
> design of the new security model.

I think it's fine if we discuss LDAP in this topic because it's an alternative
authentication service that allows us to look at OFBiz security in a more
generalized way. Whatever issues that need to be addressed with LDAP
authentication would probably need to be addressed in any other authentication
method.

[Andrew Sykes]

Andy,

Could we use the service architecture for this rather than just a java
binary, that would make authentication integrations a lot more flexible.

Or perhaps a second set of binaries that just give some guidelines for
using the service architecture for authentication...

- Andrew

On Tue, 2007-01-09 at 08:08 -0800, Adrian Crum wrote:

> Andy,
>
> Thanks for the reply!
>
> I pictured my proposals being a two-step approach. It seems to me that proposal
> #1 - centralized security - would be fairly easy to implement. Backward
> compatibility would be maintained on the service layer - where existing service
> definitions would just point to the new java class(es).
>
> Proposal #2 would take a lot of work, and like you said, much more discussion.
>
> So, what's next? Where do we go from here? Is there anything I can do to help?
>
> -Adrian
>
>
> Andrew Zeneski wrote:
>
> > 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, 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 <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

[Adrian Crum]

Andrew Sykes wrote:

> Adrian,
>
> Thanks for that, I see what you mean.
>
> However, if all the relevant services have proper security restrictions,
> why would this be a problem?
>
> Are you thinking about the possibility of someone doing something sneaky
> at the ftl/bsh level?
>
> Thanks
> - Andrew

Generic scenarios:
Using the existing security permissions, how do you set up an OFBiz user to
view/create/update/delete a group of parties except for one - where the user can
only view that one party?

Using the existing security permissions, how do you set up an OFBiz user to be
an associate admin (where they have their own user login ID with admin
permissions) but they don't have permission to delete (or disable) the main
admin user login ID?

No, it doesn't have anything to do with hacking attempts. It has more to do with
controlling potentially malicious users, or users who simply don't pay attention
to what they're doing and end up changing data that they shouldn't.

[David E Jones-2]

Aren't we _already_ using the service engine and a centralized  
service for authentication?

How would what is being discussed be different than the userLogin  
service?

-David


On Jan 9, 2007, at 9:46 AM, Andrew Sykes wrote:

> Andy,
>
> Could we use the service architecture for this rather than just a java
> binary, that would make authentication integrations a lot more  
> flexible.
>
> Or perhaps a second set of binaries that just give some guidelines for
> using the service architecture for authentication...
>
> - Andrew
>
> On Tue, 2007-01-09 at 08:08 -0800, Adrian Crum wrote:
>> Andy,
>>
>> Thanks for the reply!
>>
>> I pictured my proposals being a two-step approach. It seems to me  
>> that proposal
>> #1 - centralized security - would be fairly easy to implement.  
>> Backward
>> compatibility would be maintained on the service layer - where  
>> existing service
>> definitions would just point to the new java class(es).
>>
>> Proposal #2 would take a lot of work, and like you said, much more  
>> discussion.
>>
>> So, what's next? Where do we go from here? Is there anything I can  
>> do to help?
>>
>> -Adrian
>>
>>
>> Andrew Zeneski wrote:
>>
>>> 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, 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 <[hidden email]>
> Sykes Development Ltd
> http://www.sykesdevelopment.com
>

[David E Jones-2]

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
>
>
>

[Andrew Zeneski]

I don't see much difference here at all. Unless there is any reason  
to provide an authentication mechanism which does not require the  
service engine to be present. I'm trying to come up with scenarios  
for this, but none as of yet.

So, if an LDAP implementation was needed, it would just follow the  
same pattern as the userLogin service. However, this is defined on  
the root engine level. Should we allow different authentication  
services on a per-service level as well, using what is defined in  
serviceengine.xml as the default if none is provided?

There are two main areas for permissions:

1) Invocation - Does the user have permission to invoke this service
2) View - Does the user have permission to view this page.

I think what we are proposing takes care of #1, the screen widget can  
be modified to call into these service based permissions as well to  
take care of #2.

I think based on what we are discussing here the end result will be  
to deprecate the existing Security object (and implementation) and  
remove all references to it (long term). Service implementations will  
no longer do permission checking and neither will raw FTL (templates  
or BSH files). The actual checking will be handled at the Service  
Dispatcher and the Screen Widget level.

CRUD services probably will not have permissions assigned, and NEVER  
called directly from requests. Maybe we add a flag to these  
definitions to prevent them from being called directly through an  
event handler. Special purpose services will be implemented (which  
call the CRUD services) to perform functions (i.e. create party,  
create order, etc). These services will have permissions set and  
often custom permission services to check if the user can perform the  
operations.

As for permissions implemented as services, I am not sure about  
SUCCESS & ERROR. Well mainly ERROR, ERROR will always do a  
transaction rollback, and maybe the permission says A or B, if A  
rolls back, B has no chance. This is why I suggested a Boolean  
return. We may be able to use SUCCESS and FAILURE (I think FAILURE  
was implemented to NOT roll back) I'll have to check the code to verify.

I think we are moving forward on this, and that's great! Let's  
continue the discussion...

Andrew


On Jan 9, 2007, at 1:16 PM, David E Jones wrote:

>
> Aren't we _already_ using the service engine and a centralized  
> service for authentication?
>
> How would what is being discussed be different than the userLogin  
> service?
>
> -David
>
>
> On Jan 9, 2007, at 9:46 AM, Andrew Sykes wrote:
>
>> Andy,
>>
>> Could we use the service architecture for this rather than just a  
>> java
>> binary, that would make authentication integrations a lot more  
>> flexible.
>>
>> Or perhaps a second set of binaries that just give some guidelines  
>> for
>> using the service architecture for authentication...
>>
>> - Andrew
>>
>> On Tue, 2007-01-09 at 08:08 -0800, Adrian Crum wrote:
>>> Andy,
>>>
>>> Thanks for the reply!
>>>
>>> I pictured my proposals being a two-step approach. It seems to me  
>>> that proposal
>>> #1 - centralized security - would be fairly easy to implement.  
>>> Backward
>>> compatibility would be maintained on the service layer - where  
>>> existing service
>>> definitions would just point to the new java class(es).
>>>
>>> Proposal #2 would take a lot of work, and like you said, much  
>>> more discussion.
>>>
>>> So, what's next? Where do we go from here? Is there anything I  
>>> can do to help?
>>>
>>> -Adrian
>>>
>>>
>>> Andrew Zeneski wrote:
>>>
>>>> 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, 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 <[hidden email]>
>> Sykes Development Ltd
>> http://www.sykesdevelopment.com
>>
>

[Adrian Crum]

Andrew Zeneski wrote:
> CRUD services probably will not have permissions assigned, and NEVER  
> called directly from requests. Maybe we add a flag to these  definitions
> to prevent them from being called directly through an  event handler.
> Special purpose services will be implemented (which  call the CRUD
> services) to perform functions (i.e. create party,  create order, etc).
> These services will have permissions set and  often custom permission
> services to check if the user can perform the  operations.

That would rock! I've always been frustrated by permissions checking in the
lower level stuff. It would be great if there was a pattern followed where
anytime the lower level services are used, they assume that permissions were
checked somewhere higher.

That's the pattern I used in https://issues.apache.org/jira/browse/OFBIZ-495.

[David E Jones-2]

On Jan 9, 2007, at 12:20 PM, Adrian Crum wrote:

> Andrew Zeneski wrote:
>> CRUD services probably will not have permissions assigned, and  
>> NEVER  called directly from requests. Maybe we add a flag to  
>> these  definitions to prevent them from being called directly  
>> through an  event handler. Special purpose services will be  
>> implemented (which  call the CRUD services) to perform functions  
>> (i.e. create party,  create order, etc). These services will have  
>> permissions set and  often custom permission services to check if  
>> the user can perform the  operations.
>
> That would rock! I've always been frustrated by permissions  
> checking in the lower level stuff. It would be great if there was a  
> pattern followed where anytime the lower level services are used,  
> they assume that permissions were checked somewhere higher.
>
> That's the pattern I used in https://issues.apache.org/jira/browse/ 
> OFBIZ-495.

This is interesting, but does it mean that for all CrUD service  
definitions that are now being called directly will have to be  
duplicated to create services with permissions? Right now the current  
patterns involve quite a bit of this. Does this mean we'd have  
alternate service definitions for each page where the lower level  
service implementation is used?

Are the different permission requirements really that conflicting?  
Based on the real-world scenarios I've been through so far using the  
pattern of general and role limited, or even multiple varieties of  
role limited, permissions is a fine way to go, and can be done  
"centrally" in the lower level services so nothing gets through  
accidentally.

I'm not quite sure where this is going, so perhaps it would be good  
to step back and start putting together some more general  
requirements and example scenarios. Given the fairly substantial  
current functionality and the amount of work that will be required  
regardless of what we choose it would be really great to get  
something good on this pass.

Part of the reason I'm bringing this up is that I'm seeing some  
"requirements" that are conflicted, for example:

1. have a central place to easily manage permissions and things  
security in general
2. have no security (or at least permission) checking on lower level  
(CrUD) services, and instead have each higher level service handle  
the permissions

-David

[Adrian Crum]

Yeah, there are two things I brought up in response to Andy's original email and
the discussion has become a mixture of the two. Maybe we should start another
thread to make a clearer distinction.

My two orignal proposals:

1. Centralize security maintenance/checking code so that an alternate security
"back-end" can be "plugged in." This has nothing to do with Andy's original
proposal. I mentioned it because I was thinking he could consider it while
mucking around in the security stuff.

2. Extend or modify the current permissions implementation to make it more
flexible. This was more along the lines of what Andy first mentioned. I'd like
to see permissions assigned in a little more organized and consistent way. As
has been pointed out, this would be a major work.

Now Andy is proposing a two-tiered service structure that would address
something that has bothered me for a while. For that I can give an example:

I developed role-oriented party data-entry screens. Instead of one application
to maintain parties in all roles (Party Manager) I have a Customer maintenance
screen, a Supplier maintenance screen, a Dealer maintenance screen, etc. A
user's role in the company determines which screens they can use.

To keep development to a minimum, I called OFBiz's party java methods directly
to perform the create/update/delete tasks. Problem was, the java methods had
permissions checking built into them. To me, that seemed redundant because the
service engine or UI had already checked permissions.

I ended up disabling the permissions checking in the java methods. It didn't
become a security issue because none of the OOTB screens were being used anyway.

Maybe OFBiz has changed some of that recently - hence your confusion. But in the
past it has been a major pain in the butt.

 From my perspective it would be cool if all service calls were organized like this:

Invoke service
   Permissions/parameter checking layer
     Perform desired action layer (permissions ignorant)



David E Jones wrote:

>
> On Jan 9, 2007, at 12:20 PM, Adrian Crum wrote:
>
>> Andrew Zeneski wrote:
>>
>>> CRUD services probably will not have permissions assigned, and  
>>> NEVER  called directly from requests. Maybe we add a flag to  these  
>>> definitions to prevent them from being called directly  through an  
>>> event handler. Special purpose services will be  implemented (which  
>>> call the CRUD services) to perform functions  (i.e. create party,  
>>> create order, etc). These services will have  permissions set and  
>>> often custom permission services to check if  the user can perform
>>> the  operations.
>>
>>
>> That would rock! I've always been frustrated by permissions  checking
>> in the lower level stuff. It would be great if there was a  pattern
>> followed where anytime the lower level services are used,  they assume
>> that permissions were checked somewhere higher.
>>
>> That's the pattern I used in https://issues.apache.org/jira/browse/ 
>> OFBIZ-495.
>
>
> This is interesting, but does it mean that for all CrUD service  
> definitions that are now being called directly will have to be  
> duplicated to create services with permissions? Right now the current  
> patterns involve quite a bit of this. Does this mean we'd have  
> alternate service definitions for each page where the lower level  
> service implementation is used?
>
> Are the different permission requirements really that conflicting?  
> Based on the real-world scenarios I've been through so far using the  
> pattern of general and role limited, or even multiple varieties of  role
> limited, permissions is a fine way to go, and can be done  "centrally"
> in the lower level services so nothing gets through  accidentally.
>
> I'm not quite sure where this is going, so perhaps it would be good  to
> step back and start putting together some more general  requirements and
> example scenarios. Given the fairly substantial  current functionality
> and the amount of work that will be required  regardless of what we
> choose it would be really great to get  something good on this pass.
>
> Part of the reason I'm bringing this up is that I'm seeing some  
> "requirements" that are conflicted, for example:
>
> 1. have a central place to easily manage permissions and things  
> security in general
> 2. have no security (or at least permission) checking on lower level  
> (CrUD) services, and instead have each higher level service handle  the
> permissions
>
> -David
>

[Adrian Crum]

Andrew Zeneski wrote:
> There are two main areas for permissions:
>
> 1) Invocation - Does the user have permission to invoke this service
> 2) View - Does the user have permission to view this page.
>
> I think what we are proposing takes care of #1, the screen widget can  
> be modified to call into these service based permissions as well to  
> take care of #2.

The object permissions idea I proposed would extend #2 to control what data
elements on the page the user can view.