[Zope3-dev] proposal: allow contained PAU plugins

[Gary Poster]

Background:
The pluggable authentication utility (hereafter called PAU; found in  
zope.app.authentication) allows two kinds of plugins, credential  
plugins and authenticator plugins.  The PAU currently keeps track of  
the names that it should use for these two types of plugins, and then  
looks up utility components by those names.  The plugin utilities  
know of no relation to the PAU, and there is nothing stopping a  
single utility from being used for multiple PAUs.

Principals from authentication utility plugins have ids that are  
comprised of three components: the PAU prefix, the authentication  
plugin utility prefix that identified the user, and the  
identification of the user within the authentication plugin.

Primary Problem:
Some plugins want to know what PAU they are associated with.  They  
also may only want to be used by a single PAU.

For instance, if a authenticator plugin wishes to convert some of its  
local principal information into a principal or principal id, perhaps  
to fire an event, it cannot: the PAU is the only component that knows  
how to do that, in part because of the composition of ids described  
in the second paragraph of background, above.

Another example is that groups folders should only be applied to  
principals defined in its same PAU: principals defined in sites above  
will never have a chance to ask the lower groups for their blessing  
(see zope/app/authentication/groupfolder,txt, the "Limitation"  
section at the bottom).   Group folders cannot maintain that  
constraint themselves, because

Secondary Problem:
It would be nice to not have to do the utility registration dance for  
local PAU plugins.

Tertiary Problem:
The PAU is a site management folder, which means it can hold local  
utilities; it typically is used to hold plugin utilities, and this is  
a bit misleading.  Adding them in the PAU does not do anything unless  
you register them as a local utility; and there's no difference in  
doing that in the PAU or in a normal site management folder.  The  
registered plugins can in fact be used by PAUs below the one in which  
they reside, which is again not obvious.

Consideration:
Some (many?) plugins *are* appropriate to be shared--credentials  
plugins are often sharable, for instance.  The utility pattern does  
have merit, and should be maintained.

Solution:
In addition to utility-based plugins, allow contained plugins, which  
are looked up by name from within the PAU.

Adding a plugin to the PAU would immediately make it available to be  
used by the PAU, without having to register it as a utility.  The id  
in the container would be the name for the lookup.  Container names  
would mask utility names (i.e., the container names would have  
precedence).

Some plugins would want to only be contained item plugins, some would  
want to only be utilities, and others might be flexible, supporting  
use as contained items or registered utilities.

Contained item plugins could count on __parent__ being the relevant  
PAU; if their __name__ was one of the configured plugins in the PAU,  
then they are active.  The PAU's prefix adds the missing link to get  
a full principal id, and the PAU API adds the missing link to get a  
principal.

PAU UI might not have to change too much, though it would help the  
tertiary problem if utility plugins and contained item plugins were  
clearly distinguished in the PAU container UI.

The Group Folder would become a contained item plugin.  Others might  
follow.

Notes:
This is reminiscent of the Zope 2 PAS approach.

Risks:
Some additional complexity, perhaps.



Thoughts appreciated.

Gary