FrontPage BetterUserManagement / backlinks

BetterUserManagement Proposal

Note - this document is still a work in progress. Please do not make inline comments in the proposal - use the BetterUserManagementDiscussion to make comments.

Contact

Brian Lloyd (brian@digicool.com)

Problem

In the course of several years and many applications built, we now have a fair amount of experience with various approaches to user management and authentication / authorization. Over time, DC and the Zope community have implemented user sources based on relational data, LDAP data, operating system user data and more. This experience has pointed out some shortcomings in the current architecture for user management.

This can be thought of as a concrete example of both the "simplify the user experience" and "simplify the developer experience" goals in the current Zope roadmap. The current architecture does not do as good a job as it could to make user management easy and to make it easy to implement alternate user sources.

Some problems with the current user management APIs^x and default User/UserFolder^x implementation in Zope include:

• Scalability to large numbers of users. Both the current HTML interface for managing users and certain technical underpinnings are not well suited to large numbers of users (in the thousands).

• Does not support extended attributes. Many applications need to associate metadata with users beyond the bare minimum that Zope currently supports for basic access control. Several community-developed user sources support extended user attributes but not all do it in the same way, making it difficult for application developers to change user sources in the future.

• Assumptions about authentication data. The current APIs^x make some assumptions about the handling of authentication data that can make it difficult for people trying to implement new user sources. For example, to implement HTTP Digest authentication, the current design would force a developer to override and reimplement parts of the "private interface" that is supposed to be a black box to subclasses.

• Storage of password information. The default user objects in Zope have their password information stored in the object database in a clear-text format. Though someone would have to have permission to the filesystem or the ability to export object data to take advantage of this, it would be better if user implementations could avoid storing the actual password unless it is absolutely required due to the nature of the authentication algorithm.

• No standard facility for users to manage their own information. People shouldn't have to roll their own code to allow users to do simple things (like change their own password or logout) themselves.

Proposed Solution

This project proposes to revisit the user managment framework, addressing some specific problems and incorporating some of the good ideas that have been developed over time in other user management implementations such as LoginManager^x. Specifically, the result of this project should address:

• Scalable user management UI & architecture

• Extensible authentication protocol handling

• Security of user data

• Standard APIs^x designed to support alternate storage interfaces

• Standard APIs^x to support extended user attributes

• Outline support for logging and management information

• The opportunity to update jargon to familiar terms

• Ability to change own password and logout

• identity without authentication?

Risk Factors

• As always, backward compatibility. Should existing user and user database-like objects magically gain support for the new apis? Or should older objects be deprecated and still supported for awhile?

Scope

This project will concentrate on improving the design of the user / user database aspects of the Zope security infrastructure. We will not try to address other perceived problems of the infrastructure (managability of permissions, etc.) in this project.

Deliverables

This project is expected to produce:

• An expanded set of common user / user database APIs^x

• A stable implementation of the built-in Zope user database and user objects that support the new apis.

• A developers guide that explains how to develop new kinds of user databases.

• Zope help system pages for each user management screen for builtin user databases.

• API documentation for inclusion in the help system covering the public interfaces of User objects and user databases.

• Documentation to replace the current documentation in the Zope Content Manager's Guide covering the management of users.