Proposal: Simplify Security Implementation

[Adrian Crum-3]

An OFBiz user can replace the default org.ofbiz.security.Security
implementation with their own by changing some configuration files. From
my perspective, those configuration changes are overly complicated.

In the current implementation, security.xml contains a list of
org.ofbiz.security.Security implementation class names, and
security.properties (security.context property) selects an
implementation from the list. If an OFBiz user wanted to replace the
default org.ofbiz.security.Security implementation with their own, they
would have to modify both files.

So, it looks like the original intent was to have OFBiz support multiple
Security implementations that can be selected via a property. I'm not
convinced that we need this level of complexity.

At the least we could reduce implementation selection down to a single
property (the implementation class name) and eliminate the XML file.

My preference would be to use Java's ServiceLoader to locate an
implementation without the need to change any properties. This is the
design we use currently for other "pluggable" things. So, OFBiz would
try to locate a Security implementation via Java's ServiceLoader, and if
one isn't found it uses the default implementation.

What do you think?

--
Adrian Crum
Sandglass Software
www.sandglass-software.com

[Jacopo Cappellato-4]

Hi Adrian,

thanks for looking at this and I agree with the general approach you suggests; however it would be great if the new design would simplify the integration with Apache Shiro:
http://shiro.apache.org

I see a good fit with OFBiz that could simplify and reduce lot of our code.

Jacopo

On Oct 8, 2013, at 6:11 PM, Adrian Crum <[hidden email]> wrote:

> An OFBiz user can replace the default org.ofbiz.security.Security implementation with their own by changing some configuration files. From my perspective, those configuration changes are overly complicated.
>
> In the current implementation, security.xml contains a list of org.ofbiz.security.Security implementation class names, and security.properties (security.context property) selects an implementation from the list. If an OFBiz user wanted to replace the default org.ofbiz.security.Security implementation with their own, they would have to modify both files.
>
> So, it looks like the original intent was to have OFBiz support multiple Security implementations that can be selected via a property. I'm not convinced that we need this level of complexity.
>
> At the least we could reduce implementation selection down to a single property (the implementation class name) and eliminate the XML file.
>
> My preference would be to use Java's ServiceLoader to locate an implementation without the need to change any properties. This is the design we use currently for other "pluggable" things. So, OFBiz would try to locate a Security implementation via Java's ServiceLoader, and if one isn't found it uses the default implementation.
>
> What do you think?
>
> --
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com

[Adrian Crum-3]

I don't understand. If you want to replace the default implementation
(entity engine based) with a Shiro based implementation, you can do that
now - but it would require changing two configuration files. I'm only
suggesting that we simplify Security implementation discovery by using
Java's ServiceLoader instead of property files.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 10/8/2013 9:20 AM, Jacopo Cappellato wrote:

> Hi Adrian,
>
> thanks for looking at this and I agree with the general approach you suggests; however it would be great if the new design would simplify the integration with Apache Shiro:
> http://shiro.apache.org
>
> I see a good fit with OFBiz that could simplify and reduce lot of our code.
>
> Jacopo
>
> On Oct 8, 2013, at 6:11 PM, Adrian Crum <[hidden email]> wrote:
>
>> An OFBiz user can replace the default org.ofbiz.security.Security implementation with their own by changing some configuration files. From my perspective, those configuration changes are overly complicated.
>>
>> In the current implementation, security.xml contains a list of org.ofbiz.security.Security implementation class names, and security.properties (security.context property) selects an implementation from the list. If an OFBiz user wanted to replace the default org.ofbiz.security.Security implementation with their own, they would have to modify both files.
>>
>> So, it looks like the original intent was to have OFBiz support multiple Security implementations that can be selected via a property. I'm not convinced that we need this level of complexity.
>>
>> At the least we could reduce implementation selection down to a single property (the implementation class name) and eliminate the XML file.
>>
>> My preference would be to use Java's ServiceLoader to locate an implementation without the need to change any properties. This is the design we use currently for other "pluggable" things. So, OFBiz would try to locate a Security implementation via Java's ServiceLoader, and if one isn't found it uses the default implementation.
>>
>> What do you think?
>>
>> --
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>