[pmwiki-users] Roadmap Help with Authentication Set UP

Vince Administration vadmin at math.uconn.edu
Thu Jan 11 09:15:34 CST 2007


It seems that what you want could be achieved in a similar manner to  
what we do, with a combination of Apache authorization and
just the standard PmWiki password stuff.
The downside is that you would need Apache authorization. For the  
Public, a Guest account of some kind, possibly with a generic
password. For the others, individual passwords managed by apache. The  
groups can be unix groups (as we do), or you can
roll your own.
I realize that you may not have the capability to use apache  
authorization on your system.  In that case I think individual  
passwords would
probably work better, although a bit more of a pain to set up.

By all means, please make your "musings" available. We all might  
learn something.
       Vince

On Jan 10, 2007, at 11:28 PM, Sivakatirswami wrote:

> 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
>
>
> _______________________________________________
> pmwiki-users mailing list
> pmwiki-users at pmichaud.com
> http://www.pmichaud.com/mailman/listinfo/pmwiki-users
>





More information about the pmwiki-users mailing list