LDAPUserSatellite - Misunderstood usage?
Hello, I've been trying to find a description of how the LDAPUserSatellite objects in the LDAPUserFolder Product actually should be used. I've read the included docs and google searched for answers, but can't find what I'm looking for. Basically I've got a large directory of users, and want to give some additional roles in some subfolders of my site. I have a single subfolder below the Zope root housing my site, which contains an LDAPUserFolder connected to this directory, with the original user folder still in place, with one user (admin). I don't have write access to the directory I'm authenticating against (the directory is operated by my school), so I've got LDAP group status stored locally in the LDAPUserFolder, and read-only set on the directory. When I map a group to a role in the LDAPUserFolder itself, the users in the group get that role for the whole site. My understanding from the docs I have found is that if I create a satellite in a subfolder, then I can map groups to roles there, and then those mappings will be in effect for that subfolder. This does not seem to be working. Does anyone know what I might be doing wrong, or where my understanding might be flawed? -- Chris Connett
When I map a group to a role in the LDAPUserFolder itself, the users in the group get that role for the whole site. My understanding from the docs I have found is that if I create a satellite in a subfolder, then I can map groups to roles there, and then those mappings will be in effect for that subfolder. This does not seem to be working.
Does anyone know what I might be doing wrong, or where my understanding might be flawed?
The LDAPUserSatellite augments roles. This is done either by mapping roles that already exist on the user to new roles, or by looking up additional group memberships (which are translated to roles) in an LDAP tree branch you specify in its configuration. jens --------------- Jens Vagelpohl jens@zetwork.com Software Engineer Zope - done medium rare Zetwork GmbH http://www.zetwork.com/
On Fri, 1 Oct 2004 23:06:24 +0100, Jens Vagelpohl <jens@dataflake.org> wrote:
When I map a group to a role in the LDAPUserFolder itself, the users in the group get that role for the whole site. My understanding from the docs I have found is that if I create a satellite in a subfolder, then I can map groups to roles there, and then those mappings will be in effect for that subfolder. This does not seem to be working.
Does anyone know what I might be doing wrong, or where my understanding might be flawed?
The LDAPUserSatellite augments roles. This is done either by mapping roles that already exist on the user to new roles, or by looking up additional group memberships (which are translated to roles) in an LDAP tree branch you specify in its configuration.
jens
OK, what I have are locally stored groups. If these are mapped to roles *in the LDAPUserFolder*, then the users in those groups indeed gain those roles, but then as I would expect, those mappings apply to the whole site, which is a security hole. But if I enter the mapping in an LDAPUserSatellite in a subfolder, the users do not gain the roles. The docs say the mappings augment roles in the context of the satellite. What exactly is that context? Is there a certain ``id`` that the satellite must have in order to be effective? Right now, with logging on 9, nothing shows up in the log besides the two lines at the end of this message, as if the satellite is being bypassed entirely when authentication happens. Or is there a certain structure that I am not following, i.e. the satellite is sitting inside the actual folders for which I want to give augmented roles. Is this the proper setup? ------Log------ (3) Oct 01 19:40:45: Re-initialized through __setstate__ (0) Oct 01 19:40:45: Log buffer cleared ------End Log------ -- Chris Connett
OK, what I have are locally stored groups. If these are mapped to roles *in the LDAPUserFolder*, then the users in those groups indeed gain those roles, but then as I would expect, those mappings apply to the whole site, which is a security hole. But if I enter the mapping in an LDAPUserSatellite in a subfolder, the users do not gain the roles. The docs say the mappings augment roles in the context of the satellite. What exactly is that context?
The context is the enclosing folder and folders "underneath".
Is there a certain ``id`` that the satellite must have in order to be effective? Right now, with logging on 9, nothing shows up in the log besides the two lines at the end of this message, as if the satellite is being bypassed entirely when authentication happens.
Or is there a certain structure that I am not following, i.e. the satellite is sitting inside the actual folders for which I want to give augmented roles. Is this the proper setup?
Yes, this is the proper setup. It is important to note that the LDAPUserSatellite only works in conjunction with a LDAPUserFolder, the link here is the kind of user object emitted by the LDAPUserFolder. Only a user object of class LDAPUser has a specialized "allowed" method that tries to find and use LDAPUserSatellite objects to augment its roles on a per-request basis. jens
On Sat, 2 Oct 2004 19:18:37 +0100, Jens Vagelpohl <jens@dataflake.org> wrote: *snip*
Is there a certain ``id`` that the satellite must have in order to be effective? Right now, with logging on 9, nothing shows up in the log besides the two lines at the end of this message, as if the satellite is being bypassed entirely when authentication happens.
Or is there a certain structure that I am not following, i.e. the satellite is sitting inside the actual folders for which I want to give augmented roles. Is this the proper setup?
Yes, this is the proper setup. It is important to note that the LDAPUserSatellite only works in conjunction with a LDAPUserFolder, the link here is the kind of user object emitted by the LDAPUserFolder. Only a user object of class LDAPUser has a specialized "allowed" method that tries to find and use LDAPUserSatellite objects to augment its roles on a per-request basis.
I took a look at the source and it seems straightforward enough. When I did a little introspection, I found something that might be a problem. I created an external method to report the type of the current user object (needed to be an external method for ``type``), and for both kinds of users, standard (i.e. admin in the default user folder), and authenticated out of LDAP, I got:: <extension class Acquisition.ImplicitAcquirerWrapper at 40796180> so it appears that the users aren't gaining roles because the ``allowed`` method of LDAPUser isn't getting called. Could this have something to do with it, or am I way off base? -- Chris Connett
I took a look at the source and it seems straightforward enough. When I did a little introspection, I found something that might be a problem. I created an external method to report the type of the current user object (needed to be an external method for ``type``), and for both kinds of users, standard (i.e. admin in the default user folder), and authenticated out of LDAP, I got::
<extension class Acquisition.ImplicitAcquirerWrapper at 40796180>
so it appears that the users aren't gaining roles because the ``allowed`` method of LDAPUser isn't getting called.
Could this have something to do with it, or am I way off base?
Python scripts can use something similar to "type", it's called "same_type". Under almost all circumstances the user object you look at *will* be wrapped, so your output just confirms that. In your external method, you could do something like this: from Acquisition import aq_base from AccessControl.SecurityManagement import getSecurityManager ... and then look at the type of user... user_type = type(getSecurityManager().getUser()) (untested and from memory) jens
On Mon, 4 Oct 2004 17:22:12 +0100, Jens Vagelpohl <jens@dataflake.org> wrote: I went ahead and traced the whole process by adding my own logging statements to the source starting with ``allowed`` and following everything. (The proper versions of methods are indeed getting called, so that's not an issue.) I noticed though that it seems in LDAPUserSatellite.py, in ``getAdditionalRoles``, it only goes through the *roles* that the user object has, and adds more roles that those *roles* map to in ``self.groups_map`` (self is the LUS), but it does not go through LDAP *groups* that the user has. My LUF gives only groups to specific users. I have no Zope roles specifically for my groups; it is my intent that the groups map to existing roles like 'Manager' in certain contexts. Has this been my misunderstanding? Are you supposed to create a Zope role for every group in an LUF, and include the trivial mapping from the group to the role in the LUF, then just use LUS for adding roles based on roles only? Or is LUS supposed to be able to add roles based on groups and there is something else wrong? -- Chris Connett
called, so that's not an issue.) I noticed though that it seems in LDAPUserSatellite.py, in ``getAdditionalRoles``, it only goes through the *roles* that the user object has, and adds more roles that those *roles* map to in ``self.groups_map`` (self is the LUS), but it does not go through LDAP *groups* that the user has. My LUF gives only groups to specific users. I have no Zope roles specifically for my groups; it is my intent that the groups map to existing roles like 'Manager' in certain contexts.
There's the misunderstanding. The LDAPUserSatellite object has *no idea whatsoever* which LDAP groups a user happens to be in (meaning the groups seen from the LDAPUserFolder perspective). It looks at... - the *Zope Roles* on the user - LDAP groups the user is a member of underneath the groups search base defined in the LDAPUserSatellite itself
Has this been my misunderstanding? Are you supposed to create a Zope role for every group in an LUF, and include the trivial mapping from the group to the role in the LUF, then just use LUS for adding roles based on roles only?
You are not forced to create Zope roles for *every* group found underneath the group search base in the LDAPUserFolder, but you may. You use the group mappings to define translations between LDAP groups and Zope roles. And yes, the LDAPUserSatellite acts on those roles put on the user by the LDAPUserFolder with the help of those mappings (and if you define a groups search base in the LDAPUserSatellite it will pull in those as well in a simplistic "the group names become role names" fashion). jens --------------- Jens Vagelpohl jens@zetwork.com Software Engineer Zope - done medium rare Zetwork GmbH http://www.zetwork.com/
participants (2)
-
Chris Connett -
Jens Vagelpohl