Forgot your password?
New user?
Document Actions
#102: PlonePAS Integration
- Proposed by
- Alan Runyan
- Seconded by
- Cameron Cooper
- Proposal type
- Architecture
- Assigned to release
- State
- completed
Definitions
GRUF - Group User Folder
PAS - Pluggable Authentication Service
Motivation
Overview
For several years Plone has used GRUF (Group User Folder). GRUF has served us well.
Many companies who build infrastructure require a more expensive infrastructure for
user datasources. GRUF works well for end-users but is rather limiting for infrastructure
developers. But most importantly GRUF is maintained by very few developers and is not
shared across multiple Zope projects (such as Silva, Zope Corp, CPS and Plone).
The Plone community is not in a bubble. We need to leverage as much work across
the Zope community as possible. By deprecating GRUF and moving to PAS (there is a
product, PlonePAS) we have the opportunity to work with the larger Zope community
as well as benefiting significantly from the flexibility this software provides.
We can provide various 'property' providers to store selected attributes in
a variety of datasources. For instance we could have email,userid stored in
LDAP and have 'wysiwyg_editor' stored in ZODB. Providing properties/roles/groups
can be separated out in the same manner - into various datasources.
Proposal
I propose to split the plip into 3 steps:
- Releasing PlonePAS as a product
- Integration PlonePAS into Plone
- Completing the User Interface and possibly provide a revamped control panel integration
Step 1 - Release PlonePAS
Make a release of the PlonePAS software as version 0.5 which is 90% feature complete. I believe
we are also there with what is in CVS. This release will work with Plone 2.0.5. This will enable
people to test and integrate it into existing Plone 2.0.5 installs. It should also work in Plone 2.1
but may require work -- I believe this should not be as much of an issue. See Risks for 2.1 integration.
Step 2 - Integrating PlonePAS
Integrating of PlonePAS should be straightforward. By default we should really focus on
ZODB-centric storing of Properties/Roles/Groups. There are several parts of the Plone UI that
assumes that functionality exists, such as Password Reset. Some datasources can not reset the
password (i.e. send the user a password - as it could be encrypted). So the User Interface impact
needs to be recorded and quite a bit changed.
Have to move to an entirely 'search based' approach to finding users. It is not always possible to get
a list of users in the system since some auth sources will not implement the listing interface.
This is preferable in larger installs
since a user listing is impractical and potentially expensive. Break the User Interface into a notion
of 'Capabilities' when it comes to the User datasources (PAS).
We can create a PlonePAS-Integration branch which uses some stated PlonePAS branch and will change
the Plone UI to meet these requirements. We should also ensure that the tests for GRUF still pass
(for backwards compatibiltiy - where necessary).
Step 2.5 - Migration
A generic migration could be possible. But this is not something I am as interesting in. I believe
we should document and work with the users to attempt to do *some* migration. We should explain in detail
how GRUF will be effected. We can attempt a migration; but a 'silver bullet' migration may not be possible.
Using ZODB in GRUF should be possible. We have LDAP UserFolder migrating. But there are a lot of permutations
of Group/USer folders in GRUF and we need to educate users on how to migrate rather than spending all our time
trying to make migrations be 100% perfect for anything other than the "most common", which is the ZODB.
Step 3 - User Interface
I briefly described that the Plone User Interface makes some assumptions about the user datasources and
capabilities of those datasources. These need to be fixed. But there are several portions of the "user management"
interface that works with PAS that I would like to move to "Zope3-style Views". These will make the logic simpler
and more self contained. These views are directly related to PAS integration into day-to-day 'views' that end users
interact with, such as:
- Local Roles/Sharing Tab
- Control Panel - Users/Groups Administration
- Members form/search
- Am I missing anything else?
It is understood that the 'configuration' of PAS will still occur in the ZMI. The configuration possibilities
are almost infinite in GRUF because of its flexibiltiy. It is also somewhat confusing for people not familiar
with its concepts. So in Plone-tradition we should provide 'sensible defaults' for users.
Deliverables
PlonePas 0.5 release
PlonePAS Integration Branch + Tests
PlonePAS User Interface Integration + ?Functional/Selenium Tests?
Risks
- Backwards compatibility.
- Previous plips such as 'local role blacklisting' which
can be very expensive and PAS does not provide for this
sort of functionality.
- Migrations
Progress log
- PlonePAS 0.3 will be released during EP 2005.
Participants
Cameron Cooper
Alan Runyan
Migration
I think that the migration should not be a major issue for user sources. We should write several migration scripts/procedures, one per kind of user source (eg. one for the ZODB user folder, one for LDAPUserFolder, and that's all).
PLIP 34 is basically the same
Compare PLIP 34, #34: Using PAS instead of GRUF
http://plone.org/products/plone/roadmap/34
An additional risk / side effect
It's worth noting that this will completely break CMFMember compatibility. The Membrane product works w/ PlonePAS, using content objects to feed authentication and decorator plug-ins, but there would need to be a considerable amount of work done to actually create a full Plone member implementation, such as CMFMember provides, on top of Membrane.
a small gloss...
User listing is possible, and is done in PlonePAS for the ZODB-based plugins. Not all plugins/source will/can do this, and I have warning text when this is the case. However, it is potentially expensive for large sites, though this can be tested so that small sites still have the benefit of listing.
I imagine that "most" user folder scenarios can be covered, and already are (GRUF ZODB/GRUF LDAPUF). I would like to put together a nice pluggable migration mechanism to allow better extension for more cases and to support end-user-written migrations.
Migration for some cases may be near to impossible, except perhaps with the untested and probably broken GRUFMultiPlugin. GRUF compatibility should remain in the UI for a long time to come.
The current Plone UI assumes that user/group management is done per user. With PAS, this starts making less sense. With one or two plugin sets, this is reasonable, but a plugin-centric UI, whether ZMI or Plone-side, would be less confusing in advanced cases. This needs some careful thinking.