User Tools

Site Tools


wikiisms:namespacesecurity

Namespace Security

Cardboard BoxThe purpose of this page is to describe how namespaces work in Dokuwiki, and explain how they can be used to implement security strategies.

Namespace Security

Before talking about namespace security, we need to fully understand namespaces themselves. A brief discussion of the subject follows.

What is a Namespace?

In a wiki, a namespace is a grouping mechanism. Namespaces are important when a large number of documents exist because they eliminate confusion. Consider a document named “return.pdf.” Is this a tax return, or does it describe Uncle Bob's trip home after a long exile in Africa? The document name doesn't make it clear. We could add more information to the document name, perhaps calling it “tax_return.pdf” to solve the problem. But what happens when two or more documents exist for the same reason–perhaps from different years or for different people?

One way to handle this problem is to continue including more information in the filename, such as “2008_tax_return.pdf”. While this is easy to do in a single-user environment, it doesn't work well in multi-user environments. Each user is likely to create his or her own documents using the same naming conventions, thus overwriting other documents or causing confusion. And the number of naming collisions will increase as time goes on.

So another strategy is needed…one that separates documents by something other than a filename. This is exactly what namespaces do. On a hard drive, a directory is a namespace. In the Java programming language, a package is a namespace. In a filing cabinet, a folder represents a namespace. And in a warehouse, a cardboard box represents a namespace.

Illustration

Here is one possible way to structure the namespaces in a wiki. This illustration uses a single-user scenario for the purpose of discussion.

wiki root
 |
 *--personal
 |  |
 |  *--bills
 |  |  |
 |  |  *--2007
 |  |  |
 |  |  *--2008
 |  |
 |  *--family
 |  |
 |  *--hobbies
 |
 *--work
    |
    *--projects
    |
    *--sales leads

Notice there are two primary namespaces. These should be as mutually exclusive as possible. In other words–there should be no doubt as to which namespace a document belongs in. Our illustration's namespaces–home and work–are clearly named and non-overlapping. Proper naming strategies are essential.

Inside the personal namespace, the subnamespaces are related to subject matter. Although bills, family and hobbies might lead to some ambiguity 1), it is generally understood where documents should be stored. Perhaps more importantly: namespaces can be added or changed in the future to improve clarity.

Within the bills namespace, the subnamespaces are grouped by time period. This a very precise strategy since bills are normally dated.

The work namespace is a little vague–only 2 subnamespaces: projects and sales leads. What about research? What about miscellaneous information? What about sales leads that turn into projects in the future? This area needs more thought.

Namespace Security

Now we turn our attention to security. How can we separate individual users from each other? How can we allow users to collaborate as a group yet remain independent from other groups? How do we maintain security over time as people move to different groups? These questions are addressed by Namespace permissions.

In Dokuwiki (as in many other multi-user products), there are 3 main concepts to understand: users, groups, and access control lists.

  • Users are people. They are defined in the User Manager on the Admin panel. All users have an ID, with the exception of visitors. Visitors are treated differently, as described below.
  • A Group is a collection of people. Groups are created to simplify the creation of access control lists. A person can belong to more than one group. People who don't have an ID are members of s special built-in group called “ALL”.
  • An access control list (or ACL) has 3 components: a user (or group of users), a pagename (or a namespace), and a set of permissions. These permissions determin if users can read, write, update, or delete documents, and if they can upload documents or not–a total of 5 permissions per ACL.

Illustration

Lets illustrate namespace security with an example:

<draw name=namespacesecurity namespace=wikiisms>

The green bubbles on the right represent namespaces in Dokuwiki. Each namespace can point to a directory, a file, or a collection of either. For example, a namespace defined as finance*.xls would refer to all Excel spreadsheets with the word finance at the beginning of their filename. These are the groupings mentioned previously.

The middle column (in orange) is the interesting one. These are the roles (also called Access Control Lists, or ACLs) of the system. They are an abstract set of permissions that defines what a certain type of user can do, see, or edit on the wiki. Each role can be granted permissions to tailor their use of the wiki. For example, the public ACL can be granted read-only permission to the public namespace. Any member of this role will not be able to edit, nor will they see any content protected by another group permission.

The column of green bubbles on the left represent people with user IDs on the system. The bottom-most of these is the built-in group for non-logged-in visitors to the wiki–those who are just browsing. When this group does not have read access to the wiki, the site becomes a private one (meaning people must login before seeing anything). If the group does have read access but self-registration is disabled, the wiki takes on the flavor of a departmental system where only team members can edit. And if self-registration is enabled, the wiki becomes a public site for collaboration by anyone who cares to participate.

Wiki administration begins on the right-hand side of the diagram with the creation of namespaces. Then it proceeds to the center column where access control lists are created and namespaces are added to them. Finally, the administration panel allows the administrator to manage user IDs and assign them to zero or more ACLs.

1) for example: where would you store bills related to hobbies–in the bills namespace or the hobbies namespace?
/home/cfreyer/public_html/data/pages/wikiisms/namespacesecurity.txt · Last modified: 2008/03/31 15:50 by Chris Freyer