Re: [Zope-dev] LOTS of roles?
In article <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: Security internals, was Re: [Zope-dev] LOTS of roles?
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: Security internals, was Re: [Zope-dev] LOTS of roles?
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: Security internals, was Re: [Zope-dev] LOTS of 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 [EMAIL PROTECTED] Development team www.dev.flow.com.au FLOW Communications Pty. Ltd. www.flow.com.au ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: Security internals, was Re: [Zope-dev] LOTS of roles?
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" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "Paul Winkler" <[EMAIL PROTECTED]> 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, ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
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,
>
> 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
___
Zope-Dev maillist - [EMAIL PROTECTED]
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 )
Re: Security internals, was Re: [Zope-dev] LOTS of roles?
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 [EMAIL PROTECTED]
Development team www.dev.flow.com.au
FLOW Communications Pty. Ltd. www.flow.com.au
___
Zope-Dev maillist - [EMAIL PROTECTED]
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 )
Security internals, was Re: [Zope-dev] LOTS of roles?
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 <[EMAIL PROTECTED]> 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 ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] LOTS of roles?
On Tue, Feb 25, 2003 at 06:33:16PM +, Florent Guillaume wrote:
> Leonardo Rochael Almeida <[EMAIL PROTECTED]> 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
___
Zope-Dev maillist - [EMAIL PROTECTED]
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 )
Re: [Zope-dev] LOTS of roles?
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] LOTS of roles?
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] LOTS of roles?
Leonardo Rochael Almeida <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] LOTS of roles?
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] LOTS of roles?
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. ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] LOTS of roles?
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] LOTS of roles?
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] LOTS of roles?
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 - [EMAIL PROTECTED] > 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. ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] LOTS of roles?
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] LOTS of roles?
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] LOTS of roles?
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] LOTS of roles?
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] LOTS of roles?
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
