Rolo's Notes on Twiki Access Control

This page describes some of the behavior of Twiki when using some of the access control facilities. Access Control is the ability to restrict the viewing and editting of topics to a select group of people. This is particularly useful when you want to post sensitive information to which only certain individuals can have access.

Most of this information is covered in TWikiAccessControl, but in testing this capability (mainly access control by topic), some subtle security issues have been identified. The following observations where made with Internet Explorer on a PC. Others may wish to verify it on other browser/operating system combinations.

Creating a page that only registered wiki users can read and only you can edit

In order to restrict a page to be visible only to registered wiki users and only a specific person can edit the topic, you can enter the following entry in the page

• Set DENYTOPICVIEW = People.TWikiGuest
• Set ALLOWTOPICCHANGE = People.YourWikiName

Noted side-effect for searches

A side-effect of placing those settings in the registered user restricted page is that if TWikiGuest ever tries to do a search of all public webs and one of the keywords happens to be in that page, they will be prompted to login. It can be a bit of an annoyance for the casual wiki users accessing our systems, but it may have the added benefit of forcing them to be registered.

I tried setting NOSEARCHALL = on, but that did not seem to have any effect in the search side-effect.

Note the security issues described below.

Creating a page that only a specified registered wiki users can read.

In order to restrict a page to be visible to a user or list of users, the following entry can be placed anywhere in a topic page

• Set ALLOWTOPICVIEW = People.RolandoRaqueno, People.TimGallagher

In the above example, only RolandoRaqueno or TimGallagher can theoretically view the page.

HERE'S THE CATCH

The reason we say theoretically is because there is a way, by the very nature of web-browsers, for someone else other than yourself to view that restricted page. In order to better understand this, let's go through the following scenario.

FIRST SCENARIO: We start a web-browser on a machine in which no user has logged in to the wiki

In this case, without logging in, we can browse all the unrestricted pages in the the CIS wiki system as TWikiGuest. We can verify this by accessing the link WelcomeGuest through the sidebar or other links. We see this page welcoming us as TWikiGuest.

Now if we try to access a restricted page that has the ALLOWTOPICVIEW set as above, the system will require us to login. If we login and we are not on that list, we will be denied from viewing the page.

SECOND SCENARIO: We login as one of the users in the ALLOWTOPICVIEW list

After successful login, we can now view that page and read or download whatever attachment happens to be on that topic page.

Now when we are finished, we close our browser to essentially "logoff" from the wiki.

Here comes the problem. Even though we've closed the browser, there is still some residual information that causes the browser to remember us (it's not in the browser cache or cookie stash) so that if we, OR ANOTHER PERSON , starts up the browser, it recognizes you from the previous login. This can be verified by visiting the page WelcomeGuest and seeing that it is no longer welcoming TWikiGuest, but the person who last logged in to the wiki from that browser.

While you (masquerading as the previous wiki user) are theoretically logged off from the wiki and cannot edit any pages, you can still view access pages in which the previous user is listed in the ALLOWTOPICVIEW list. So, all attachments will be compromised in this case.

-- RolandoRaqueno - 09 Dec 2004: There is an upside. Apparently, after some experimentation , the information regarding the wiki login will eventually become stale and subsequent browser invocations will revert back to TWikiGuest. It is not clear, however, when the cached information is purged from the system.

MORAL OF THE STORY AND A SOLUTION

Be careful which computer you use to post any sensitive information to the wiki. If at all possible, do not use a public computer. I currently do not have a solution or know of the specific file that needs to be modified or deleted to cause the previous user to totally "LOGOUT" from the browser. But for now, follow the suggested precautions.

If you use the DENYTOPICVIEW = TWikiGuest restriction, this security concern should probably not be an issue since any computer/browser that encounters this security issue is probably in an environment that can be trusted, i.e., in the CIS building or on campus. -- RolandoRaqueno - 08 Dec 2004

When using ALLOWTOPICVIEW access control, ALWAYS use ALLOWTOPICCHANGE

If you restrict viewing using ALLOWTOPICVIEW as shown below

• Set ALLOWTOPICVIEW = People.RolandoRaqueno, People.TimGallagher

It is always a good idea to set the ALLOWTOPICCHANGE also, i.e.,

• Set ALLOWTOPICCHANGE = People.RolandoRaqueno, People.TimGallagher

The reason for this is that even though they cannot view your page, an attempt to edit this page will cause the page to be locked out for an hour keeping the people on your list from editting the page.

Common Problems

Specifying Set variables multiple times

A common user mistake that prevents the desired access control to be invoked is the multiple definition of any of the access control variable, i.e.,

• Set ALLOWTOPICVIEW = People.RolandoRaqueno, People.TimGallagher

is the correct method of specifying limited access control and is not the same as

• Set ALLOWTOPICVIEW = People.RolandoRaqueno
• Set ALLOWTOPICVIEW = People.TimGallagher

The latter case only allows the user People.TimGallagher to access a given page because the second Set statement overrides the previous statement which gave People.RolandoRaqueno access to the topic. Access is effectively denied for People.RolandoRaqueno as a result.

-- RolandoRaqueno - 19 Jan 2006