Re: Custom Security / Permissions

[David E Jones]

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

-David

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

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.

Thanks to everyone for their input!

Andrew


On Jan 9, 2007, at 4:59 PM, Adrian Crum wrote:

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!

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,

Andrew

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.

My Original Example:
Object A wants to modify Object B.

Implementation:

    Object A is granted permission to modify Object B

Scenario 1:




Scenario 2:


Scenario 3:

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 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. I want to temporarily disable a service. I set the service's permissions to Invoke-able=false. 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.

smime.p7s
Description: S/MIME cryptographic signature