[pmwiki-users] Roadmap Help with Authentication Set UP
Sivakatirswami
katir at hindu.org
Wed Jan 10 22:28:28 CST 2007
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
More information about the pmwiki-users
mailing list