This discussion deals with the design of an access control scheme for Wikis in general,
and for JSPWiki in particular, for use in an academic setting.  It addresses colaboration 
requirements for both teaching and research settings.


From an academic and research point of view there are a number of advantages to deploying 
information in a Wiki. Wiki markup languages are easy to learn and, for this reason, there
is very little that must be learned for an individual to start participating.  Academics
from non-technical fields, who might be less computer-literate than their Computer Science
collegues, can be expected to provide their own instructional materials.  Students can 
collaborate on group projects without having to learn a complex new system.

The various Versioning File Providers in JSPWiki make it particularly well suited to the
academic world since changes, and their authorship, can be easily tracked.  Other features
(such as footnoting and page attachments) are so clearly valuable as not to need explanation.

!Need for New Capability

Having discussed the desirability of JSPWiki for use in academics, we now turn to some of its
shortcomings (from an academic point of view) and how they may be addressed.

__Not Hierarchical__ The primary problem with using JSPWiki (and Wikis in general) in academics is that 
they poorly model the hierarchical nature of an academic setting.  In the academic world institutions
have departments.  Departments have staff and faculty.  Faculty members have research
projects and classes.  Research projects have participants and sub-groups.  Classes have
students, etc., etc., etc..  Contrast this to most Wikis where there is the Wiki Administrator, 
and then there is everyone else.

__Unrestricted Access__ A related problem is that most Wikis do not provide sufficient 
access control to keep participants in one collaborative area from impacting the work of
another group. To some extent one can think of a desire for such restrictuions as
antithetical to Wikis, and any access control scheme that eliminates the free and easy
Wiki creation process would lose most of the advanctages that Wikis offer.  But, on the 
other hand, a well-tuned access control system can be liberating -- making the edges of
the collaboration clear so users can contribute confidently.

__No Resource Administration__ Academic web servers do not have infinite storage capacity
  -- generally far from it.  Any system that invites students to submit data for storage 
on the system should be prepared to limit the amount of data it will accept, either as a 
single file, or as a total.  The system should be set up so that when a student has 
uploaded one-too-many MP3 files the whole site doesn't shut down.  

!The Idea

Logically partition the namespace of Wiki pages by defining a set of Wiki page name 
prefixes.  These ''prefixes of interest'' define ''groups'' of pages (that have names
that start with the prefix.) For each group, specify the '''default''' access level and 
optionally specify the amount of storage allowed for pages
and attachments in the group.  Create an access control table that maps from user 
names to sets of groups with an associated access-level for each group.  
Users' access to Wiki pages will be determined by examining the page name for prefixes 
and granting access according to the user's assigned permission for the group with the
longest matching prefix.

For this to work the Wiki will need to adopt a naming strategy where Wiki page names consist 
of a series of tokens that divide the Wiki into areas, with the broadest categories identified
by the first token and subsequently more specific categorization provided by additional tokens.

In principle these tokens could be single letters.  One could, for instance, specify the storage
allowed for all Wiki pages that begin with the letter 'A', or one could specify that all pages
starting with the letters "QU" would be read only.  More typically, the prefix defining a group
will end with some punctuation mark (usu. a period or underscore) to ensure whole words.
(It may not be desired that "Pageant" fall in the "Page" group.)

Storage and permissions can be defined against the top-level group (the group associated
with the ''empty prefix'' -- the zero length
prefix that is defined as a prefix of __all__ Wiki page names).  Storage limits and permissions
associated with the top-level group will apply to all pages in the Wiki unless overridden by
some group wiht a  longer and more specific prefix.

Access levels will be as follows:

__NOACCESS__: The user cannot interact with pages in the group at all.

__READ__: The user can read the pages but the ''edit this page'' link is suppressed.
       The user cannot create a page starting with the given prefix.

__AUDIT__: The user can read the pages in the group and can view, but not modify, the markup language.
       The edit page displays a look-only message and lacks a save button.  The user
       is allowed to interact with the markup so the page can be a source of cut-and-
       paste text. The user cannot create a page starting with the given prefix.

__EDIT__: The user can read and edit pages in the group, but cannot create a new page.

__ADD__: The user can read, edit and create pages in the group.

__ADMIN__: In addition to EDIT access, the ADMIN user can create and delete sub-groups of 
       any prefix for which the user has ADMIN access.  These new new sub-group's prefixes must 
       be at least one character longer than the prefix for which the user has ADMIN access level.  
       The ADMIN user can grant other users access to his ADMIN groups and to any 
       sub-groups he may have created -- ''including the right to ADMINister them''.
       A user with ADMIN priveleges will always have full edit access to all pages and
       attachments recursively in all sub-groups (regardless of access levels set for
       the sub-group).  An ADMIN user cannot delete his own ADMIN permission but he can grant
       ADMIN permission to another user and ask to be deleted.

!Some examples:

A read-only Wiki administered by a user named Bob. (Only Bob can change anything)

Group Table
|""| |READ

Access Permission Table
||Prefix||User||Access Level

The same Wiki but limited to 100 MB of storage.

Group Table

Access Permission Table
||Prefix||User||Access Level

The same Wiki with a single page guestbook. (Page must be created by Bob -- no one else
has permission to create a new page.  Guests can edit the guestbook but cannot create
a new page.  The GuestBook page will not be allowed to grow larger than 2 MB, including
version history, if enabled.)

Group Table

Access Permission Table
||Prefix||User||Access Level

The same Wiki with 5 MB set aside for pages starting with "Guest." which anyone can create
and/or edit.  Guests can view but not change the markup for the non-guest pages.
 (Note that Bob is now limited to 95 MB since he has given 5 MB away to guests.)

Group Table

Access Permission Table
||Prefix||User||Access Level

A wide-open Wiki except that only Bob, Carol, Ted and Alice can edit the WikiEtiquette page
 (or any page starting with "WikiEtiquette".)

Group Table
|""| |ADD

Access Permission Table
||Prefix||User||Access Level

A Wiki for a chemistry department. KRose is the site administrator.  DrMellon and DrClark are 
professors.  BRitch, WWilliams and PGreiman are teaching assistants working for DrMellon.  
DrMellon administers the "Fac." group where the faculty keep their information.  Chem101 is a class being
offered by DrMellon.  Chem102 and Chem103 are with DrClark.  StudentOne through StudentTen are
students in the various classes.  

Notice that all access beyond read must be granted.  There are no parts of the namespace where
EDIT or ADD permission is granted by default.  Also notice that administration has been delegated.
KRose is the overall admin for the Wiki but has delegated administration of the "Fac." pages to 
DrMellon.  DrMellon and DrClark are also able to administer their personal areas and classes.
DrMellon has delegated to his lab assistants (BRitch, WWilliams and PGreiman) for the "Chem101.Lab1.",
"...Lab2." and "...Lab3." lab sections.  The lab assistants, presumably, have granted the students
access to the appropriate lab group areas.

Prefix Table

Access Permission Table
||Prefix||User||Access Level

!Implementation Notes

The only significant new function that has to be written is a Permission Manager.
The permission manager has two functions: it supplies access permission levels for
pages and it allows maintenance of its data tables by users with ADMIN permissions.
The data used by the Permission Manager is, esentially, the two tables shown in
the examples above.  

Given the group and permission tables, a user name and a page name, the Permission
Manager can provide a level of acccess to grant to the user for that page.  The
permission is determined by a simple inspection of the page name and there is no
need for the page to be read to determine a user's permission level.
The Permission Manager will have an interface to allow an administrator to manage his 
groups.  When the interface is opened it will determine 
which groups and sub-groups, and which permissions entries, fall within the groups
for which the user has ADMIN permission.  This information is extracted and the 
user is allowed to edit it.  When the ADMIN user accepts his changes they are merged
back into the tables.

Because the Permission Manaer can determine access levels merely by inspecting page
names it should be fairly easy to use it to filter lists so that pages that cannot 
be accessed are omitted (Unused and Undefined pages, Recent changes, Search, etc.).  For efficiency
sake it is best to filter the list as early as possible so that pages that will be
eliminated are not first processed.

It is also possible to know which links can be followed when the page is rendered.
Links to inaccessible pages could be specially marked (or the markup language could
be extended to allow them as an option to be omitted.)

Determining a page's position in the permission hierarchy using prefixes to the names
can lead to long page names such as BogusLongPrefixICantControl.Welcome.  This is, to
some extent, just the price you pay for organizing things this way but there are some
ways to minimize the problem.  One can format  links to avoid the problem --
{{{    [Welcome!|BogusLongPrefixICantControl.Welcome]. }}}
It is, nonetheless, tempting to tinker with the markup language a bit to help out
a bit here -- additional page title beautifying rules might be nice, for instance.

Here is a (rather vague) mockup of a possible Permission Manager Admin screen (for BRitch,
one of our lab assistants in the Chemistry Dept example above.)


Welcome __BRitch__

||Prefix||Storage Allocation (MB)||Default Access Level||Action
|Chem101.Lab1|10|NOACCESS| -N/A-
|Chem101.Lab1._ _ _ _|_ _ _ _|_ _ _ _ |:NEW:

||Prefix||User Name||Access Level||Action
|Chem101.Lab1|BRitch|ADMIN| -N/A-
|Chem101.Lab1.|_ _ _ _|_ _ _ _|:ADD:
|Chem101.Lab1.Group1|_ _ _ _|_ _ _ _|:NEW:


;::ACTION: = An action button.  
;:_ _ _ _ = a data entry field. )

__A few things to notice__

BRitch is directly assigned to administer the Chem101.Lab1. group.

He controls the sub-groups Chem101.Lab1.Group1. and Chem101.Lab1.Group2.

He can create new sub-groups provided they all start with Chem101.Lab1.

He can delete sub-groups (but not the top level group he is administering --
only DrMellon or KRose can delete that group.)

He can assign access priveleges to other users for his groups and sub-groups.

He can assign another ADMIN user for his group if he wishes.

He cannot change his ADMIN access permission for his top-level group but
he can assign another ADMIN user and ask to be removed.  (A group has to have
at least one administrator.)

If BRitch were administrating more groups those groups (and any sub-groups) 
would also appear in this display.



A well-thought out system, indeed!  Thank you for writing this, it helps me understand what kind of functionality we need (as I am just implementing the access control).

However, it seems to me that your proposal sounds quite a lot like IdeasMultipleWikiWebs.  Is that right?  Wouldn't the ability to have multiple WikiWebs - with fine-grained access control - be exactly what you are after?

-- JanneJalkanen

I hadn't seen IdeasMultipleWikiWebs when I posted this and, yes, some of my notions are similar. 

He just seems to be thinking about creating a hierarchy to deal with page name collisions.  I 
think that it is when you ''combine'' a hierarchical page structure ''with'' a delegating access-control scheme that you start getting into interesting synergies.
The idea is not just to create multiple sandboxes, but to set things up so the playgound administrator
can assign each sandbox a playgound monitor to make sure everybody 'play's nice'.

I noticed that [ebu] suggested that the hierarchy could reflect an underlying directory structure.
( DirFileSystemProvider )  I thought about that as I was working up my idea but decided that how
the files are stored is a WikiPageProvider detail and doesn't necessarily have anything to do with
access control.  

-- BigLeeH

Yes, obviously any implementation of [multiple wiki webs|IdeasMultipleWikiWebs] would have to have a hierarchical access control system.  TWiki only does it one level deep,  and it might well be that one level is all we need.  Deeply hierarchical structures tend to be nonintuitive to casual users, who get easily lost in them.

The question is: is one level enough?  My guess would be yes - if you have a problem that requires nested wiki webs, then you probably are doing something wrong, and perhaps have to think about restating your problem.

The access control system that is coming up will probably have nested groups, though.  But perhaps not in the first incarnation.

-- JanneJalkanen

If the wiki used a hierarchical page structure, you could simply use the operating system file permissions to control access to pages in a similar fashion. 

FitNesse uses a page scheme that lends itself to this approach. In FitNesse, each wiki page is a directory containing a "content.txt" file with the page's content. Each page can have child pages, which are themselves subdirectories within the parent page's directory. The pages are referenced using the format {{~ParentPage.~ChildPage.~GrandChildPage}}, and so on.

Generally, operating systems provide decent capabilities to control access to directories and files, and this is easy to manage. While you won't have the ability to let wiki users assign rights from within the browser, you could gain considerable control with a new page provider using this sort of page structure.

-- [PaulDownes], 04/16/2003

Over the last few days I have been working on an implementation of part of the above.  I have
implemented the namespace partitioning access control with delegated administration and it seems
to be working out well for me so far.  

I have simplified the Administration interface somewhat from the initial conception.
Now a user can go to a page for which (s)he has ADMIN permission, click
the "Administer this page" link and edit a comma-separated list of Name-Permission pairs that
will apply to the page and its children.  The administrator of a page-group (a page and its 
children) can delegate authorship and/or administration of child pages simply by navigating to 
those pages and adding names and permissions to the list for the child page.

At this time I haven't begun to address the storage limits part but the idea still seems workable.
It is fairly obvious how to proceed if one is using the File System provider, but it is less so
for the various versioning providers.  

It is my understanding that the professor for whom I am doing this plans on making the changes
available.  If anyone is curious about the code, [let me know|http:mailto:lee@haslups.com]
and I will find out how and when that curiousity can be satisfied.

-- [BigLeeH], 04/17/2003