How to manage specific permissions for one resource?

[Mark]

Hi Pyramid experts,

I am developing an ERP solution on Pyramid using CouchDB (no RDBMS at
all !). All of the pages/resources in the system will have row-level
authorization setup. I will have a page that contains a matrix of all
the resources on the page as well as the Create, Read, Update and
delete checkboxes for each resource. The admin will be allowed to
check/uncheck the checkboxes to decide what kind of permissions the
person will have.

Scenario:

Supposing I give USER Timothy the EDITOR role which allows him to
UPDATE and READ all Brands in the system. However, because he is an
agent (like a salesperson) of France, He should be able to DELETE
Brands that originate from France (meaning that Brands have an
attribute that references a country). So if there were 4 Brands, B1
to B4, only B3 should be DELETABLE by Timothy because B3 originates
from France. Get the picture?

1. Does the above scenario mean that EVERY time a brand is created in
the system, I would have to generate for instance, "b1_create",
"b1_read" .... "b1_delete", "b2_create", "b2_read", "b2_update" ...
"b4_delete" permissions?

2. If the above is true, how would I dynamically assign the various
permissions to a view callable in Pyramid as part of the @view_config
OR does this mean I just have to handle that special case in the
application logic in my view?

Another example would be something like:

An agent of a company can make orders. However, he should only be
able to select the products (this means read permission right?) from
his country. If he is an agent of France, he can only make orders of
products that are only for France, not those in Germany or Holland.
How would the ACL for this work....?

Please let me know if this question needs improvement and I'll make
the necessary changes.

Thanks in advance!

Regards,
Mark Huang

[Michael Merickel]

On Tue, Mar 13, 2012 at 11:52 PM, Mark <zheng...@gmail.com> wrote:

1.  Does the above scenario mean that EVERY time a brand is created in
the system, I would have to generate for instance, "b1_create",
"b1_read" .... "b1_delete", "b2_create", "b2_read", "b2_update" ...
"b4_delete" permissions?

The way I would approach the problem is to have a "create", "read" and "delete" permissions. When accessing a context of type B, it would then supply an __acl__ which is dynamically generated based on its origins. For example:

@property

def __acl__(self):

    return [

        (Allow, 'editor', ('read', 'update')),

        (Allow, 'origin:' + self.origin, 'delete'),

    ]

With this, the object of type B has told us "who" is allowed to delete it. Now when Timothy accesses the system, it would be the responsibility of the authentication policy via the groupfinder to return a list of principals for Timothy. For example, Timothy is from france, so you would add the 'origin:france' principal, and he is an editor so you would add the 'editor' principal. Now when the auth system compares B's acl to timothy's principals, he will only have the delete permission if one of his principals matches up with one of the ACE's providing delete.

 

Another example would be something like:

An agent of a company can make orders.  However, he should only be
able to select the products (this means read permission right?) from
his country.  If he is an agent of France, he can only make orders of
products that are only for France, not those in Germany or Holland.
How would the ACL for this work....?

Again, look at it from the perspective of the context (the object of interest). That object (the product) should provide an ACL that tells the auth system what principals are allowed to use it. For example the product returns (Allow, 'agent_of_'+self.origin, 'read') where self is a product. The auth system then compares these acls with the principals returned by the authentication policy.

[Mark]

Thanks for your speedy reply. I need some time to experiment with
what you just said and to digest it a little. I'll let your know how
it goes. You are true expert in this field of Authn and Authz, thank
you so much for your help once again.

On Mar 14, 12:06 am, Michael Merickel <mmeri...@gmail.com> wrote:

[Mark]

Hi Michael,

Can I describe another likely situation? 

What if USER Timothy has the role of 'EDITOR' with read and update permissions on a specific resource, BUT....because of some condition, eg. if his sales is lesser than 100/month (let's call this attribute sales_per_month), he can only read and NOT update that resource.  How would this acl be?

@property
def __acl__(self):
  return [
      (Allow, 'editor', ('read', 'update'),
      (Deny, 'sales_lesser_than_100', 'update')
  ]

Should the deny be first in the list or should it be at the end?

[Michael Merickel]

The default "acl search" algorithm is to stop at the first entry (ace) that matches both the permission and a principal. So yeah, the Deny should be before the Allow in your example.

--

You received this message because you are subscribed to the Google Groups "pylons-discuss" group.

To view this discussion on the web visit https://groups.google.com/d/msg/pylons-discuss/-/mbA2i1_cOdMJ.

To post to this group, send email to pylons-...@googlegroups.com.
To unsubscribe from this group, send email to pylons-discus...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.