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

[Patrick R. Michaud]

Wow, thanks for the detailed spec!  This gives me a bit to work with.
I haven't had a chance to review it in much detail, but I did want
to quickly comment on the last section (which was also mentioned
in an earlier email)...

On Wed, Sep 21, 2005 at 07:37:14PM -0700, Christopher Dant wrote:
> Authuser, while it works exactly as designed, has a couple of major
> drawbacks for my application. First it requires edits to
> local/config.php. 

Well, users can also be stored in .htpasswd, LDAP, or other locations -- 
it doesn't *require* edits to local/config.php.  That's just one of
the options.  :-)

> 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. ... 

And from the earlier message...

> The result is that wikigroup permissions need to be associated with
> users, not the groups themselves.

I understand your reasoning, but I think the reality is that
associating wikigroup permissions with users just optimizes for
a different task.  As you correctly note, in the present implementation
(where permissions are associated with pages/groups), the act of 
adding a new user sometimes requires updating multiple wikigroups
with authorizations for the new user.  However, associating permissions
with individual users just switches the load to the wikigroups --
i.e., adding a new wikigroup would then require updating multiple
user accounts to authorize users to be able to access that new
group.

(Beyond this, the majority of authorization systems I've encountered
associate the authorizations with the resource to be protected,
and not with the entities attempting to access the resource.  So
we should probably keep this model.)

Fortunately, there's a way to get the best of both worlds, and
that's to introduce "user groups", as suggested numerous times by
Hagan Fox.  Essentially, we allow something like "group:abc" in a 
page's permissions, analogous to "id:xyz" except that it identifies
a group of users instead of just one.  Then, when we add a new user
we can place the user into group "abc" and he/she is authorized
into every page and wikigroup that has "group:abc" in its permission set.

(It's still an open question as to how an admin would associate
users and usergroups; we could have files containing group names and
lists of users in the group, or we could have each user account
identify the groups it belongs to.  Most systems I'm familiar define
groups as lists of users.)

Anyway, that's my current thoughts on the internal permissions
structure.  There are other approaches I'm thinking about, but
they're a little "off-the-wall" relative to what most people are
familiar with so I'm ending the message here before I describe them
below.  :-)

Pm


----other off-the-wall ideas----

We don't *really* have to have a special "group:abc" permission
syntax and separate group structures.  If disallow usernames from
also being group names, then "id:abc" suffices, and "abc" can be
used to identify either an individual user or a group of users.

Yet another way to do this is to allow pages/groups to directly
use the permissions set on another page.  For example, permissions 
could be set as "page:Other.GroupAttributes" which means to
grab authorizations from another page/group.  So then it becomes
easy to mantain sets of permissions from within a single page 
that is referenced from others.  (It also allows pages in other groups
to share non-user password authorizations that may be there.)

Pm