[pmwiki-users] Roadmap Help with Authentication Set UP

[Sivakatirswami]

I'm about to merge several fields into one wiki and will need to start
implementing per group authentication.

Before starting, I'm studying the authentication options, PMWikis simple
password system, vs AuthUser.

I have a long page of "Conceptual Musings" on this whole area...where I
clarified my thinking. As there appears to be  many options and I need
to find my way forward thru the authentication forest and not waste a
lot of time. So I'm looking to have a good blueprint done before
laying in any bricks.

I have two questions today:

1) can I and would it be useful to  add a link on the PMwiki Roadmap
page, to a new page and put my "musings" there? It much too long for
this mailing list.
I would be interested in
a) comments from people who have already built such sites and
b) offering this to PM, as it might be good for
advanced admins to see what a "naive" admin
has to wrap his head around to get started...
this could useful context for the future centralized authorization 
control recipe.

2) After the musing were done I analyzed all possible future users of 
our wikis,
seeking to find some "generic" categories that
might help reduce the number of user-password names needed to be
managed.  I came up with 8 "levels." These are listed below
where the numbers of users in the different categories ranges from
"infinite" for public up to "1 only " for admin. Nomenclature is
from a non-profit org lexicon, but I think the "8 levels" would translate
into (of from) any other hierarchical context (military, edu, corporate, 
gov)

Level 1  * Public -- read only, specific "out front" group or pages, but 
not all groups-pages
Level 2    * Associates -- read only, specific  groups for 
"collaborative for public consumption" = read but not edit
Level 3    * Collaborators -- read and edit, specific "collaborative for 
public consumption" groups-content
Level 4    * Members -- read and edit: specific "in-house" groups-content
Level 5   * Supervisors -- read, edit and edit attributes of some (but 
not all) groups
		# Supervisors is unlikely to be used by me but large orgs admins would 
want it.
Level 6    * Team -- read and edit the entire wiki *except* core 
documentation
that present security risks.
    		#These users have FTP access to specific, jailed-in areas on the 
server.
Level 7   * Core -- read and edit all pages, root access to webserver, 
including wiki.d, config.php
		# but are trusted and will rarely touch wiki config files unless they 
ask first.
Level 8    * Admin -- has Site password and can edit attributes of site 
and groups globally.

For purposes of discussion we might call these authorization "classes"

So, I guess what this is is a call for help on "best practices" to 
achieve the above
authentication framework where any number of individuals may be have.

I see two possible directions:

I. create a "level" specific passwords with a auth-class integer tag. 
This would just
make use of PMwiki's existing password system and no .htaccess style 
AuthUser
would be needed.

1apples, 2oranges, 3bananas, 4papayas, 5kiwi, 6starfruit, 7durian, 8mango

Then for any group or page it's easy to remember

  For public, you just put right on the home page "Please enter password 
1apples"
and then apply all eight passwords to those groups.
--1apples, 2oranges, 3bananas, 4papayas, 5kiwi, 6starfruit, 7durian, 8mango

for level two access you give out to your associates the password 
"2oranges"  then you apply

2oranges, 3bananas, 4papayas, 5kiwi, 6starfruit, 7durian, 8mango

Level 3 groups get:

3bananas, 4papayas, 5kiwi, 6starfruit, 7durian, 8mango

etc.  all the way up to high level classification groups to which you 
only apply

passwords: 7durian, 8mango

PROS: easy to remember , no user-name issues to worry about.
CONS: low security, if someone "leaks" a password and "bad boy" comes 
in, then
you need to changs "4papayas" to "4jackfruit"  and tell all of your 
collaborators
that there is a new pass word: headache for everyone.

Also, I would like to auto enforce author to be every edit.  I don't 
think this system
does that... users have to manually enter their name.

II. Use Auth-User... but I need some help to understand best how to set 
it up.

I could see a similar system user auth groups (where group is not pages 
but a group of
users as per auth-user recipe which I read and have partially digested...)

Level-1: user-public,password: quick
Level-2: a general use-pass word for all your associates, + 
user-password for those with abov.

At this point my brains starts to steam up and my glasses fog over... 
you want people with
level 7 classification to be able to read and edit all pages, so how do 
you set it up
so that they don't have to remember the user-password for all the levels 
"below" them, but such
that all level's below them become accessible with a single 
user-password entry.

I guess what you do is use the user-groups names in the Attributes and 
then add the Specific  user-pass
to each of the groups below them.. USER: bob PASS 1hope8  is entered 
into all "levels"
he has access to...

At best, no matter what you do, you still need to apply whatever you do 
to every single
group on the wiki. Of course, addition of group is relatively rare, but 
still,
The admin overhead seems complicated.. So,  I would really appreciate help
from anyone...the goal beings some simple method to set these 
"classification" levels
of access all groups on the wiki, with some simple way that's easily 
changed if
security requires it.

Maybe there is an easy way to approach this and I'm just not seeing it 
yet. We hope so!

Sivakatirswami