[Zope-PAS] Re: Failure authorizing with PlonePAS and pubcookie

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

cristopher pierson ewing wrote:
> Tres,
> 
> I'm the poor lug who wrote the plugins in queestion.  Thanks again for 
> helping out with this.  I've got some questions and some ideas folded in
> with your response below.
> 
> On Tue, 13 Feb 2007, Tres Seaver wrote:
>> >> Thanks for responding.
>> >>
>> >> The multi-plugin was written by Cris (cc'd above) here at UW.  The
>> >> plugin isn't incredibly invasive, and in fact at one point it seemed to
>> >> be working so I tend to assume that it may be a
>> >> configuration/installation/human error.  If you'd like to take a look at
>> >> it, I've copied a tarball and the extracted contents out to
>> >> http://staff.washington.edu/mdgilb/ for perusal.  We've done a fair
>> >> amount of debugging to the plugin and haven't found a blaring error yet,
>> >> but it is possible we missed something.
>> >>
>> >> The main problem that we seem to be having seems related to the context
>> >> of the installation - if the plugin is installed at the zope root
>> >> acl_users folder, only users listed in that folder with the manager role
>> >> will have their permission reflected on all plone sites underneath.  If
>> >> the plugin is installed under a plone site's acl_users folder, users
>> >> with the manager role in that site have the proper permissions, but root
>> >> level managers (ie zope admins) will have a limited set of rights - once
>> >> the plugin is enabled for the final plugin type, trying to view all
>> >> available plugin types again (/<SiteName>/acl_users/plugins) will result
>> >> in a list of Undo options instead of the expected Plugin Types.
>>
>> The plugin likely needs to check with the "parent" user folder, if any,
>> for role assignments, as well as looking in its own map.  Likewise for
>> group membership, if your roles are assigned to groups, rather than
>> directly to users.
> The plugins I wrote don't have any component for checking group membership 
> or roles (as far as I know).  There's only four plugins defined in the 
> folder, a Challenge plugin, an authenticateCredentials plugin, an 
> extractCredentials plugin, and a resetCredentials plugin.  As far as I 
> have been able to tell, group membership seems to be handled by the 
> 'source_groups' plugin in the plone acl_users and by 'groups' in the zope 
> acl_users.  The same goes for role acquisition.  There appears to be a 
> role manager for the plone acl_users and another for the zope acl_users. 
> As far as I've been able to tell, the problem seems to be that the only 
> acl_users that gets checked with is the one appropriate to the context of 
> the page request made.  So, if a page from the zope ZMI is requested, the 
> acl_users in the root zope folder is used for all plugins.  If the page 
> requested comes from the plone site, then the plone acl_users is selected, 
> and the plugins come from there.  The problem seems to arise in that if a 
> principal defined in the zope acl_users and given the role of 'manager' 
> from there attempts to access a plone site page, the role he is granted by 
> the zope acl_users is never found, because the role manager consulted 
> comes from the plone acl_users, and the principal doesn't exist there.

You've got your finger on the crux, here:  the user identified by
pubcookie is being "recognized" by the child PAS (becuase of the
cookie), but is *not the same user* as the one in the root:  she just
happens to have the same userid as the one defined in the root.  This
would be the same problem if you created "traditional" user foldere and
defined users with the same ID in both parent and child:  any role
assignments made to the parent would be "shadowed" by the presence of
the doppelganger in the child.

As a hack, I might try adding another method, 'getRolesForPrincipal', on
your plugin, and register it as an IRoles plugin.  In that method, you
will need to check the global roles of the user with that ID in the
*parent* user folder, and add them to any assigned there.

In fact, you might be able to accomplish this via a
'DelegatingMultiPlugin' (or at least steal the code from there).  Here
is what its 'getRolesForPrincipal' looks like::

    def getRolesForPrincipal(self, user, request=None):
        """ Fullfill RolesPlugin requirements """
        acl = self._getUserFolder()

        if acl is None:
            return ()

        user = acl.getUserById(user.getId())

        if user is None:
            return ()

        return tuple(user.getRoles())

In your case, the only hard part would be that first call, to
'_getUserFolder':  you would need to replace it with something which
looked at the "grandparent" of the plugin to find the containing user
folder:'(aq_parent(aq_parent(aq_inner(self)))'.

> In general, I would break apart the idea of group membership, which is
> typically done globally (within the entire scope of the user folder),
> from role assignment.  Mostly, I avoid doing "global" role assignment,
> preferrning instead to grant roles to the groups as "local roles".
>> So, if I read this right, you are suggesting that a principal should be 
>> granted roles solely on the basis of group memberships.  That makes sense 
>> to me, it certainly cleans up the picture when trying to figure out which 
>> roles to apply.
> 
> I'm also pretty convinced that you don't really want or need more than
> one user folder, in general at the root of the Zope database:  the
> complexity caused by nesting user folders outweighs any benefit I've
> ever identified.
>> We haven't been nesting user folders.  The problem seems to arise in that 
>> a default zope installation creates an acl_users 'folder' (really a PAS 
>> object), and a default plone installation creates a second one at the root 
>> of the plone site.

Plone creates both, actually, replacing the "traditional" one in the root.

>>  The problem seems to be that the PAS object that 
>> exists in the context of the page request made is the only one asked for 
>> information about the roles/credentials of the user making the request, 
>> and so we are running into trouble.
> 
>> Is it possible to just delete the acl_users PAS object from the root of 
>> the plone site?  Is it advisable to do so?  If we do that, will the 
>> request for plugins to handle authorization and authentication bubble up 
>> to the zope instance of acl_users?  Perhaps this would solve all our 
>> problems, but it's a little scary to do.

It is certainly possible:  you would need to ensure that you recreate
any state in the child folder (properties, etc.).

>> Thanks again for your help

You're welcome.
,

Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF1GXX+gerLs4ltQ4RAuBVAJ9Xj8OPT7Y4Q2B/ZVziD4Wr8ENqWgCfUzNV
adwPxPSEarKQj0+5p1PFyvo=
=5b6u
-----END PGP SIGNATURE-----