Tags:
archive_me1Add my vote for this tag create new tag
view all tags
Related Topics: WebAdmin, AdminToolsDev, ScriptToCreateNewWeb, TrashCanWeb, HostileUsers

TWiki based group authentication is a flexible approach, and detached from user authentication. Users still get authenticated the same way, based on web server authentication (or alternatively it could be cookie based). Certain functions, like performing WebAdmin functions, or permission to edit certain topics can be restricted based on group authentication.

Group authentication can be made like this (intended as RFC) :

(deleted, superceded by spec below)

  • Open question: It makes sense to restict a whole web to be editable only by a certain group or groups. How to define?

-- PeterThoeny - 20 Jul 2000

Concerning the last point: a simple authorization scheme, compatible with present implementation of twiki, is described in UserAuthorizationSchemes

-- FrancoBagnoli - 04 Sep 2000

Here is the spec for authentication based on groups, intended as an RFC. My goal is to have a flexible and powerful way of allowing and restricting view, change and creation of topics, with a selectable granularity (per web or per topic). Ease of use and intuitiveness are important too. (Feedback is appreciated.)

  • Access restriction based on groups will be implemented, but use is discouraged unless necessary, because it goes against the free Wiki culture.

  • Groups can be defined in addition to users:
    • A group is defined as a topic in the TWiki.Main web.
    • The topic name ends in ...Group, i.e. TWikiAdminGroup
    • A "Set GROUP" bullet line defines the group members. Example:
      • Set GROUP = Main.PeterThoeny, Main.NicholasLee, Main.AndreaSterbini

  • There are two types of access restrictions:
    • Permission to view topics (applicable only if the whole TWiki site is authenticated, i.e. not for this TWiki installation here)
    • Permission to change existing topics or new topics

  • Access restriction (e.g. view, change, create) can be defined on two levels:
    • Access restriction defined in topic
    • Access restriction defined in Preferences

  • Access restriction defined in topic:
    • View permission can be set by a "Set ALLOWTOPICVIEW" bullet line somewhere in the topic (recommended to put at the end of the topic so that it is near the edit link). The line contains one or more users or groups (separated by comma) that have view permission. Example:
      • Set ALLOWTOPICVIEW = Main.TWikiAdminGroup
    • Change permission (e.g. edit topic or attach file) can be set by a "Set ALLOWTOPICCHANGE" bullet line somewhere in the topic. The line contains one or more users or groups that have change permission. Example:
      • Set ALLOWTOPICCHANGE = Main.SomeUser, Main.AnotherUser, Main.SomeGroup, Main.AnotherGroup
    • View permission should not be set on a per topic level, it is recommended to set it per web (if at all).
    • Of course, group topics in TWiki.Main should be protected so that not anyone can add him/herself to the group wink   Example for the TWikiAdminGroup topic:
      • Set ALLOWTOPICCHANGE = Main.TWikiAdminGroup

  • Access restriction defined in Preferences:
    • Preference variables to deny or permit access to view, change or create topics are defined on site level (TWikiPreferences) and on web level (WebPreferences).
    • The value is a comma separated list of topic names (user topics and group topics)
    • The DENYWEBVIEW preference variable defines persons or groups who are not allowed to view topics. Example:
         * Set DENYVIEW = Main.TWikiGuest
    • The ALLOWWEBVIEW preference variable defines persons or groups who are allowed to view topics. Example:
         * Set ALLOWVIEW = Main.TWikiAdminGroup, Main.AlbertEinstein
    • The DENYWEBCHANGE preference variable defines persons or groups who are not allowed to change or create topics.
    • The ALLOWWEBCHANGE preference variable defines persons or groups who are allowed to change or create topics.

  • Implicit sequence of checking access permissions:
    1. DENYTOPIC... topic variable overrides the DENYWEB... preference variable.
    2. Check DENY... variable. Deny access if person is in list.
    3. ALLOWTOPIC... topic variable overrides the ALLOWWEB... preference variable.
    4. Check ALLOW... variable.
      • If exists:
        • Check if person is in list. Grant access if it is, else deny
      • If line does not exists:
        • Grant access.

Ideas for implementation:

  • Create subroutine checkAccessPermission( $theAccessType, $theUserName, $theTopicText, $theTopicName, $theWebName) in wiki.pm :
    • The routine does the implicit sequence of checking access permissions.
    • Used by the view and rdiff scripts with $theAccessType = "view"
    • Used by the edit and attach scripts with $theAccessType = "change"
    • Used by the edit and attach scripts with $theAccessType = "create" in case topic does not exist.
    • The routine should be generic so that a new $accessType can be defined without changing the code. Examples are "synchronize" for replication, "delete" to delete topics or webs.

  • View permissions need to be considered for topic %INCLUDE%, i.e. user has access to view the topic where %INCLUDE% is standing, but not the included topic.

Questions:

  • How to handle mailnotify? Restrict by user?

  • How to restrict overriding of ALLOW... and DENY... site preferences? We could use AlWilliams' idea in LockedPages.

I will start working on the implementation soon. Feedback? Ideas?

-- PeterThoeny - 22 Sep 2000 (amended 23 Oct 2000)

Regarding Implicit sequence of checking access permissions

How about making the sequence explicitly specifiable as in apache's config?

deny from all
allow from Main.ManpreetSingh

or

allow from all
deny from Main.ManpreetSingh

etc. so that different kind of access can be specified more easily.

Or, how about looking at the various ways secure OSes specify how to grant/deny permissions? How about ACLs? (though I myself don't know a lot about them yet )? etc.

-- ManpreetSingh - 22 Sep 2000

A lot of what a Wiki does is common with WebDAV. WebDAV has an ACL based access control draft proposal in works.

See http://www.webdav.org/acl/ for details.

-- ManpreetSingh - 23 Sep 2000

We can use some ideas of WebDAV's ACL proposal. It is kind of a complex proposal, for TWiki it makes sense to use just a small subset initially and extend it over time. At some point in the future we can extend TWiki to be a TWikiWebDavServer.

-- PeterThoeny - 23 Sep 2000

First preparation step is done, see also BetterTWikiTagTemplateProcessing: In the preferences it is now possible to restrict overriding of ALLOW... and DENY... variables by setting a %FINALPREFERENCES% variable containing a list of variables that may not be overridden. Example:

  • Set FINALPREFERENCES = WEBTOPICLIST, DENYWEBVIEW, ALLOWWEBVIEW, DENYWEBCHANGE, ALLOWWEBCHANGE
  • Set DENYWEBVIEW =
  • Set ALLOWWEBVIEW =
  • Set DENYWEBCHANGE = TWikiGuest
  • Set ALLOWWEBCHANGE = TWikiAdminGroup
  • Set ALLOWTOPICCHANGE = TWikiAdminGroup

To do:

  • Create a new "module" wikiaccess.pm that handles access control. (It can be OO'zed at some later time once we have the modularization in place.)
  • Work on the checkAccessPermission function.

-- PeterThoeny - 28 Sep 2000 (amended 23 Oct 2000)

One of the Wikis I saw someplace had the concept of differentiating between appends (change), edits and creates. If append and edit are differentiated, we could allow, for example, guests to be only able to append to an existing topic. This would make the topic work like a bulletin board.

Thoughts?

-- ManpreetSingh - 28 Sep 2000

A text append mode is a logical extension to the TWikiAccessControl property and could be easily added by defining a new type of access restriction:

    • Permission to append text to topics, as opposed to:
    • Permission to change topics (edit, attach)

Is also a question of user interface. Add a Append link at the bottom of the page?

Regarding definition of a group and topic access restriction: I created two test topics to show that, TWikiAdminGroup and AllowChange. Please have a look at these topics and let us know here what you think about the syntax.

-- PeterThoeny - 28 Sep 2000

You could extend the Append idea to allow appends at various places in the page. There could be a special tag that you could embed in the page. When you click on it, text ends up being appended at that point. Each append tag could have optional attributes: an ID so that you could have multiple append points on a single page, an order attribute: "append before" (for oldest comment first ordering) or "append after" (for oldest comment last ordering), and other attributes to be defined in the future.

-- JamesThompson - 29 Sep 2000

A question: Why are we re-doing the authentication stuff of apache? We already rely on apache to authenticate the user ... Is'nt it easier to add a tool to manage .htaccess and .htgroup files?

-- AndreaSterbini - 29 Sep 2000

Well, authentication by the apache server is useful but access restriction using the .htaccess file is rather bad: you cannot easily allow view but not editing (I did it using Apache's Rewrite Rules, but it is quite painful).

Bytheway, I'm developing a mod_perl module to handle apache authetications so that I can check them against an existing sql database. I think that the same modulus could be used to replace the .htaccess file, so that one can use a complete wiki approach to usernames/password or restrict access on a per web/per page/per user basis. If someone is interested I can post the results.

However, with this approach one cannot forbid searches to enter directories, to accomplish this goal one has also to modify the scripts.

Concerning the append question: I partially solved it using subwebs, as described in the WebTeach topic.

An elegant way of adding a note to a given portion of a text without editing the text itself or embedding buttons could be the following:

Add an empty (small?) textarea at the bottom of the page. One can select a portion of the text and paste it into the textarea (the same one does with the signature). Then two buttons permit to add a note before or after the text. After that, one enters the text as usual (preferably in a different window, or in the same textarea as before, so to have the original portion of the text at hand). Finally, having the information of the previous pasted text (and hoping it occours only once) the note is added at the end (or in a sepatate reply topic) and a link is placed in the right position.

-- FrancoBagnoli - 30 Sep 2000

Using a textarea and asking the users to paste into it in order to append to text in the middle of a msg, is probably too much to ask for lots of the user community -- at least for mine. It needs to simple and foolproof: click here, fill in box, click submit.

It would be nice to automate the signature append too as part of the append here operation.

Is the "Append Here" function something could be implemented using TWikiPluginAPI

-- JamesThompson - 01 Oct 2000

Once I experimentd with a simple annotation scheme. It would simply add a small button at the end of ech paragraph, and once clicked it locked the original text, open a textarea in which to type the comment, add a link to the text and put the comment at the end. Were you thinking to something similar? Otherwise, I think you need java, since javascript is not able to detect the position of cursor iside a text.

I think that an automatic appending of signatures is feasible, but you have to remove it when not commenting.

In my opinion, if you are using twiki as a "message board", you should have a look at my "threaded" extension (see WebTeach), it is quite a click-type-submit solution.

-- FrancoBagnoli - 01 Oct 2000

I was thinking of something very similar to what you described. I was assuming that the automatic signature appending would only be turned on when using this append-here function. While you could use it for a message board, it seems like it would have other uses too. It could be implemented with a generalized function -- the click causes the current page text, user login name, etc. to be piped to an application that could then: ask for user input, process it, return an updated version of the page text.

WebTeach looks interesting but when I try to follow the link on the WebTeach page, it asks for a user name/password.

-- JamesThompson - 02 Oct 2000

Sorry, I'm actually working to WebTeach since it should "open" in a few day and it changes everyday.

I'll update the link so to allow people to read about the project without actually entering the site.

-- FrancoBagnoli - 02 Oct 2000

I implemented authentication based on groups following the above guidelines. You can find it on WebTeach.

-- FrancoBagnoli - 18 Oct 2000

I will look at your contribution Franco. As mentioned I am currently working on the implementation, and in fact it is almost done, just some more finishing touches before it goes into the Alpha repository.

-- PeterThoeny - 21 Oct 2000

First step of access control is implemented and commited to TWikiAlphaRelease:

  • Changed script files attach, edit, save, upload and wiki.pm
  • New template files oopsaccesschange.tmpl and oopsaccessview.tmpl

It is possible to deny and grant topic changes in any web by specifying the following in the WebPreferences topic:

  • Users or groups who are not / are allowed to change topics in the Codev web: (See TWikiAccessControl)
    • Set DENYWEBCHANGE = <list of users and/or groups>
    • Set ALLOWWEBCHANGE = <list of users and/or groups>

A topic itself can override the access controls defined in WebPreferences:

  • Users or groups allowed to change the topic:
    • Set ALLOWTOPICCHANGE = <list of users and/or groups>

Groups are defined in the Main web as group topics. A group topic name ends with "Group", i.e. TWikiAdminGroup. The group topic itself should define two Sets:

  • Set GROUP = <list of users and/or groups>
  • Set ALLOWTOPICCHANGE = <name of topic>

GROUP defines the members of a group. It is a comma delimited list of users.
ALLOWTOPICCHANGE makes sure that only members of the group can change the topic, so that other people cannot add themselfs to the group wink

Groups can be nested; recursion is prevented.

The TWikiAccessControl topic in the TWiki web should describe access control in detail (doc is pending)

To do:

  • Document access control in TWikiAccessControl
  • Implement view access control (already done in wikiaccess.pm; needs to be added to view, %INCLUDE%, ...)
  • Test more

-- PeterThoeny - 23 Oct 2000

I forgot to add wikiaccess.pm to the TWikiAlphaRelease CVS repository - sorry. Has been done now.

Also, test change permission in the TWiki.Test web:

-- PeterThoeny - 23 Oct 2000

I set the classification to FeatureDone since write protection based on groups has been implemented and is part of the 01 Dec 2000 production release.

One pending feature is to read protect pages, follow up in ReadAccessPermission

-- PeterThoeny - 26 Nov 2000

I implemented a read access restriction for a whole TWiki web. It is now possible to place restrictions of who is allowed to view a TWiki web.

Define one or both of these variable in the WebPreferences topic:

  • Set DENYWEBVIEW = < list of users and groups >
  • Set ALLOWWEBVIEW = < list of users and groups >

Some remarks on read access restriction:

  • Read access restriction only works if the view script is authenticated, that means that users need to log on also just to read topics. TWiki Installation has more on basic authentication based on the .htaccess file.
  • There is a workaround if you prefer to to have unrestricted access to view topics located in normal webs, and to authenticate users only for webs where view restriction is enabled:
    • Leave the view script non authenticated in the .htaccess file.
    • Enable the $doRememberRemoteUser flag in wikicfg.pm as described in TWiki Authentication. TWiki will now remember the IP address of an authenticated user.
    • Copy the view script to viewauth (or better, create a symbolic link)
    • Enable authentication for the viewauth script in the .htaccess file.
    • When a user accesses a web where you enabled view restriction, TWiki will redirect from the view script to the viewauth script once (this hapens only if the user has never edited a topic). Doing so will ask for authentication. The viewauth script shows the requested topic if the user could log on and if the user is authorized to see that web.
  • If you enable view restriction for a web, it is recommended to restrict search "all webs" from searching this web. Enable this restriction with the NOSEARCHALL variable in its WebPreferences, like:
    • Set NOSEARCHALL = on
  • It is not recommended to restrict view access to individual topics since all content is searchable within a web.
  • The view restriction is not suitable for very sensitive content since there is a way to circumvent the read access restriction.

Commited to TWikiAlphaRelease and made a TWikiBetaRelease.

-- PeterThoeny - 20 Jan 2001

Edit | Attach | Watch | Print version | History: r30 < r29 < r28 < r27 < r26 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r30 - 2005-02-15 - SamHasler
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.