[Zope3-dev] PAS vs pluggableauth

[Jim Fulton]

Zope 3 has a pluggable authentication service, zope.app.pluggableauth.

Zope 2 has a pluggable authentication service, PAS, which was partially
inspired by Zope 3's pluggable authentication service.

At this point. Zope 2's PAS is more mature that Zope 3's pluggableauth.
It is more configurable and has been employed in production environments.
It takes a different architectural approach that, I think, makes it superior.

In pluggableauth, principals are manageged by principal sources.  They are
typically persistent and, in any case, are under the control of the principal
source.

In PAS, principals are created for each request.  The model in PAS is
that principals are created from minimal information and then are scribbled
on by various plugins.  This model is extremely flexible, making it
much easier, for example, to distribute things like group memberhip
management.

Of course, PAS has the advantage that it is being widely adopted in Zope 2.
While the Zope 3 PAS will be somewhat different (simpler) than the Zope 2
flavor, it should still be very familiar to Zope 2 PAS users.

I'm in the process of porting/reinterpreting PAS for Zope 3.  I began this
because I'm also working on introducing groups to Zope 3, as described in:

   http://dev.zope.org/Zope3/AggregatePermissionsAndPrincipalGroups

and I see PAS providing a cleaner architecture to base groups on:

Here's a brief (and rough) introduction to the PAS for Zope 3 architecture:

   Pluggable Authentication Service
   ================================

   The Pluggable Authentication Service (PAS) provides a pluggable
   framework for authenticating principals and associating information
   with them.  It uses a variety of different utilities, caled pluggins,
   and subscribers to get it's work done.

   The job of an authentication service is to authenticate principals.
   Given a request object, the authentication service returns a principal
   object, if it can.  The PAS does this in two steps:

   1. It determins a principal ID based on authentication credentials
      found in a request, and then

   2. It constructs a principal from the given ID, combining information
      from a number of sources.

   It uses plug-ins in both phases of it's work. Plugins are named
   utilities that the service is configured to use in some order.

   In the first phase, the PAS iterates througha sequence of extractor
   plugins.  From each plugin, it attempts to get a set of credentials.
   If gets credentials, it iterates through a sequence of authentication
   plugins, trying to get a principal id for the given credentials.  It
   continues this until it gets a principal id.

   Once it has a principal, it begins the second phase.  In the second
   phase, it:

   - Iterates through a collection of principal factory plugiins until a
     plugin returns a principal object for given principal ID.

   - Having gotten a principal, it publishes a principal-created event.
     Subscribers to this event are responsible for adding data,
     especially groups, to the principal.  Typically, if a subscriber adds
     data, it should also add corresponding interface declarations.

   If the unauthorized method is called on the PAS, the pas iterates
   through a sequence of challenge plugins calling their challenge
   methods until one returns True, indicating that a challenge was
   issued.

   If getPrincipals is called, the PAS uses IPrincipalSearch pluggins to
   find matching principal ids.

Over the next few days, I expect to check in some documentation and implementation
for this.

I'm inclined to eventually migrate from pluggableauth to this.

Thoughts?

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org