[pmwiki-users] Ideas: Group-based user permissions

[Christopher Dant]

Based on my experience with experience with AuthUser and some
encouragement from PM, I'm posting some thoughts about group-based user
permissions. Some of it is clearly an incremental step from where things
stand today - a web-interface for managing users and more robust
Authuser functionality. Some of it is a little speculative...

Thanks for looking this over.

Chris

Design ideas and analysis for Group-based user permissions with a web
management interface.

Background: I need to administer two wikis which require me to manage
user-based authentication. Once users sign in, they all have access to
the majority of the wiki. Each user will also have access to one or more
restricted WikiGroups (to put it in PmWiki terms). These users will come
and go, wikigroups will come and go, and ultimately I need to delegate
wiki user/group admin to someone else. In addition I'd like the wiki
users to be able to request access and forgotten passwords on a
self-serve basis.

I believe that a permissions system that assigned groups to users via
web-based panels or forms would make this process as streamlined error
free as possible.

Following is a preliminary design which I believe will address these
requirements in a generic, extensible sort of way.

Admin: Tasks related to Users

FORM: Manage individuals
* Add individual (see below for user attributes)
* Change individual (see below for user attributes)
* Remove individual
* Add multiple users from a file
* Remove multiple users as listed in a file
* Reports / lists
  * Current users
  * Users by content group (WikiGroup)
  * User by user group (see below)
  * Users by permission
  * Recently removed users

FORM: Manage access requests
* Approve as requested
* Approve as modified
* Reject with reason (return via email)
* Reject (return via email)
* Reports / lists
  * List current requests
  * Users awaiting approval

Admin: Tasks related to Content Groups (WikiGroups)

FORM: Groups Management (WikiGroups)
* Manage Groups
  * Define default permissions for new groups
  * Set permissions for a group
  * Change permissions for a group
  * Remove permissions for a group
* Reports / lists
  * All groups, showing permissions
  * Subset of groups, selected by permission

FORM: Permissions Management
* Define default user permissions for entire site
* Enable/disable specific permissions on a wiki-wide basis
* Enable/disable permission durations and dates
* Add / change / delete custom permissions
* Reports / lists
  * Current / available permissions
  * Used permissions
  * Unused permissions
  * Groups by permission
  * Users by permission

SETTINGS: System
* Data paths or connectors (LDAP, AD, Apache, etc.)
* Customize / translate screen text

Users: Tasks

FORM: User Management (Settings)
* Apply for user id
* Change password
* Request password (auto reply via email)
* Request permission add/change/delete for a group (requires admin
approval)
* Reports
  * List of available groups (according to current permissions)

Associated Definitions and Analysis

Wiki permission-aware functionality
* Nothing new here that I can see

User Attributes
* User id or name
* Password
* Email address
* WikiGroup permissions (could be called group memberships?)
  * Group name
  * Permissions list for the group, if necessary to override default set
for the group (see below)

Permissions

A permission might be defined as "(basic list item | extended list
item), permission state, permission period"

Basic List
  * Read
  * Edit
  * Delete
  * Create
  * Attr
  * Upload
  * Admin

Extended list
  * Protect / unprotect
  * Undelete
  * Revert
  * List - Access to have the item appear as part of a list of items,
but not to view the item's content
  * Custom

Permission state
  * Allow (default)
  * Deny

Permission period
  * Inception date 
  * Duration and/or
  * Conclusion date

User Groups
* All
* Reader
* Author
* Anonymous
* Authenticated
* Admin
* Owner
* Creator
* Custom groups

NOTES:

Authuser, while it works exactly as designed, has a couple of major
drawbacks for my application. First it requires edits to
local/config.php. Second, unless I assign users according to a
convention that can be matched via a wildcard (using id:p* for example),
I need to update the access list for each group for each user. This is
the wrong way around because it means I have to make multiple edits for
each user twice, once when adding the user and again on removing
him/her. It would be more natural for me to type or select the groups as
an "attribute" of the user, then have the permissions removed with the
user. Also, I want users to select their own user ids and perhaps
ultimately to piggyback on LDAP or some other sort of authentication for
our intranet.