The pluggable authentication utility (hereafter called PAU; found in 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.

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.

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.

This is reminiscent of the Zope 2 PAS approach.

Some additional complexity, perhaps.

Thoughts appreciated.

Zope3-dev mailing list

Reply via email to