has anybody ever set up a site with a large number of roles? we're contemplating a security model for our app that might lead to ~ 100 Roles within a year, possibly thousands within the next 5 years. (Outline of the actual problem is at the end of this message) (The users and roles will be managed in LDAP, by the way; we plan to use LDAPUserFolder for this and not do any user or role administration in Zope.) I seem to recall the Zope Book or some other text advising against large numbers of roles, but IIRC that was only because of the UI. Obviously the ZMI default Security tab will not scale. I think I can replace that without too much trouble: possibly have the main page list only the roles vertically, with each one being a link to manage_roleForm as it is currently. As the number of roles grows very large this main page could be broken into batches if necessary. And of course there'd be a link to another page with a list of permissions to manage, and each of those would link to manage_permissionForm. i'm also thinking to use checkboxes as the current UI is too easy to unselect everything by accident. The question is, if I can solve the interface issues, are there other reasons not to have hundreds or thousands of roles? It seems to me that there should not be performance issues, since I assume that finding the current user's roles is just a dictionary lookup which should scale pretty well... we're not talking millions of roles here, and each user will have only a handful of roles. comments? more about our scenario: * We must anticipate users at hundreds of locations * there might be 10 or so users at each location * permissions can be grouped pretty well into tasks, but are specific to a location - permission to do a task at one location must not mean permission at all locations. To me this suggests several Roles per location, corresponding to the grouped tasks at that location. * each user might work from several different locations * each user might need different permissions when working at different locations * We have multiple applications, not all in zope, so LDAP is looking attractive. -- Paul Winkler http://www.slinkp.com
Paul Winkler wrote:
more about our scenario:
* We must anticipate users at hundreds of locations
* there might be 10 or so users at each location
* permissions can be grouped pretty well into tasks, but are specific to a location - permission to do a task at one location must not mean permission at all locations. To me this suggests several Roles per location, corresponding to the grouped tasks at that location.
* each user might work from several different locations
* each user might need different permissions when working at different locations
* We have multiple applications, not all in zope, so LDAP is looking attractive.
With locations, do you mean physical locations of the clients (i.e. IP-adresses), or the locations of objects inside zope (i.e. /department1, /department2 etc.)? cheers, oliver
On Sat, Feb 22, 2003 at 02:24:10PM +0100, Oliver Bleutgen wrote:
With locations, do you mean physical locations of the clients (i.e. IP-adresses), or the locations of objects inside zope (i.e. /department1, /department2 etc.)?
Both. Let's call them "sites" instead of locations, because they're physical sites: a discrete physical resource that our users need to manage. One user may have certain permissions at one of these sites, and different permissions at another. Unfortunately this is a required feature. It's also true that there may be specific content and applications in zope which correspond to a specific physical site, but not to the whole group of sites. and that's why zope needs to be involved with such a complex security model. example: Three physical sites, 1 2 and 3. Three tasks, X Y and Z. task X involves reading some class of data. task Y involves reading some other class of data. task Z involves writing some class of data. Two users, A and B. User A working at site 1 performs tasks X and Y. User A working at site 2 performs tasks Y and Z. User A working at site 3 cannot do anything. User B working at site 1 cannot do anything. User B working at site 2 performs task X. User B working at site 3 performs tasks X, Y, and Z. The solution we are considering is to have one role per site per task. If we were to name the roles after the site and task identifiers, we'd end up with something like: User A has roles 1X, 1Y, 2Y, 2Z User B has roles 2X, 3X, 3Y, 3Z ... but this obviously leads to an explosion of roles. e.g. 10 tasks * 200 sites = 2000 roles. Hence my original question. :) Bear in mind that we do not intend to do any of the user or role management in Zope; that would all be done in LDAP, and it would be officially Not My Problem. ;-) So "all" I'd need to do in Zope would be to assign permissions on particular folders to one or more of these 2000-some roles. So I'd need to write a security UI for the ZMI that can handle this well, because the default one cannot. We've also discussed the possibility of making this modified zope security UI available publically, if there is community interest. Does anybody actually like the one huge security grid? Try adding a couple roles to a CMF site and it already gets a bit unwieldy... The other possibility I've considered is a custom UserFolder which assigns the user's roles dynamically depending on what physical site they are working on (which we can always find out). This seems less bulky - many fewer roles from Zope's perspective - but i'm concerned about introducing security bugs that might go unnoticed, and I've never written a UserFolder so I don't know how long it would take. And I'm worried about session issues - if user A is doing some remote work for site 1 and then switches to site 2, would all of his roles be updated immediately and correctly? And we may need to allow a user to work on two sites *simultaneously* which would not be possible in this model. -- Paul Winkler www.slinkp.com
Paul Winkler wrote:
On Sat, Feb 22, 2003 at 02:24:10PM +0100, Oliver Bleutgen wrote:
With locations, do you mean physical locations of the clients (i.e. IP-adresses), or the locations of objects inside zope (i.e. /department1, /department2 etc.)?
Both. Let's call them "sites" instead of locations, because they're physical sites: a discrete physical resource that our users need to manage. One user may have certain permissions at one of these sites, and different permissions at another. Unfortunately this is a required feature
It's also true that there may be specific content and applications in zope which correspond to a specific physical site, but not to the whole group of sites. and that's why zope needs to be involved with such a complex security model.
From that I gather that your "sites" don't map 1:1 to objects into zope, so that you cannot use local roles for that, right? E.g, there are methods like doTaskX(location,...), where the permission to execute that method depend on location, and location is not an object inside zope.
[example snipped]
The solution we are considering is to have one role per site per task. If we were to name the roles after the site and task identifiers, we'd end up with something like:
User A has roles 1X, 1Y, 2Y, 2Z User B has roles 2X, 3X, 3Y, 3Z
... but this obviously leads to an explosion of roles. e.g. 10 tasks * 200 sites = 2000 roles. Hence my original question. :) [...] The other possibility I've considered is a custom UserFolder which assigns the user's roles dynamically depending on what physical site they are working on (which we can always find out). This seems less bulky - many fewer roles from Zope's perspective - but i'm concerned about introducing security bugs that might go unnoticed, and I've never written a UserFolder so I don't know how long it would take.
There's a nice "template" for userfolder from ChrisW: http://www.zope.org/Members/NIP/SimpleUserFolder
And I'm worried about session issues - if user A is doing some remote work for site 1 and then switches to site 2, would all of his roles be updated immediately and correctly? And we may need to allow a user to work on two sites *simultaneously* which would not be possible in this model.
Well, for me roles are just a simplification/optimization for getting permissions of a user (for an object) for the sake of easier management. From the mapping user_id -> set of permissions, we go to user_id -> set of roles -> set of permissions, where the last mapping is defined by mappings of the form role -> set of permissions. This works, because for typical situations, you just need to define a handful of roles. Since your application might not be suited for that scheme, it might be worth throwing out roles altogether. How about creating a role for each user (i.e. user "user_id" get's just the role "user_id", instead of creating a role for for each possible (task,location) tuple. When creating a new user, the admin would have to just assign the permissions, instead of roles. This task could be made easier by creating template permission sets. You might wind up with less roles and I bet administration is a lot easier. cheers, oliver
On Mon, Feb 24, 2003 at 12:41:01PM +0100, Oliver Bleutgen wrote:
From that I gather that your "sites" don't map 1:1 to objects into zope, so that you cannot use local roles for that, right? E.g, there are methods like doTaskX(location,...), where the permission to execute that method depend on location, and location is not an object inside zope.
That is correct.
Well, for me roles are just a simplification/optimization for getting permissions of a user (for an object) for the sake of easier management. From the mapping user_id -> set of permissions, we go to user_id -> set of roles -> set of permissions, where the last mapping is defined by mappings of the form role -> set of permissions. This works, because for typical situations, you just need to define a handful of roles.
i'm with you so far...
Since your application might not be suited for that scheme, it might be worth throwing out roles altogether. How about creating a role for each user (i.e. user "user_id" get's just the role "user_id", instead of creating a role for for each possible (task,location) tuple. When creating a new user, the admin would have to just assign the permissions, instead of roles. This task could be made easier by creating template permission sets.
Interesting idea... tell me if I'm wrong, but I see two obvious problems with this approach: 1) for one-role-per-user: we'd have to visit the security management for N objects in Zope and adjust the permissions every time we add a user. Whereas in my proposal, we only need to do that every time we add a site or change the tasks, which happens much less frequently. 2) for one-role-per-user, changing a user's privileges means wanding around the ZMI setting permissions on N objects. Whereas in my scheme, we can do that in one place (LDAP) by adding or removing a role or two.
You might wind up with less roles and I bet administration is a lot easier.
my guess is that in our case, the number of roles would be comparable. 200 sites * 10 tasks = 2000 roles 200 sites * 10 users = 2000 roles -- Paul Winkler http://www.slinkp.com
Paul Winkler wrote:
On Mon, Feb 24, 2003 at 12:41:01PM +0100, Oliver Bleutgen wrote:
Since your application might not be suited for that scheme, it might be worth throwing out roles altogether. How about creating a role for each user (i.e. user "user_id" get's just the role "user_id", instead of creating a role for for each possible (task,location) tuple. When creating a new user, the admin would have to just assign the permissions, instead of roles. This task could be made easier by creating template permission sets.
Interesting idea... tell me if I'm wrong, but I see two obvious problems with this approach:
1) for one-role-per-user: we'd have to visit the security management for N objects in Zope and adjust the permissions every time we add a user. Whereas in my proposal, we only need to do that every time we add a site or change the tasks, which happens much less frequently.
2) for one-role-per-user, changing a user's privileges means wanding around the ZMI setting permissions on N objects. Whereas in my scheme, we can do that in one place (LDAP) by adding or removing a role or two.
You might wind up with less roles and I bet administration is a lot easier.
my guess is that in our case, the number of roles would be comparable. 200 sites * 10 tasks = 2000 roles 200 sites * 10 users = 2000 roles
I think I still don't get all the characteristics of you application. So I'll try to post what I had in mind: - implement a kind of permission matrix: "tasks"x"sites",i.e. permission 1X says that the user who has this permission is allowed to call taskX(site=1,...). Then in taskX you could check if the user has the permission 1X, and otherwise throw an exception. - write an UI which hides the existance of roles, instead let the admin assign permissions directly to users (by implictly creating one role named user_id with all the permissions the admin choose). Optionally give the admin some knobs to use "permission templates" or other helpers. Note that this could still be combined with "normal" roles for everything which has nothing to do with your "sites". So I don't see why your point 1) and 2) could be an issue, unless you also need stuff like local roles for other things etc. - but that seems to be solvable through an UI too. Then you'd have sites*tasks permissions, and as many roles as you have users. And maybe you steered around the complexity problem w.r.t roles too. cheers, oliver
Paul Winkler wrote at 2003-2-21 16:28 -0500:
has anybody ever set up a site with a large number of roles? we're contemplating a security model for our app that might lead to ~ 100 Roles within a year, possibly thousands within the next 5 years. (Outline of the actual problem is at the end of this message)
I think (not sure, though) that Zope has the following time complexity for permission checking: If a user has "u" roles and a permission is allowed for "a" roles, then Zope checks for each of the "u" roles whether it is in the list of "a" roles. The complexity is "u * a" whith can be too high for large "u" and "a". It is easy to optimize this to "u + a" (via a dictionary), then thousands of roles should not be a problem. Dieter
On Sun, Feb 23, 2003 at 09:02:24PM +0100, Dieter Maurer wrote:
I think (not sure, though) that Zope has the following time complexity for permission checking:
If a user has "u" roles and a permission is allowed for "a" roles, then Zope checks for each of the "u" roles whether it is in the list of "a" roles.
That's correct, I just found this in lib/python/AccessControl/User.py, in the definition of "allowed": user_roles = self.getRoles() for role in object_roles: if role in user_roles: if self._check_context(object): return 1 return None (_check_context ensures that the object is not acquired from some other context where this user doesn't exist.)
The complexity is "u * a" whith can be too high for large "u" and "a".
Indeed... and object_roles seems likely to be bigger than user_roles (in general, but drastically moreso in my scenario). which means that it's quite likely we'd iterate for quite some time before findign a match.
It is easy to optimize this to "u + a" (via a dictionary), then thousands of roles should not be a problem.
would that mean you have to build a (potentially huge) dictionary every time? I'd greatly appreciate it if you could expand on this suggestion. Thanks! -- Paul Winkler http://www.slinkp.com
Paul Winkler wrote at 2003-2-24 16:27 -0500:
...
It is easy to optimize this to "u + a" (via a dictionary), then thousands of roles should not be a problem.
would that mean you have to build a (potentially huge) dictionary every time? I'd greatly appreciate it if you could expand on this suggestion.
Even when you create the dictionary anew each time, it will have (almost) "u+a" complexity. However, the dict might be cachable in volatile variables (i.e. "_v_" variables). As it is not my problem, I am a bit reluctant to search for optimazation possibilities. Dieter
On Tue, Feb 25, 2003 at 11:33:54PM +0100, Dieter Maurer wrote:
Paul Winkler wrote at 2003-2-24 16:27 -0500:
...
It is easy to optimize this to "u + a" (via a dictionary), then thousands of roles should not be a problem.
would that mean you have to build a (potentially huge) dictionary every time? I'd greatly appreciate it if you could expand on this suggestion.
Even when you create the dictionary anew each time, it will have (almost) "u+a" complexity.
However, the dict might be cachable in volatile variables (i.e. "_v_" variables).
good idea, thanks.
As it is not my problem, I am a bit reluctant to search for optimazation possibilities.
understandable... for anyone else who's interested, i just found this by Alex Martelli: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52303 -- Paul Winkler http://www.slinkp.com
I don't think a multitude of roles is the way to go. The way your problem sounds, you need users being allowed/forbiden to do certain tasks depending on which part of the site they are. This is what local-roles are for: parameterizing the permissions of a user based on the location of the objects inside Zope. However you do mention that you need to manage this centrally, especially since this information won't be used by Zope alone (and even if it was, you need centralized administration of these local roles, something that Zope doesn't give you, unless you consider Zope "central" :-), which I think you don't, because you consider LDAP "central". Is this correct?). So I think you need dynamically calculated local roles. This can be achieved by a user folder that returns a user object that overrides ".getRolesInContext(object)" to take the location (or any other attribute, such as an acquired "site") of "object" and check it against your central authorization source (eg. LDAP). exUserFolder has had modifications to allow construction of authentication sources that override user.getRolesInContext, but none of its default auth sources use this so far. Hope I made some sense :-) Cheers, Leo On Fri, 2003-02-21 at 18:28, Paul Winkler wrote:
has anybody ever set up a site with a large number of roles? we're contemplating a security model for our app that might lead to ~ 100 Roles within a year, possibly thousands within the next 5 years. (Outline of the actual problem is at the end of this message)
(The users and roles will be managed in LDAP, by the way; we plan to use LDAPUserFolder for this and not do any user or role administration in Zope.)
I seem to recall the Zope Book or some other text advising against large numbers of roles, but IIRC that was only because of the UI. Obviously the ZMI default Security tab will not scale. I think I can replace that without too much trouble: possibly have the main page list only the roles vertically, with each one being a link to manage_roleForm as it is currently. As the number of roles grows very large this main page could be broken into batches if necessary. And of course there'd be a link to another page with a list of permissions to manage, and each of those would link to manage_permissionForm. i'm also thinking to use checkboxes as the current UI is too easy to unselect everything by accident.
The question is, if I can solve the interface issues, are there other reasons not to have hundreds or thousands of roles? It seems to me that there should not be performance issues, since I assume that finding the current user's roles is just a dictionary lookup which should scale pretty well... we're not talking millions of roles here, and each user will have only a handful of roles.
comments?
more about our scenario:
* We must anticipate users at hundreds of locations
* there might be 10 or so users at each location
* permissions can be grouped pretty well into tasks, but are specific to a location - permission to do a task at one location must not mean permission at all locations. To me this suggests several Roles per location, corresponding to the grouped tasks at that location.
* each user might work from several different locations
* each user might need different permissions when working at different locations
* We have multiple applications, not all in zope, so LDAP is looking attractive.
--
Paul Winkler http://www.slinkp.com
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
-- Ideas don't stay in some minds very long because they don't like solitary confinement.
On Mon, Feb 24, 2003 at 07:18:21PM -0300, Leonardo Rochael Almeida wrote:
I don't think a multitude of roles is the way to go. The way your problem sounds, you need users being allowed/forbiden to do certain tasks depending on which part of the site they are. This is what local-roles are for: parameterizing the permissions of a user based on the location of the objects inside Zope.
Yes, except that Oliver hit the nail on the head when he said: """From that I gather that your "sites" don't map 1:1 to objects into zope, so that you cannot use local roles for that, right? E.g, there are methods like doTaskX(location,...), where the permission to execute that method depend on location, and location is not an object inside zope. """
However you do mention that you need to manage this centrally, especially since this information won't be used by Zope alone (and even if it was, you need centralized administration of these local roles, something that Zope doesn't give you, unless you consider Zope "central" :-), which I think you don't, because you consider LDAP "central". Is this correct?).
yes.
So I think you need dynamically calculated local roles. This can be achieved by a user folder that returns a user object that overrides ".getRolesInContext(object)" to take the location (or any other attribute, such as an acquired "site") of "object" and check it against your central authorization source (eg. LDAP).
hmmm... now i'm leaning back this way again. some quick testing with a large number of roles (10,000 added via a ZEO debug session) reveals that performance does indeed suck with that many roles. i could pursue the optimization that Dieter suggested but i'm no longer sure that I want to; the "lots of roles" idea was a lot more attractive when I thought it would be only a UI issue. Instead it looks like I'd have to make substantial changes in lib/python/AccessControl and there's a few more thousand lines of code in there which I haven't even looked at yet.
exUserFolder has had modifications to allow construction of authentication sources that override user.getRolesInContext, but none of its default auth sources use this so far.
Hope I made some sense :-)
I think so. This stuff makes my head hurt. :) -- Paul Winkler http://www.slinkp.com
On Mon, 2003-02-24 at 19:07, Paul Winkler wrote:
On Mon, Feb 24, 2003 at 07:18:21PM -0300, Leonardo Rochael Almeida wrote:
I don't think a multitude of roles is the way to go. The way your problem sounds, you need users being allowed/forbiden to do certain tasks depending on which part of the site they are. This is what local-roles are for: parameterizing the permissions of a user based on the location of the objects inside Zope.
Yes, except that Oliver hit the nail on the head when he said:
"""From that I gather that your "sites" don't map 1:1 to objects into zope, so that you cannot use local roles for that, right? E.g, there are methods like doTaskX(location,...), where the permission to execute that method depend on location, and location is not an object inside zope. """
Yes, but .getRolesInContext still gives you everything you need to know: The user object (and everything your user folder puts in there, which could include request data, such as the originating IP and time of login) and the object, including it's location and any other data you can acquire from it.
[...]
So I think you need dynamically calculated local roles. This can be achieved by a user folder that returns a user object that overrides ".getRolesInContext(object)" to take the location (or any other attribute, such as an acquired "site") of "object" and check it against your central authorization source (eg. LDAP).
hmmm... now i'm leaning back this way again. some quick testing with a large number of roles (10,000 added via a ZEO debug session) reveals that performance does indeed suck with that many roles. i could pursue the optimization that Dieter suggested but i'm no longer sure that I want to; the "lots of roles" idea was a lot more attractive when I thought it would be only a UI issue. Instead it looks like I'd have to make substantial changes in lib/python/AccessControl and there's a few more thousand lines of code in there which I haven't even looked at yet.
Yes. I do believe .getRolesInContex was put there to support this kind of customization. As I said in posts past, local-roles should have a more central role in the documentation, and that includes development documentation, such as local-role customization
[...]
Hope I made some sense :-)
I think so. This stuff makes my head hurt. :)
I feel your pain :-) Cheers, Leo -- Ideas don't stay in some minds very long because they don't like solitary confinement.
Leonardo Rochael Almeida <leo@hiper.com.br> wrote:
So I think you need dynamically calculated local roles. This can be achieved by a user folder that returns a user object that overrides ".getRolesInContext(object)" to take the location (or any other attribute, such as an acquired "site") of "object" and check it against your central authorization source (eg. LDAP).
Note that you'll also want to change validate() if you go that route. It has a short-circuited version of getRolesInContext in it. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:fg@nuxeo.com
On Tue, Feb 25, 2003 at 06:33:16PM +0000, Florent Guillaume wrote:
Leonardo Rochael Almeida <leo@hiper.com.br> wrote:
So I think you need dynamically calculated local roles. This can be achieved by a user folder that returns a user object that overrides ".getRolesInContext(object)" to take the location (or any other attribute, such as an acquired "site") of "object" and check it against your central authorization source (eg. LDAP).
Note that you'll also want to change validate() if you go that route. It has a short-circuited version of getRolesInContext in it.
I'm now looking into doing this... and i haven't found what you mean. there are a bunch of validates() in various modules in AccessControl, which are you talking about? ]$ grep "def validate(" * 2> /dev/null AuthEncoding.py: def validate(reference, attempt): AuthEncoding.py: def validate(self, reference, attempt): AuthEncoding.py: def validate(self, reference, attempt): AuthEncoding.py: def validate(self, reference, attempt): SecurityManager.py: def validate(self, accessed=None, container=None, name=None, value=None, User.py: def validate(self, request, auth='', roles=_noroles): User.py: def validate(self, request, auth='', roles=_noroles): ZopeSecurityPolicy.py: def validate(self, accessed, container, name, value, context, cAccessControl.c: /*| def validate(self, accessed, container, name, value, context are you sure it's not BasicUser.allowed() that you mean? there's a comment in there about checking roles manaully rather than with getRolesInContext... -- Paul Winkler http://www.slinkp.com
OK, now I am really confused. Please Help! I've been trying to understand how to implement dynamic local roles, and this has got me into trying to understand how authorization works. Brief background from the "Lots of roles" discussion:
Leonardo Rochael Almeida <leo@hiper.com.br> wrote:
So I think you need dynamically calculated local roles. This can be achieved by a user folder that returns a user object that overrides ".getRolesInContext(object)" (snip)
OK, that much is pretty easy, I've got a proof of concept based on SimpleUserFolder which works fine AFAICT. but then...
Florent Guillaume wrote:
Note that you'll also want to change validate() if you go that route. It has a short-circuited version of getRolesInContext in it.
The same thing was mentioned to me on #zope by Kosh. In addition, Chris Withers mentioned validate() in a private email in regard to dynamic local roles. So there's some consensus that this is what I need to do. But AFAICT this is just not true. Looking around in lib/python/AccessControl I observe that: (PLEASE correct me if anything below is wrong!!!!) * User.BasicUser.allowed() is the only method that "has a short-circuited version of getRolesInContext in it" * There are lots of "validate" methods, related as follows: BasicUserFolder.validate() calls self.authorize() which calls SecurityManager.validate() which calls ZopeSecurityPolicy.validate() which calls BasicUser.allowed() ... so I'm back where I started. AFAICT, none of these validate() methods do anything with roles, it's left up to .allowed() to figure out the roles. * Some logging experimentation confirms that my UserFolder.validate() is called EVERY time an object deeper in the zope object tree is accessed; often it just returns None thereby bubbling up the validation to higher user folders. This makes sense. * Also on Kosh's advice I looked at ZPublisher.BaseRequest.traverse() which seems to be the thing that kicks off the whole validation process. Skipping to the "# Do authorization checks" comment, it seems i'm looking in the right place. Ugh, this is possibly the snarliest method I've ever seen in python source. - __allow_groups__?? what the heck is this? what kind of groups are these? the only places i can find __allow_groups are in OFS/Application.py where it's used to refer to an emergency UserFolder (in case you delete your top-level acl_users), and in User.py where it refers to self of BasicUserFolder ... is this odd name possibly a bit of old bobo cruft? - after the allow_groups weirdness I think we've got hold of a UserFolder's validate method, which is our entry point into the authenticate / authorize process. One more thing: AFAICT, ZopeSecurityPolicy.checkPermission() and User.has_permission() are purely for informational purposes - e.g. you can call them in your app to find out something, but they are not used by the internals to grant or deny access. True? If anybody could confirm or deny any of teh above it would really help me grok what i'm doing here. -- Paul Winkler http://www.slinkp.com
On March 5, Paul Winkler wrote:
I've been trying to understand how to implement dynamic local roles,
Customise the Folder class and override __ac_local_roles__ with a method that returns a dictionary mapping users to roles for that object: {user: [local,roles], ...}
* User.BasicUser.allowed() is the only method that "has a short-circuited version of getRolesInContext in it"
This is correct. But if you implement dynamic local roles per above, you don't need to do this. You were right in an earlier post when you said that when people said validate() they meant allowed(). (This is what happens when you don't have well-defined naming standards!)
which calls ZopeSecurityPolicy.validate()
This does the work of validating access to object *after* the object has been allowed(). ie, to figure out permissions on callables to avoid a trojan attack. This is not the validate() you are looking for.
One more thing: AFAICT, ZopeSecurityPolicy.checkPermission() and User.has_permission() are purely for informational purposes - e.g. you can call them in your app to find out something, but they are not used by the internals to grant or deny access. True?
True. a. -- Adrian van den Dries adriand@flow.com.au Development team www.dev.flow.com.au FLOW Communications Pty. Ltd. www.flow.com.au
On Thu, Mar 06, 2003 at 09:19:37AM +1100, Adrian van den Dries wrote:
On March 5, Paul Winkler wrote:
I've been trying to understand how to implement dynamic local roles,
Customise the Folder class and override __ac_local_roles__ with a method that returns a dictionary mapping users to roles for that object:
{user: [local,roles], ...}
well, that's appealingly simple :) but I have doubts: * more coupling - since i'm going to have to get the users from the external source too (LDAP in this case), i then have 2 classes (the UserFolder and the Folder) that have to know about the external source. * performance hit - along with the previous concern, i now always have to do 2 queries of the external source: one for the userfolder to get the user, one for this Folder to look up the roles. I don't know if I care about this one... * one more detail to pay attention to during normal zope admin work - This is a real problem, as we're going to have a large amount of stuff protected this way and it's going to grow all the time. AFAICT I'd have to use this customized Folder instead of normal Folders for every place where i want to keep content that I store this way, because *everything* under the special Folder acquires the same local role. Why? Because at the time that the Folder gets asked for its local roles, it doesn't know what the leaf object was. This also means that I can't use other Folderish things e.g. LocalFS and generate varying local roles for its contained items. OTOH, doing the magic in user.allowed() would mean I'd only need one "special" UserFolder instance at the top of the hierarchy, and then everything else Just Works regardless of what folderish thing it is and all my LDAP-related code would be in this UserFolder class. am i overlooking something?
* User.BasicUser.allowed() is the only method that "has a short-circuited version of getRolesInContext in it"
This is correct.
thanks.
which calls ZopeSecurityPolicy.validate()
This does the work of validating access to object *after* the object has been allowed(). ie, to figure out permissions on callables to avoid a trojan attack. This is not the validate() you are looking for.
"You don't need to see his identification... he can go about his business... move along" :)
One more thing: AFAICT, ZopeSecurityPolicy.checkPermission() and User.has_permission() are purely for informational purposes - e.g. you can call them in your app to find out something, but they are not used by the internals to grant or deny access. True?
True.
thanks. -- Paul Winkler http://www.slinkp.com
Caveat: a) I haven't followed the discussion closely and I haven't used this in Zopes better than 2.4.x and (I think) 2.5.0, so I am not aware of any API Changes in 2.6x b) The way I did it is more or less crude. You may want to add to Zope's own local Roles rather than just crudely replace them. Using XUF as an intermediary, what I did was to hi-jack the User-objects getRoles method and feeding it with the results of a query. Similarely for getRolesInContext, which is what believe feeds the particular Object's local roles. I have just had a quick looked at the source for Zope 2.5 (cvs) and the API seems to be the same You ought to be able to do the same for SUF's User Object (either it is possible OOTB with SUF otu you can just modify SUF for this). The validate method you want is the one from the User object I believe, if you keep it user-centric - I haven't used the other validates that you list. In Zope the Userclass that is actually used is User User.py in lib/python/AcessControl/User.py It subclasses all other User-classes (SimpleUser and indirectly thru it BasicUser). XUF replaces User with it's own User class. anyway , I hope this helps you somewhat. Sincerly, /dario ----- Original Message ----- From: "Paul Winkler" <pw_lists@slinkp.com> To: <zope-dev@zope.org> Cc: "Paul Winkler" <pw_lists@slinkp.com> Sent: Thursday, March 06, 2003 1:09 AM Subject: Re: Security internals, was Re: [Zope-dev] LOTS of roles?
On Thu, Mar 06, 2003 at 09:19:37AM +1100, Adrian van den Dries wrote:
On March 5, Paul Winkler wrote:
I've been trying to understand how to implement dynamic local roles,
On March 5, Paul Winkler wrote:
* more coupling
Yes.
* performance hit
Yes.
* one more detail to pay attention to
Yes.
OTOH, doing the magic in user.allowed() would mean I'd only need one "special" UserFolder instance at the top of the hierarchy, and then everything else Just Works regardless of what folderish thing it is and all my LDAP-related code would be in this UserFolder class.
am i overlooking something?
No, I think you've distilled the issue quite concisely. (/me revisits LDAPUserFolder) Looks like the work is already done for you anyway: allowed() and friends check if the context has an attribute acl_satellite, and queries it for any additional roles, and it even keeps a cache. You could probably just customise the Folder to automagically place a satellite object in it. Or otherwise borrow the logic to do what you need. Huzzah open-source software! a. -- Adrian van den Dries adriand@flow.com.au Development team www.dev.flow.com.au FLOW Communications Pty. Ltd. www.flow.com.au
On Fri, Mar 07, 2003 at 08:56:59AM +1100, Adrian van den Dries wrote:
(/me revisits LDAPUserFolder)
Looks like the work is already done for you anyway: allowed() and friends check if the context has an attribute acl_satellite, and queries it for any additional roles, and it even keeps a cache.
!!!!!!!!!! OMG !!!!!!!!!!! thank you - for some obscure reason it never would have occurred to me in a million years that LDAPUserFolder already does this. Well, duh.
Huzzah open-source software!
Amen! -- Paul Winkler http://www.slinkp.com
hm... i could have told you that the LDAPUser class in the LDAPUserFolder product can do that but i had the whole thread mostly tuned out. initially it did not look like anything i could help with and the first posting was very long if i remember correctly. jens On Thursday, Mar 6, 2003, at 17:13 US/Eastern, Paul Winkler wrote:
On Fri, Mar 07, 2003 at 08:56:59AM +1100, Adrian van den Dries wrote:
(/me revisits LDAPUserFolder)
Looks like the work is already done for you anyway: allowed() and friends check if the context has an attribute acl_satellite, and queries it for any additional roles, and it even keeps a cache.
!!!!!!!!!! OMG !!!!!!!!!!!
thank you - for some obscure reason it never would have occurred to me in a million years that LDAPUserFolder already does this. Well, duh.
Huzzah open-source software!
Amen!
--
Paul Winkler
In article <20030304192817.GC3495@slinkp.com> you write:
Note that you'll also want to change validate() if you go that route. It has a short-circuited version of getRolesInContext in it.
are you sure it's not BasicUser.allowed() that you mean? there's a comment in there about checking roles manaully rather than with getRolesInContext...
Yeah I'm sorry, I meant allowed(). You could also check what NuxUserGroups does, it has to patch this same area to provide a notion of groups to the security machinery. Note that I don't remember your exact use cases, but NuxUserGroups could be useful to you. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:fg@nuxeo.com
participants (8)
-
Adrian van den Dries -
Dario Lopez-Kästen -
Dieter Maurer -
Florent Guillaume -
Jens Vagelpohl -
Leonardo Rochael Almeida -
Oliver Bleutgen -
Paul Winkler