Over the last 4 days here at 2006 Snow Sprint I've been working on a refactoring of Helge Tesdal's Membrane product.  I think this is important work for Plone, and am very excited about how it's coming along.  Here's a brief overview:

Membrane is a product that allows regular Archetypes content objects to provide the information needed for such user-related tasks as authentication, group membership, user properties, and more.  Anyone who has used CMFMember can speak to the value of using content to represent members.  Workflow becomes a valuable asset in managing site security and member management.  AT schemas are the means to manage member properties, allowing developers to use the auto-generated view and edit templates and AT's rich field validation engine.  Member searches use a catalog.  But anyone who has used CMFMember can also speak to the fact that it is complex, confusing, and somewhat scary.  There are many factors contributing to this, but one of the biggest, IMO, is the complicated user wrapping approach that CMFMember inherits from Plone and the CMF.

How does Membrane improve on this?  Most Plone developers have heard of PAS (i.e. PluggableAuthService) and PlonePAS by now.  PAS is the successor to old school user folders that allows all aspects of user management, including authentication, user properties, group and role management, and more, to be delegated to plug-ins.  PlonePAS is the product that reimplements the standard Plone behaviour using PAS instead of GRUF.  Membrane is a collection of PAS plugins that allow this important information to be retrieved from AT objects existing in your portal.

This is the crux of the distinction: with CMFMember, content member objects wrap persistent user objects, and it is
necessary (and sometimes difficult) to maintain synchronization with the user object.  With PAS, user objects are created dynamically upon request, and with Membrane, the content member objects are BEHIND the user object.  A developer will ask PAS for a user object, PAS will delegate to Membrane, Membrane will retrieve the appropriate content object(s), and will return the appropriate information to PAS.  If Membrane determines that authentication fails, then the user object is never created, no muss, no fuss.

What I have done is refactored Helge's original product into smaller pieces using Zope 3's component architecture.  Originally, if you wanted to use content as a member provider, you would need to subclass your content from a number of different mix-in classes provided by Membrane.  Now all of this behaviour is handled with adapters.  It is possible to use ANY piece of content as a member provider, as long as it implements (or can be adapted to) a very simple interface that Membrane provides.  Similarly, any content can be used to provide properties or specify group membership.  In fact, multiple pieces of content can be used for these purposes.  The default implementation uses a specific reference class to define relationships between these various objects, but since this is componentized it is absurdly easy to replace with any implementation of your choosing.  In fact, nearly EVERY piece of the product is easy to replace with a custom implementation.  It takes a while to wrap your brain around working with adapters and components, but the value of it quickly becomes clear when you realize how loosely coupled the results are, if it is done correctly.

This technology is still very new, of course; this is not road tested, and there are some known gotchas that early adopters should be aware of (see the readme).  And it requires you to be running the Zope 2.9 branch and the Archetypes 1.4 branch from svn, neither of which are officially supported with Plone 2.1.  It's coming along very well, however, and I am very hopeful that this will stabilize quickly and will become Plone 3.0's default member implementation.  This is definitely the forward path for CMFMember; not only is this a much better solution, but the changes that PAS introduces to the low-level user object behaviour mean that CMFMember will not work with PAS at all.  Instead of putting effort into making CMFMember work, I plan on providing a clean migration path forward to a Membrane-derived solution.

Membrane can currently be found in the collective subversion repository.  The componentization work is available on the "adapterizing" branch.