You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Andrew Zeneski <ja...@ofbiz.org> on 2007/01/06 05:13:56 UTC
Custom Security / Permissions
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
Re: Custom Security / Permissions
Posted by Adrian Crum <ad...@hlmksw.com>.
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
>
>
Re: Custom Security / Permissions
Posted by Andrew Zeneski <ja...@ofbiz.org>.
I guess I jumped the gun on this one, I looked at this code today and
realized that it would be impossible to implement in a simple method.
All the caching code is there and that's pretty darn important. I was
hoping to find a way to actually get rid of the security object in
many places to prevent its use (inside of services, simple methods,
FTL files, etc). However, maybe its fine to just leave as is, as an
alternative.
The actual idea was to replace the security object everywhere it was
used with a permission service. Laying out some base services to
handle the generic permissions. But now I realize this isn't practical.
Andrew
On Jan 10, 2007, at 2:31 PM, David E Jones wrote:
>
> On Jan 10, 2007, at 8:57 AM, Andrew Zeneski wrote:
>
>> Yes, however the example uses the built in permission checking in
>> the simple methods which in turn uses the Security Object. I still
>> think this Object needs to be deprecated and as a best practice
>> example this probably isn't good.
>
> What would it mean to deprecate the Security object? What would
> replace it everywhere it is used?
>
>> Since simple methods (other than permission checking methods)
>> won't need the check-permission any more, maybe this tag should be
>> deprecated as well? What do you think about this?
>
> Similar to above, what would replace the check-permission simple-
> method, especially in the permission services? Would you also like
> to get rid of the if-permission operation and condition?
>
>> I would like to throw in a simple method which checks base
>> permissions (like the security object does today). Maybe but this
>> method in 'common'? Or it could even live in the service
>> component, or security for that matter...
>
> Is this what would replace the Security object and the check-
> permission operation? How would it be different? How would it be
> better?
>
> I'd appreciate any details you could offer on your thoughts, I must
> admit I'm pretty completely lost trying to see where you're going
> with this one...
>
> -David
>
>
>> Then there will be a generic 'checkBasePermission' service which
>> can be used to replace the simple calls there today. What are your
>> thoughts on that?
>>
>> Andrew
>>
>> On Jan 10, 2007, at 12:51 AM, David E Jones wrote:
>>
>>>
>>> Looks good Andy, and there's even an example of how to use it!
>>>
>>> -David
>>>
>>>
>>> On Jan 9, 2007, at 10:35 PM, Andrew Zeneski wrote:
>>>
>>>> Based on the discussions from this thread as well as some
>>>> offline discussions, the new service based permission checking
>>>> is checked in.
>>>>
>>>> Examples of using this can be found in the example component.
>>>> One feature not yet documented yet is you can trigger an eca on
>>>> running a condition on hasPermission (boolean) and can either
>>>> add additional permission checks or do alternative permission
>>>> checking. This will be very handy!
>>>>
>>>> Thanks to everyone for their input!
>>>>
>>>> Andrew
>>>>
>>>>
>>>> On Jan 9, 2007, at 4:59 PM, Adrian Crum wrote:
>>>>
>>>>> Oh, oops. Yeah, Object = OFBiz element: user, record, service,
>>>>> etc.
>>>>>
>>>>>
>>>>> Andrew Zeneski wrote:
>>>>>
>>>>>> I agree, I think this is nice. I thought you were talking
>>>>>> about Java Objects however, so indeed I think the service
>>>>>> model will still fit this just fine.
>>>>>> Andrew
>>>>>> On Jan 9, 2007, at 3:57 PM, Adrian Crum wrote:
>>>>>>> Andrew Zeneski wrote:
>>>>>>>
>>>>>>>> Adrian,
>>>>>>>> Where do you see the need for an Object? So far what I have
>>>>>>>> heard is service based authentication and permissions will
>>>>>>>> cover everything, if you see otherwise please describe.
>>>>>>>> Andrew
>>>>>>>
>>>>>>>
>>>>>>> My Original 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 is granted permission to modify Object B
>>>>>>>
>>>>>>> Scenario 1:
>>>>>>> In our sales order program we have orders that are used as
>>>>>>> templates. Our orders are very complicated and detailed, and
>>>>>>> they take a lot of time to create. Using templates speeds
>>>>>>> things up considerably. Templates are copied to new orders
>>>>>>> and the new order is modified. The templates are seldom
>>>>>>> modified, and only by those who have permission to do so.
>>>>>>> Templates should not be deleted.
>>>>>>>
>>>>>>> I could add an order type called "TEMPLATE" and write custom
>>>>>>> code to control what actions can be performed on records
>>>>>>> that have that order type, OR using the security scheme
>>>>>>> mentioned above I could just set the template's permissions
>>>>>>> to Modify-able=false and Delete- able=false - the underlying
>>>>>>> security checking will do all of the work my custom code
>>>>>>> would have done.
>>>>>>>
>>>>>>> Scenario 2:
>>>>>>> I want to temporarily disable a service. I set the service's
>>>>>>> permissions to Invoke-able=false.
>>>>>>>
>>>>>>> Scenario 3:
>>>>>>> I'm the OFBiz administrator and I want to go on a vacation.
>>>>>>> I assign a co-worker to be the OFBiz administrator in my
>>>>>>> absence by giving him full admin permissions. Either
>>>>>>> accidentally or maliciously, the coworker deletes or
>>>>>>> disables the main admin user login while I'm gone.
>>>>>>>
>>>>>>> Using the security scheme mentioned above, I can set the
>>>>>>> main admin's permissions to Modify-able=false and Delete-
>>>>>>> able=false for anyone but the main admin.
>>>>>>>
>>>>>>> I could think of more. Assigning permissions to objects opens
>>>>>>> up many possibilities.
>>>>>>>
>>>>
>>>
>>
>
Re: Custom Security / Permissions
Posted by David E Jones <jo...@undersunconsulting.com>.
On Jan 10, 2007, at 8:57 AM, Andrew Zeneski wrote:
> Yes, however the example uses the built in permission checking in
> the simple methods which in turn uses the Security Object. I still
> think this Object needs to be deprecated and as a best practice
> example this probably isn't good.
What would it mean to deprecate the Security object? What would
replace it everywhere it is used?
> Since simple methods (other than permission checking methods) won't
> need the check-permission any more, maybe this tag should be
> deprecated as well? What do you think about this?
Similar to above, what would replace the check-permission simple-
method, especially in the permission services? Would you also like to
get rid of the if-permission operation and condition?
> I would like to throw in a simple method which checks base
> permissions (like the security object does today). Maybe but this
> method in 'common'? Or it could even live in the service component,
> or security for that matter...
Is this what would replace the Security object and the check-
permission operation? How would it be different? How would it be better?
I'd appreciate any details you could offer on your thoughts, I must
admit I'm pretty completely lost trying to see where you're going
with this one...
-David
> Then there will be a generic 'checkBasePermission' service which
> can be used to replace the simple calls there today. What are your
> thoughts on that?
>
> Andrew
>
> On Jan 10, 2007, at 12:51 AM, David E Jones wrote:
>
>>
>> Looks good Andy, and there's even an example of how to use it!
>>
>> -David
>>
>>
>> On Jan 9, 2007, at 10:35 PM, Andrew Zeneski wrote:
>>
>>> Based on the discussions from this thread as well as some offline
>>> discussions, the new service based permission checking is checked
>>> in.
>>>
>>> Examples of using this can be found in the example component. One
>>> feature not yet documented yet is you can trigger an eca on
>>> running a condition on hasPermission (boolean) and can either add
>>> additional permission checks or do alternative permission
>>> checking. This will be very handy!
>>>
>>> Thanks to everyone for their input!
>>>
>>> Andrew
>>>
>>>
>>> On Jan 9, 2007, at 4:59 PM, Adrian Crum wrote:
>>>
>>>> Oh, oops. Yeah, Object = OFBiz element: user, record, service, etc.
>>>>
>>>>
>>>> Andrew Zeneski wrote:
>>>>
>>>>> I agree, I think this is nice. I thought you were talking about
>>>>> Java Objects however, so indeed I think the service model will
>>>>> still fit this just fine.
>>>>> Andrew
>>>>> On Jan 9, 2007, at 3:57 PM, Adrian Crum wrote:
>>>>>> Andrew Zeneski wrote:
>>>>>>
>>>>>>> Adrian,
>>>>>>> Where do you see the need for an Object? So far what I have
>>>>>>> heard is service based authentication and permissions will
>>>>>>> cover everything, if you see otherwise please describe.
>>>>>>> Andrew
>>>>>>
>>>>>>
>>>>>> My Original 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 is granted permission to modify Object B
>>>>>>
>>>>>> Scenario 1:
>>>>>> In our sales order program we have orders that are used as
>>>>>> templates. Our orders are very complicated and detailed, and
>>>>>> they take a lot of time to create. Using templates speeds
>>>>>> things up considerably. Templates are copied to new orders
>>>>>> and the new order is modified. The templates are seldom
>>>>>> modified, and only by those who have permission to do so.
>>>>>> Templates should not be deleted.
>>>>>>
>>>>>> I could add an order type called "TEMPLATE" and write custom
>>>>>> code to control what actions can be performed on records that
>>>>>> have that order type, OR using the security scheme mentioned
>>>>>> above I could just set the template's permissions to Modify-
>>>>>> able=false and Delete- able=false - the underlying security
>>>>>> checking will do all of the work my custom code would have done.
>>>>>>
>>>>>> Scenario 2:
>>>>>> I want to temporarily disable a service. I set the service's
>>>>>> permissions to Invoke-able=false.
>>>>>>
>>>>>> Scenario 3:
>>>>>> I'm the OFBiz administrator and I want to go on a vacation. I
>>>>>> assign a co-worker to be the OFBiz administrator in my absence
>>>>>> by giving him full admin permissions. Either accidentally or
>>>>>> maliciously, the coworker deletes or disables the main admin
>>>>>> user login while I'm gone.
>>>>>>
>>>>>> Using the security scheme mentioned above, I can set the main
>>>>>> admin's permissions to Modify-able=false and Delete-able=false
>>>>>> for anyone but the main admin.
>>>>>>
>>>>>> I could think of more. Assigning permissions to objects opens
>>>>>> up many possibilities.
>>>>>>
>>>
>>
>
Re: Custom Security / Permissions
Posted by Andrew Zeneski <ja...@ofbiz.org>.
Yes, however the example uses the built in permission checking in the
simple methods which in turn uses the Security Object. I still think
this Object needs to be deprecated and as a best practice example
this probably isn't good.
Since simple methods (other than permission checking methods) won't
need the check-permission any more, maybe this tag should be
deprecated as well? What do you think about this?
I would like to throw in a simple method which checks base
permissions (like the security object does today). Maybe but this
method in 'common'? Or it could even live in the service component,
or security for that matter...
Then there will be a generic 'checkBasePermission' service which can
be used to replace the simple calls there today. What are your
thoughts on that?
Andrew
On Jan 10, 2007, at 12:51 AM, David E Jones wrote:
>
> Looks good Andy, and there's even an example of how to use it!
>
> -David
>
>
> On Jan 9, 2007, at 10:35 PM, Andrew Zeneski wrote:
>
>> Based on the discussions from this thread as well as some offline
>> discussions, the new service based permission checking is checked in.
>>
>> Examples of using this can be found in the example component. One
>> feature not yet documented yet is you can trigger an eca on
>> running a condition on hasPermission (boolean) and can either add
>> additional permission checks or do alternative permission
>> checking. This will be very handy!
>>
>> Thanks to everyone for their input!
>>
>> Andrew
>>
>>
>> On Jan 9, 2007, at 4:59 PM, Adrian Crum wrote:
>>
>>> Oh, oops. Yeah, Object = OFBiz element: user, record, service, etc.
>>>
>>>
>>> Andrew Zeneski wrote:
>>>
>>>> I agree, I think this is nice. I thought you were talking about
>>>> Java Objects however, so indeed I think the service model will
>>>> still fit this just fine.
>>>> Andrew
>>>> On Jan 9, 2007, at 3:57 PM, Adrian Crum wrote:
>>>>> Andrew Zeneski wrote:
>>>>>
>>>>>> Adrian,
>>>>>> Where do you see the need for an Object? So far what I have
>>>>>> heard is service based authentication and permissions will
>>>>>> cover everything, if you see otherwise please describe.
>>>>>> Andrew
>>>>>
>>>>>
>>>>> My Original 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 is granted permission to modify Object B
>>>>>
>>>>> Scenario 1:
>>>>> In our sales order program we have orders that are used as
>>>>> templates. Our orders are very complicated and detailed, and
>>>>> they take a lot of time to create. Using templates speeds
>>>>> things up considerably. Templates are copied to new orders and
>>>>> the new order is modified. The templates are seldom modified,
>>>>> and only by those who have permission to do so. Templates
>>>>> should not be deleted.
>>>>>
>>>>> I could add an order type called "TEMPLATE" and write custom
>>>>> code to control what actions can be performed on records that
>>>>> have that order type, OR using the security scheme mentioned
>>>>> above I could just set the template's permissions to Modify-
>>>>> able=false and Delete- able=false - the underlying security
>>>>> checking will do all of the work my custom code would have done.
>>>>>
>>>>> Scenario 2:
>>>>> I want to temporarily disable a service. I set the service's
>>>>> permissions to Invoke-able=false.
>>>>>
>>>>> Scenario 3:
>>>>> I'm the OFBiz administrator and I want to go on a vacation. I
>>>>> assign a co-worker to be the OFBiz administrator in my absence
>>>>> by giving him full admin permissions. Either accidentally or
>>>>> maliciously, the coworker deletes or disables the main admin
>>>>> user login while I'm gone.
>>>>>
>>>>> Using the security scheme mentioned above, I can set the main
>>>>> admin's permissions to Modify-able=false and Delete-able=false
>>>>> for anyone but the main admin.
>>>>>
>>>>> I could think of more. Assigning permissions to objects opens
>>>>> up many possibilities.
>>>>>
>>
>
Re: Custom Security / Permissions
Posted by David E Jones <jo...@undersunconsulting.com>.
Looks good Andy, and there's even an example of how to use it!
-David
On Jan 9, 2007, at 10:35 PM, Andrew Zeneski wrote:
> Based on the discussions from this thread as well as some offline
> discussions, the new service based permission checking is checked in.
>
> Examples of using this can be found in the example component. One
> feature not yet documented yet is you can trigger an eca on running
> a condition on hasPermission (boolean) and can either add
> additional permission checks or do alternative permission checking.
> This will be very handy!
>
> Thanks to everyone for their input!
>
> Andrew
>
>
> On Jan 9, 2007, at 4:59 PM, Adrian Crum wrote:
>
>> Oh, oops. Yeah, Object = OFBiz element: user, record, service, etc.
>>
>>
>> Andrew Zeneski wrote:
>>
>>> I agree, I think this is nice. I thought you were talking about
>>> Java Objects however, so indeed I think the service model will
>>> still fit this just fine.
>>> Andrew
>>> On Jan 9, 2007, at 3:57 PM, Adrian Crum wrote:
>>>> Andrew Zeneski wrote:
>>>>
>>>>> Adrian,
>>>>> Where do you see the need for an Object? So far what I have
>>>>> heard is service based authentication and permissions will
>>>>> cover everything, if you see otherwise please describe.
>>>>> Andrew
>>>>
>>>>
>>>> My Original 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 is granted permission to modify Object B
>>>>
>>>> Scenario 1:
>>>> In our sales order program we have orders that are used as
>>>> templates. Our orders are very complicated and detailed, and
>>>> they take a lot of time to create. Using templates speeds
>>>> things up considerably. Templates are copied to new orders and
>>>> the new order is modified. The templates are seldom modified,
>>>> and only by those who have permission to do so. Templates
>>>> should not be deleted.
>>>>
>>>> I could add an order type called "TEMPLATE" and write custom
>>>> code to control what actions can be performed on records that
>>>> have that order type, OR using the security scheme mentioned
>>>> above I could just set the template's permissions to Modify-
>>>> able=false and Delete- able=false - the underlying security
>>>> checking will do all of the work my custom code would have done.
>>>>
>>>> Scenario 2:
>>>> I want to temporarily disable a service. I set the service's
>>>> permissions to Invoke-able=false.
>>>>
>>>> Scenario 3:
>>>> I'm the OFBiz administrator and I want to go on a vacation. I
>>>> assign a co-worker to be the OFBiz administrator in my absence
>>>> by giving him full admin permissions. Either accidentally or
>>>> maliciously, the coworker deletes or disables the main admin
>>>> user login while I'm gone.
>>>>
>>>> Using the security scheme mentioned above, I can set the main
>>>> admin's permissions to Modify-able=false and Delete-able=false
>>>> for anyone but the main admin.
>>>>
>>>> I could think of more. Assigning permissions to objects opens
>>>> up many possibilities.
>>>>
>
Re: Custom Security / Permissions
Posted by Andrew Zeneski <ja...@ofbiz.org>.
Based on the discussions from this thread as well as some offline
discussions, the new service based permission checking is checked in.
Examples of using this can be found in the example component. One
feature not yet documented yet is you can trigger an eca on running a
condition on hasPermission (boolean) and can either add additional
permission checks or do alternative permission checking. This will be
very handy!
Thanks to everyone for their input!
Andrew
On Jan 9, 2007, at 4:59 PM, Adrian Crum wrote:
> Oh, oops. Yeah, Object = OFBiz element: user, record, service, etc.
>
>
> Andrew Zeneski wrote:
>
>> I agree, I think this is nice. I thought you were talking about
>> Java Objects however, so indeed I think the service model will
>> still fit this just fine.
>> Andrew
>> On Jan 9, 2007, at 3:57 PM, Adrian Crum wrote:
>>> Andrew Zeneski wrote:
>>>
>>>> Adrian,
>>>> Where do you see the need for an Object? So far what I have
>>>> heard is service based authentication and permissions will
>>>> cover everything, if you see otherwise please describe.
>>>> Andrew
>>>
>>>
>>> My Original 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 is granted permission to modify Object B
>>>
>>> Scenario 1:
>>> In our sales order program we have orders that are used as
>>> templates. Our orders are very complicated and detailed, and
>>> they take a lot of time to create. Using templates speeds things
>>> up considerably. Templates are copied to new orders and the new
>>> order is modified. The templates are seldom modified, and only
>>> by those who have permission to do so. Templates should not be
>>> deleted.
>>>
>>> I could add an order type called "TEMPLATE" and write custom
>>> code to control what actions can be performed on records that
>>> have that order type, OR using the security scheme mentioned
>>> above I could just set the template's permissions to Modify-
>>> able=false and Delete- able=false - the underlying security
>>> checking will do all of the work my custom code would have done.
>>>
>>> Scenario 2:
>>> I want to temporarily disable a service. I set the service's
>>> permissions to Invoke-able=false.
>>>
>>> Scenario 3:
>>> I'm the OFBiz administrator and I want to go on a vacation. I
>>> assign a co-worker to be the OFBiz administrator in my absence
>>> by giving him full admin permissions. Either accidentally or
>>> maliciously, the coworker deletes or disables the main admin
>>> user login while I'm gone.
>>>
>>> Using the security scheme mentioned above, I can set the main
>>> admin's permissions to Modify-able=false and Delete-able=false
>>> for anyone but the main admin.
>>>
>>> I could think of more. Assigning permissions to objects opens up
>>> many possibilities.
>>>
Re: Custom Security / Permissions
Posted by Adrian Crum <ad...@hlmksw.com>.
Oh, oops. Yeah, Object = OFBiz element: user, record, service, etc.
Andrew Zeneski wrote:
> I agree, I think this is nice. I thought you were talking about Java
> Objects however, so indeed I think the service model will still fit
> this just fine.
>
> Andrew
>
> On Jan 9, 2007, at 3:57 PM, Adrian Crum wrote:
>
>> Andrew Zeneski wrote:
>>
>>> Adrian,
>>> Where do you see the need for an Object? So far what I have heard
>>> is service based authentication and permissions will cover
>>> everything, if you see otherwise please describe.
>>> Andrew
>>
>>
>> My Original 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 is granted permission to modify Object B
>>
>> Scenario 1:
>> In our sales order program we have orders that are used as templates.
>> Our orders are very complicated and detailed, and they take a lot of
>> time to create. Using templates speeds things up considerably.
>> Templates are copied to new orders and the new order is modified. The
>> templates are seldom modified, and only by those who have permission
>> to do so. Templates should not be deleted.
>>
>> I could add an order type called "TEMPLATE" and write custom code to
>> control what actions can be performed on records that have that order
>> type, OR using the security scheme mentioned above I could just set
>> the template's permissions to Modify-able=false and Delete- able=false
>> - the underlying security checking will do all of the work my custom
>> code would have done.
>>
>> Scenario 2:
>> I want to temporarily disable a service. I set the service's
>> permissions to Invoke-able=false.
>>
>> Scenario 3:
>> I'm the OFBiz administrator and I want to go on a vacation. I assign
>> a co-worker to be the OFBiz administrator in my absence by giving him
>> full admin permissions. Either accidentally or maliciously, the
>> coworker deletes or disables the main admin user login while I'm gone.
>>
>> Using the security scheme mentioned above, I can set the main admin's
>> permissions to Modify-able=false and Delete-able=false for anyone but
>> the main admin.
>>
>> I could think of more. Assigning permissions to objects opens up many
>> possibilities.
>>
>
Re: Custom Security / Permissions
Posted by Andrew Zeneski <ja...@ofbiz.org>.
I agree, I think this is nice. I thought you were talking about Java
Objects however, so indeed I think the service model will still fit
this just fine.
Andrew
On Jan 9, 2007, at 3:57 PM, Adrian Crum wrote:
> Andrew Zeneski wrote:
>> Adrian,
>> Where do you see the need for an Object? So far what I have heard
>> is service based authentication and permissions will cover
>> everything, if you see otherwise please describe.
>> Andrew
>
> My Original 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 is granted permission to modify Object B
>
> Scenario 1:
> In our sales order program we have orders that are used as
> templates. Our orders are very complicated and detailed, and they
> take a lot of time to create. Using templates speeds things up
> considerably. Templates are copied to new orders and the new order
> is modified. The templates are seldom modified, and only by those
> who have permission to do so. Templates should not be deleted.
>
> I could add an order type called "TEMPLATE" and write custom code
> to control what actions can be performed on records that have that
> order type, OR using the security scheme mentioned above I could
> just set the template's permissions to Modify-able=false and Delete-
> able=false - the underlying security checking will do all of the
> work my custom code would have done.
>
> Scenario 2:
> I want to temporarily disable a service. I set the service's
> permissions to Invoke-able=false.
>
> Scenario 3:
> I'm the OFBiz administrator and I want to go on a vacation. I
> assign a co-worker to be the OFBiz administrator in my absence by
> giving him full admin permissions. Either accidentally or
> maliciously, the coworker deletes or disables the main admin user
> login while I'm gone.
>
> Using the security scheme mentioned above, I can set the main
> admin's permissions to Modify-able=false and Delete-able=false for
> anyone but the main admin.
>
> I could think of more. Assigning permissions to objects opens up
> many possibilities.
>
Re: Custom Security / Permissions
Posted by Adrian Crum <ad...@hlmksw.com>.
Andrew Zeneski wrote:
> Adrian,
>
> Where do you see the need for an Object? So far what I have heard is
> service based authentication and permissions will cover everything, if
> you see otherwise please describe.
>
> Andrew
My Original 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 is granted permission to modify Object B
Scenario 1:
In our sales order program we have orders that are used as templates. Our orders
are very complicated and detailed, and they take a lot of time to create. Using
templates speeds things up considerably. Templates are copied to new orders and
the new order is modified. The templates are seldom modified, and only by those
who have permission to do so. Templates should not be deleted.
I could add an order type called "TEMPLATE" and write custom code to control
what actions can be performed on records that have that order type, OR using the
security scheme mentioned above I could just set the template's permissions to
Modify-able=false and Delete-able=false - the underlying security checking will
do all of the work my custom code would have done.
Scenario 2:
I want to temporarily disable a service. I set the service's permissions to
Invoke-able=false.
Scenario 3:
I'm the OFBiz administrator and I want to go on a vacation. I assign a co-worker
to be the OFBiz administrator in my absence by giving him full admin
permissions. Either accidentally or maliciously, the coworker deletes or
disables the main admin user login while I'm gone.
Using the security scheme mentioned above, I can set the main admin's
permissions to Modify-able=false and Delete-able=false for anyone but the main
admin.
I could think of more. Assigning permissions to objects opens up many possibilities.
Re: Custom Security / Permissions
Posted by Andrew Zeneski <ja...@ofbiz.org>.
Adrian,
Where do you see the need for an Object? So far what I have heard is
service based authentication and permissions will cover everything,
if you see otherwise please describe.
Andrew
On Jan 9, 2007, at 3:11 PM, Adrian Crum wrote:
> 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.
>
>
Re: Custom Security / Permissions
Posted by Adrian Crum <ad...@hlmksw.com>.
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.
Re: Custom Security / Permissions
Posted by Andrew Zeneski <ja...@ofbiz.org>.
Maybe adding:
<condition-permission ...
To the service ECAs to trigger events based on permission would add
an additional layer of security when triggering events. If we go with
the bypass route, this may be necessary.
Andrew
On Jan 9, 2007, at 3:17 PM, Andrew Zeneski wrote:
> Yes Adrian I agree...
>
> I am thinking about the same types of processes. The createParty
> service for example is useless unless used with other services,
> createPerson or createPartyGroup. When creating these, its nice to
> say if the user has PARTYMGR_CREATE permission then all is good.
> However...
>
> I don't want to give users permission to just a person all the
> time. I want to createContact, this would create a person/party
> group, roles, and associate them w/ my account. If createPerson
> REQUIRED the low level permissions then it would make this
> impossible...
>
> Maybe the logic should be as follows:
>
> 1) Keep CRUD service level permissions (base permissions as is today)
> 2) Move all checking to the service invocation level (out of the
> implementation)
> 3) Inherit permissions from previous services:
> Example:
>
> Service A - createPerson - requires PARTYMGR_CREATE permission
> (defined in the service def)
> Service B - createContact - request custom permission scheme
> (defined in the service def)
> Service B invokes Service A, and bypasses its base security since
> the permission passed for Service B.
>
> This would still allow CRuD services to be called directly and used
> as they are today, but also give us the flexibility to bypass them
> as needed through new service definitions (groups/ecas).
>
> That said, ECAs would follow the same pattern. The action service
> permission checking would not be invoked (ever), same with service
> groups...
>
> Does this solve all problems?
>
> Andrew
>
> On Jan 9, 2007, at 3:06 PM, Adrian Crum wrote:
>
>> 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
>
Re: Custom Security / Permissions
Posted by David E Jones <jo...@undersunconsulting.com>.
Ummm... to be honest, this scares the _hell_ out of me (and goodness
knows there's plenty there to scare out)!
What this implies to me is a new service definition for each
variation on permissions that might be needed by a stock or custom
application. Once you have half a dozen service definitions for a
service implementation it will start to take some work to figure out
which one to use, and it will greatly increase the risk that you're
using the wrong one, that someone might change that one and create a
whole in your code, or that user level interactions will accidently
hit a code path with no permission checks at all. In other words,
this seems like it would be _very_ difficult to manage. Much to much
for my poor little head...
The whole point of having low-level CrUD services is to have a
central place to attach stuff that we always want applied, including
ECA rules, security auth and permission checks, and any constraints
in general related to the data elements involved.
I'd be much more comfortable with the pattern that has been around
for years, and that has been mentioned and described dozens of times
in the mailing lists and other places, namely the general and role-
limited permissions pattern.
The idea is that the permission checking code would allow multiple
permission paths for the user to access the service (or screen or
whatever). Some permissions, like most (but not all!) of the current
permissions in OOTB OFBiz, are general permissions that mean you can
perform the operation on any related record. Other permissions, the
"role limited" ones, allow for alternate scenarios and will usually
have additional conditions like requiring the logged in user's party
to be related to an existing record, or on create allow it but then
associate it with the user in a particular way.
This is super-important. I don't think we can really discuss
permission management without understanding this well at least from a
historical perspective, and I have yet to see any requirements that
don't fit right into this pattern. That includes what Adrian
described for his application, because even though I have no idea
what his custom security code looks like, I know that the custom code
could be associated with a role-limited permission just for it, and
then live happily along with other permissions for a given service or
screen or whatever.
A good example of existing code for this is the
ProductServices.xml#checkProductRelatedPermission simple-method
(starts on line 483 in the current revision of the file). Right now
it is called from each simple-method, but it should probably be
wrapped with a service definition and called as a service through the
service definition as a pre-condition.
To facilitate discussion I beg on bended knee that everyone read over
this, even if you think you know about what is in there! I find it an
extremely helpful to remind me of certain nuances related to this. It
may not be perfect code, but it's pretty good.
-David
On Jan 9, 2007, at 1:17 PM, Andrew Zeneski wrote:
> Yes Adrian I agree...
>
> I am thinking about the same types of processes. The createParty
> service for example is useless unless used with other services,
> createPerson or createPartyGroup. When creating these, its nice to
> say if the user has PARTYMGR_CREATE permission then all is good.
> However...
>
> I don't want to give users permission to just a person all the
> time. I want to createContact, this would create a person/party
> group, roles, and associate them w/ my account. If createPerson
> REQUIRED the low level permissions then it would make this
> impossible...
>
> Maybe the logic should be as follows:
>
> 1) Keep CRUD service level permissions (base permissions as is today)
> 2) Move all checking to the service invocation level (out of the
> implementation)
> 3) Inherit permissions from previous services:
> Example:
>
> Service A - createPerson - requires PARTYMGR_CREATE permission
> (defined in the service def)
> Service B - createContact - request custom permission scheme
> (defined in the service def)
> Service B invokes Service A, and bypasses its base security since
> the permission passed for Service B.
>
> This would still allow CRuD services to be called directly and used
> as they are today, but also give us the flexibility to bypass them
> as needed through new service definitions (groups/ecas).
>
> That said, ECAs would follow the same pattern. The action service
> permission checking would not be invoked (ever), same with service
> groups...
>
> Does this solve all problems?
>
> Andrew
>
> On Jan 9, 2007, at 3:06 PM, Adrian Crum wrote:
>
>> 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
>
Re: Custom Security / Permissions
Posted by Andrew Zeneski <ja...@ofbiz.org>.
Do you foresee this causing new problems? :)
On Jan 9, 2007, at 3:24 PM, Adrian Crum wrote:
> It certainly solves the one I described! Thanks Andy!
>
> Andrew Zeneski wrote:
>
>> Yes Adrian I agree...
>> I am thinking about the same types of processes. The createParty
>> service for example is useless unless used with other services,
>> createPerson or createPartyGroup. When creating these, its nice
>> to say if the user has PARTYMGR_CREATE permission then all is
>> good. However...
>> I don't want to give users permission to just a person all the
>> time. I want to createContact, this would create a person/party
>> group, roles, and associate them w/ my account. If createPerson
>> REQUIRED the low level permissions then it would make this
>> impossible...
>> Maybe the logic should be as follows:
>> 1) Keep CRUD service level permissions (base permissions as is today)
>> 2) Move all checking to the service invocation level (out of the
>> implementation)
>> 3) Inherit permissions from previous services:
>> Example:
>> Service A - createPerson - requires PARTYMGR_CREATE permission
>> (defined in the service def)
>> Service B - createContact - request custom permission scheme
>> (defined in the service def)
>> Service B invokes Service A, and bypasses its base security since
>> the permission passed for Service B.
>> This would still allow CRuD services to be called directly and
>> used as they are today, but also give us the flexibility to
>> bypass them as needed through new service definitions (groups/ecas).
>> That said, ECAs would follow the same pattern. The action service
>> permission checking would not be invoked (ever), same with
>> service groups...
>> Does this solve all problems?
>> Andrew
>> On Jan 9, 2007, at 3:06 PM, Adrian Crum wrote:
>>> 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
Re: Custom Security / Permissions
Posted by Adrian Crum <ad...@hlmksw.com>.
It certainly solves the one I described! Thanks Andy!
Andrew Zeneski wrote:
> Yes Adrian I agree...
>
> I am thinking about the same types of processes. The createParty
> service for example is useless unless used with other services,
> createPerson or createPartyGroup. When creating these, its nice to say
> if the user has PARTYMGR_CREATE permission then all is good. However...
>
> I don't want to give users permission to just a person all the time. I
> want to createContact, this would create a person/party group, roles,
> and associate them w/ my account. If createPerson REQUIRED the low
> level permissions then it would make this impossible...
>
> Maybe the logic should be as follows:
>
> 1) Keep CRUD service level permissions (base permissions as is today)
> 2) Move all checking to the service invocation level (out of the
> implementation)
> 3) Inherit permissions from previous services:
> Example:
>
> Service A - createPerson - requires PARTYMGR_CREATE permission (defined
> in the service def)
> Service B - createContact - request custom permission scheme (defined
> in the service def)
> Service B invokes Service A, and bypasses its base security since the
> permission passed for Service B.
>
> This would still allow CRuD services to be called directly and used as
> they are today, but also give us the flexibility to bypass them as
> needed through new service definitions (groups/ecas).
>
> That said, ECAs would follow the same pattern. The action service
> permission checking would not be invoked (ever), same with service
> groups...
>
> Does this solve all problems?
>
> Andrew
>
> On Jan 9, 2007, at 3:06 PM, Adrian Crum wrote:
>
>> 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
>
>
Re: Custom Security / Permissions
Posted by Andrew Zeneski <ja...@ofbiz.org>.
Yes Adrian I agree...
I am thinking about the same types of processes. The createParty
service for example is useless unless used with other services,
createPerson or createPartyGroup. When creating these, its nice to
say if the user has PARTYMGR_CREATE permission then all is good.
However...
I don't want to give users permission to just a person all the time.
I want to createContact, this would create a person/party group,
roles, and associate them w/ my account. If createPerson REQUIRED the
low level permissions then it would make this impossible...
Maybe the logic should be as follows:
1) Keep CRUD service level permissions (base permissions as is today)
2) Move all checking to the service invocation level (out of the
implementation)
3) Inherit permissions from previous services:
Example:
Service A - createPerson - requires PARTYMGR_CREATE permission
(defined in the service def)
Service B - createContact - request custom permission scheme (defined
in the service def)
Service B invokes Service A, and bypasses its base security since the
permission passed for Service B.
This would still allow CRuD services to be called directly and used
as they are today, but also give us the flexibility to bypass them as
needed through new service definitions (groups/ecas).
That said, ECAs would follow the same pattern. The action service
permission checking would not be invoked (ever), same with service
groups...
Does this solve all problems?
Andrew
On Jan 9, 2007, at 3:06 PM, Adrian Crum wrote:
> 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
Re: Custom Security / Permissions
Posted by Adrian Crum <ad...@hlmksw.com>.
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
>
Re: Custom Security / Permissions
Posted by Chris Howe <cj...@yahoo.com>.
--- David E Jones <jo...@undersunconsulting.com>
wrote:
>
> 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
>
>
I agree, it does seem conflicted. Perhaps it's because
of the way we think of the architecture. (or perhaps
it really is conflicted)
One example:
Call a service -> Invoke a simple method -> Check
permission in the method -> create,store, delete the
value
If you instead thought of "create, store, delete the
value" as themselves being services (simply using that
tag is a service call) then you could implement the
central permissions and work backwards, removing
redundant permission checks.
This may be one of those things that is easier with a
picture?
,Chris
Re: Custom Security / Permissions
Posted by David E Jones <jo...@undersunconsulting.com>.
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
Re: Custom Security / Permissions
Posted by Adrian Crum <ad...@hlmksw.com>.
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.
Re: Custom Security / Permissions
Posted by Andrew Zeneski <ja...@ofbiz.org>.
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 <an...@sykesdevelopment.com>
>> Sykes Development Ltd
>> http://www.sykesdevelopment.com
>>
>
Re: Custom Security / Permissions
Posted by David E Jones <jo...@undersunconsulting.com>.
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 <an...@sykesdevelopment.com>
> Sykes Development Ltd
> http://www.sykesdevelopment.com
>
Re: Custom Security / Permissions
Posted by Andrew Sykes <an...@sykesdevelopment.com>.
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 <an...@sykesdevelopment.com>
Sykes Development Ltd
http://www.sykesdevelopment.com
Re: Custom Security / Permissions
Posted by Andrew Zeneski <ja...@ofbiz.org>.
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
Re: Custom Security / Permissions
Posted by Adrian Crum <ad...@hlmksw.com>.
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.
Re: Custom Security / Permissions
Posted by Ean Schuessler <ea...@brainfood.com>.
On Tuesday 09 January 2007 09:12, 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
At this point I would like to pop in with a very basic criticism. I've always
been a little confused by the use of user credentials as opposed to parties
and, especially, the fact that the userLoginId is the primary key of the
credentials.
I can see why you want to track which credential was used to perform a
particular action and I can also see the argument that the whole party
management app shouldn't always be a requirement for an OFBiz install. What
doesn't make sense is that I can't do very basic things like have several
different authentication schemes (ie: LDAP, SMB, Radius, Kerberos) attached
to the same party with the same or varying userLoginId and same or different
passwords or other shared secrets. Its also very vexing that I can't have
duplicate userLoginIds for different parties in different authentication
contexts (ie. multihomed multicontext ecommerce widget or whatever).
I really would like to see userLogins separated by some sort of "realm" and
having their own IDs that are not the user identifier and potentially even
their own tables if the shared secret is complex (ie. retina print or
somethign). The base table could also specify an authenticating service call
(service engine style) on a per credential basis (with a default?). It would
be very nice, for instance, to integrate JPAM so that you could authenticate
your ofbiz users off of your Samba server and handle password changes through
it and so forth.
I'm thinking out loud a little here, obviously.
--
Ean Schuessler, CTO
ean@brainfood.com
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com
Re: Custom Security / Permissions
Posted by Andrew Zeneski <ja...@ofbiz.org>.
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
Re: Custom Security / Permissions
Posted by Adrian Crum <ad...@hlmksw.com>.
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
>
>
>
Re: Custom Security / Permissions
Posted by David E Jones <jo...@undersunconsulting.com>.
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
>
>
>
Re: Custom Security / Permissions
Posted by Andrew Zeneski <ja...@ofbiz.org>.
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
>
Re: Custom Security / Permissions
Posted by Jacopo Cappellato <ti...@sastau.it>.
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
>
>
>
Re: Custom Security / Permissions
Posted by Adrian Crum <ad...@hlmksw.com>.
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
>>>
>>>
>>>
Re: Custom Security / Permissions
Posted by Adrian Crum <ad...@hlmksw.com>.
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.
Re: Custom Security / Permissions
Posted by Andrew Sykes <an...@sykesdevelopment.com>.
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 <an...@sykesdevelopment.com>
Sykes Development Ltd
http://www.sykesdevelopment.com
Re: Custom Security / Permissions
Posted by Andrew Sykes <an...@sykesdevelopment.com>.
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 <an...@sykesdevelopment.com>
Sykes Development Ltd
http://www.sykesdevelopment.com