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  

This page was created on 03-Apr-2003 02:24 by BigLeeH

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Difference between version and

At line 1 changed 399 lines
!!Introduction
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.
!Background
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
||Prefix||Size||Default
|""| |READ
Access Permission Table
||Prefix||User||Access Level
|""|Bob|ADMIN
----
The same Wiki but limited to 100 MB of storage.
Group Table
||Prefix||Size||Default
|""|100|READ
Access Permission Table
||Prefix||User||Access Level
|""|Bob|ADMIN
----
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
||Prefix||Size||Default
|""|100|READ
|"GuestBook"|2|EDIT
Access Permission Table
||Prefix||User||Access Level
|""|Bob|ADMIN
----
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
||Prefix||Size||Default
|""|100|AUDIT
|"Guest."|5|ADD
Access Permission Table
||Prefix||User||Access Level
|""|Bob|ADMIN
----
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
||Prefix||Size||Default
|""| |ADD
|"WikiEitquitte"|5|READ
Access Permission Table
||Prefix||User||Access Level
|""|Bob|ADMIN
|"WikiEtiquette"|Carol|ADD
|"WikiEtiquette"|Ted|ADD
|"WikiEtiquette"|Alice|ADD
----
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
||Prefix||Size||Default
|""|2000|READ
|"WikiEitquitte"|5|READ
|"GeneralInfo"|50|READ
|"Fac."|1000|NOACCESS
|"Fac.Clark"|100|NOACCESS
|"Fac.Clark.ContactInfo"|1|READ
|"Fac.Mellon"|100|NOACCESS
|"Fac.Mellon.ContactInfo"|1|READ
|"Chem101"|100|READ
|"Chem101.LabNotesSkeletin"|2|AUDIT
|"Chem101.Lab1"|10|NOACCESS
|"Chem101.Lab1.Group1"|2|NOACCESS
|"Chem101.Lab1.Group2"|2|NOACCESS
|"Chem101.Lab1.Group3"|2|NOACCESS
|"Chem101.Lab2"|10|NOACCESS
|"Chem101.Lab2.Group1"|2|NOACCESS
|"Chem101.Lab2.Group2"|2|NOACCESS
|"Chem102"|100|READ
|"Chem102.Notes"|5|AUDIT
|"Chem102.InstructorsNotes"|5|NOACCESS
|"Chem103"|100|READ
|"Chem103.Notes"|5|AUDIT
|"Chem103.InstructorsNotes"|5|NOACCESS
Access Permission Table
||Prefix||User||Access Level
|""|KRose|ADMIN
|"Fac."|DrMellon|ADMIN
|"Fac.Clark"|DrClark|ADMIN
|"Chem101"|DrMellon|ADMIN
|"Chem101.Lab1"|BRitch|ADMIN
|"Chem101.Lab1.Group1"|Student1|ADD
|"Chem101.Lab1.Group2"|Student2|ADD
|"Chem101.Lab2"|WWilliams|ADMIN
|"Chem101.Lab2.Group1"|Student3|ADD
|"Chem101.Lab2.Group2"|Student4|ADD
|"Chem101.Lab1"|PGreiman|ADMIN
|"Chem101.Lab1.Group1"|Student1|ADD
|"Chem101.Lab1.Group1"|Student2|ADD
!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.)
vvvvvvvvvvvvvvvvvvvvvvvvvv
Welcome __BRitch__
||Prefix||Storage Allocation (MB)||Default Access Level||Action
|Chem101.Lab1|10|NOACCESS| -N/A-
|Chem101.Lab1.Group1|2|NOACCESS|:EDIT::DELETE:
|Chem101.Lab1.Group2|2|NOACCESS|:EDIT::DELETE:
|Chem101.Lab1._ _ _ _|_ _ _ _|_ _ _ _ |:NEW:
||Prefix||User Name||Access Level||Action
|Chem101.Lab1|BRitch|ADMIN| -N/A-
|Chem101.Lab1.|_ _ _ _|_ _ _ _|:ADD:
|Chem101.Lab1.Group1|Student1|ADD|:EDIT::DELETE:
|Chem101.Lab1.Group1|Student2|ADD|:EDIT::DELETE:
|Chem101.Lab1.Group1|_ _ _ _|_ _ _ _|:NEW:
^^^^^^^^^^^^^^^^^^^^^^^^^^
Where
;::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.
----
!Discussion
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
----
...
--Jamelia, 18-Oct-2006
----
...
--Stan, 18-Oct-2006
----
...
--Robin, 19-Oct-2006
[DELETEME]
Version Date Modified Size Author Changes ... Change note
80 26-Sep-2007 23:21 18.322 kB JanneJalkanen to previous
79 26-Sep-2007 02:17 18.344 kB 216.23.162.164 to previous | to last
78 26-Sep-2007 02:16 18.335 kB 219.138.204.162 to previous | to last
77 25-Jul-2007 23:29 18.322 kB MurrayAltheim to previous | to last despammed again
76 25-Jul-2007 20:50 18.846 kB Pourseset to previous | to last Comment by Pourseset
75 24-Jul-2007 16:00 18.322 kB MurrayAltheim to previous | to last despammed again
74 24-Jul-2007 15:33 18.858 kB Potestido to previous | to last Comment by Potestido
73 24-Jul-2007 09:52 18.322 kB JanneJalkanen to previous | to last despam
72 24-Jul-2007 09:44 19.339 kB JusSpeaphbubs to previous | to last Comment by JusSpeaphbubs
71 23-Jul-2007 23:19 18.826 kB DiemeSeswes to previous | to last Comment by DiemeSeswes
70 30-Nov-2006 15:49 18.322 kB JanneJalkanen to previous | to last Comment by fede padre pio
69 30-Nov-2006 04:23 18.327 kB 145.18.18.151 to previous | to last Comment by fede padre pio
68 16-Nov-2006 01:32 18.322 kB JanneJalkanen to previous | to last
67 15-Nov-2006 00:13 18.323 kB 82.195.110.227 to previous | to last
66 11-Nov-2006 18:24 18.322 kB JanneJalkanen to previous | to last
65 11-Nov-2006 13:01 18.499 kB fede padre pio to previous | to last Comment by fede padre pio
64 19-Oct-2006 05:54 18.322 kB TS to previous | to last remove spam
63 19-Oct-2006 05:43 0.012 kB TS to previous | to last remove spam
62 19-Oct-2006 05:42 18.446 kB Robin to previous | to last
61 18-Oct-2006 15:28 18.405 kB Stan to previous | to last
« This page (revision-80) was last changed on 26-Sep-2007 23:21 by JanneJalkanen