Difference: TWikiAccessControl (41 vs. 42)

Revision 422014-07-04 - TWikiContributor

Line: 1 to 1
 

TWiki Access Control

Line: 19 to 20
 
  • Peer influence is enough to ensure that only relevant content is posted.
  • Peer editing - the ability for anyone to rearrange all content on a page - keeps topics focused.
  • In TWiki, content is transparently preserved under revision control:
Changed:
<
<
>
>
    • Edits can easily be rolled back to a previous revision if needed.
 
    • Users are encouraged to edit and refactor (condense a long topic), since there's a safety net.
Added:
>
>
 As a collaboration guideline:
Added:
>
>
 
  • Create broad-based Groups (for more and varied input), and...
Changed:
<
<
  • Avoid creating view-only Users (if you can read it, you should be able to contribute to it).
>
>
  • Avoid creating view-only topics (if you can read it, you should be able to contribute to it).
 

Permissions settings of the webs on this TWiki site

Added:
>
>
 

Web Sitemap VIEW CHANGE RENAME
  Listed DENY ALLOW DENY ALLOW DENY ALLOW
Preferences Home Main on            
Preferences Home TWiki on       TWikiAdminGroup   TWikiAdminGroup
Preferences Home Sandbox on            

Please Note:

  • A blank in the the above table may mean either the corresponding control is absent or commented out or that it has been set to a null value. The two conditions have dramatically different and possibly opposed semantics.
  • TWikiGuest is the guest account - used by unauthenticated users.
  • The TWiki web must not deny view to TWikiGuest; otherwise, people will not be able to register.

Line: 233 to 237
 

Dynamic access control

Changed:
<
<
This feature is regarded experimental. There are pitfalls and vulnerability.
>
>
There are pitfalls and you need to harden your web to avoid unexpected access.
 Before using this feature, please read this entire section through carefully.

You may want to restrict access dynamically -- based on topic name, a form field value, or some combination of factors.

Line: 243 to 246
 

Example 1 - restriction based on topic name

Changed:
<
<
Let's assume you need to restrict changes only to the CroniesGroup members excep with topics whose name ends with Public, which need be changed by anybody. That is achieve by the following settings on WebPrefences.
>
>
Let's assume you need to restrict changes only to the CroniesGroup members except with topics whose name ends with Public, which need be changed by anybody. That is achieve by the following settings on WebPrefences.
 
   * Set DYNAMIC_ACCESS_CONTROL = on
Line: 254 to 257
  Let's assume:
  • a web storing requests on topics whose name starts with ReqEnt
Changed:
<
<
  • Each request topic has a form field "Requstor", which has the wiki name of the requestor
>
>
  • Each request topic has a form field "Requestor", which has the wiki name of the requestor
 
  • Users can view only requests they created
  • The members of the SupportGroup mail group can view all requests
Changed:
<
<
That is achieve by the following settings on WebPrefences.
>
>
That is achieve by the following settings on WebPreferences.
 
   * Set DYNAMIC_ACCESS_CONTROL = on
Line: 319 to 322
 
  • USERNAME
  • WIKIUSERNAME
Changed:
<
<

Vulnerability

>
>

Avoiding vulnerability

By default, user level preferences are read before web level preferences. This means a user can set a preferences variable at the user level and finalise it. To prevent this sort of attack, you need to harden your web or site by disabling user preferences by e.g. having the following line on lib/LocalSite.cfg

$TWiki::cfg{DemoteUserPreferences}= 1;
and having the following line on your WebPreferences and then finalise DENYUSERPREFEENCES.
   * Set DENYUSERPREFEENCES = all
Please read TWikiVariables#ControllingUserLevelPrefsOverride for details.
 
Changed:
<
<
It's possible to redefine function tags such as %IF{...}% in your personal preferences. In a future release of TWiki, a way to prevent function tags from being overridden by personal preferences will be provied. But until then, you need to be well aware of this vulnerability.
>
>
Again by default, predefined variables such as %IF{...}% can be overridden by preferences variables. If user preferences are disabled, ordinary users cannot attack using user preferences, but topic level preferences may cause unexpected consequences. As such, all predefined variables need to be made un-overridable by having the following line on WebPreferences and then finalise OVERRIDABLEPREDEFINEDVARIABLES.
   * Set OVERRIDABLEPREDEFINEDVARIABLES =
Please read TWikiVariables#PredefinedVariables for details.
 

Disabling dynamic access control

Line: 439 to 459
  It is possible to turn the PatternSkin and TopMenuSkin into read-only mode by removing the edit and attach controls (links and buttons). This is mainly useful if you have TWiki application pages or dashboards where you do not want regular users to change content. The read-only skin mode is not a replacement for access control; you can use it in addition to access control. Details at PatternSkinCustomization#ReadOnlySkinMode.
Added:
>
>

Configuring access control for topics of a certain name in all webs

You may need to restrict access to topics of a certain name in all webs. For example, there might be an add-on refering to a certain topic of all webs. And the add-on does things only administrators are supposed to do. In that case, change to the topic needs to be restricted only to administrators and must not be overridable.

Let's say there is AutomationAddOn which refers to WebAutomation of all webs. And WebAutomation needs to be modifable only by administrators. That can be achieved by the following configuration.

$TWiki::cfg{Access}{Topic}{WebAutomation} = {
    DENYCHANGE => 'Main.AllUsersGroup',
};

In addition to ALLOWCHANGE, you can sepcify DENYCHANGE, ALLOWVIEW, DENYVIEW, ALLOWRENAME, and DENYRENAME as follows.

$TWiki::cfg{Access}{Topic}{SpecialTopic} = {
    DENYVIEW  => 'JoeSchmoe',
    ALLOWVIEW => 'FooGroup',
};

$TWiki::cfg{Access}{Topic}{TOPICNAME} has precedence over DENYTOPIC* and ALLOWTOPIC*. For example, if the configuration for WebAutomation is there as above, there is no way to allow non-adminsitrators to change the WebAutomation topic of any web.

As a way to configure access control, this may look crude. The reason why configured this way is that this can be part of plugin/add-on/contrib's configuration. For example, Config.spec of AutomationAddOn would have the following lines, with which proper access control to WebAutomation topics is implemented without the administrator knowing it.

$TWiki::cfg{Access}{Topic}{WebAutomation} = {
    DENYCHANGE => 'Main.AllUsersGroup',
};
 

Related Topics: AdminDocumentationCategory, TWikiUserAuthentication, AllowWebCreateByUserMappingManager, UserMasquerading, CustomUserGroupNotations, TWiki:TWiki.TWikiAccessControlSupplement

-- Contributors: TWiki:Main.PeterThoeny, TWiki:Main.MikeMannix, TWiki:Main.CrawfordCurrie

Changed:
<
<
META FILEATTACHMENT attachment="access-denied.png" attr="" comment="" date="1366771092" name="access-denied.png" path="access-denied.png" size="32745" user="TWikiContributor" version="1.1"
>
>
META FILEATTACHMENT attachment="access-denied.png" attr="h" comment="" date="1366771092" name="access-denied.png" path="access-denied.png" size="32745" user="TWikiContributor" version="1.1"
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 1999-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
Note: Please contribute updates to this topic on TWiki.org at TWiki:TWiki.TWikiAccessControl.