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


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.


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 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 and I will find out how and when that curiousity can be satisfied.

-- BigLeeH, 04/17/2003

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-80) was last changed on 26-Sep-2007 23:21 by JanneJalkanen