This is version . It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]


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


Access Permission Table

PrefixUserAccess Level

The same Wiki but limited to 100 MB of storage.

Group Table


Access Permission Table

PrefixUserAccess 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

PrefixUserAccess 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

PrefixUserAccess 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

PrefixUserAccess 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

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

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

PrefixStorage Allocation (MB)Default Access LevelAction
Chem101.Lab110NOACCESS -N/A-
Chem101.Lab1._ _ _ __ _ _ __ _ _ _ :NEW:

PrefixUser NameAccess LevelAction
Chem101.Lab1BRitchADMIN -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.

Add new attachment

Only authorized users are allowed to upload new attachments.
« This particular version was published on 03-Apr-2003 02:24 by BigLeeH.