access_control1Add my vote for this tag create new tag
, view all tags

Better Access Controls

Access controls in TWiki need to be thought hard about. The present scheme works, mostly, but is clunky and inefficient.

It would (IMHO) be infinitely better to take access controls out of band, both in terms of topic storage and in terms of code. By that I mean that the :

syntax (which overloads and directly conflicts with TWikiVariables syntax) should be retired, and replaced with a scheme where topics, revisions and attachments (in fact any database atom) can be controlled by an access control list that is not embedded in the topic text. In terms of code it means that the whole access control scheme should be modularised such that a TWiki core can be built that does not support access control (useful, for example, for PIM and TIM TWikis)

-- Contributors: CrawfordCurrie


I am fine if the access control is taken out of the visible text and put into TWiki meta data if there is support for existing access control settings in topics.

Taking access control completely out of band has one issue that audit trail is not simply one atomic action on the topic text. Audit trail can probably bolted on top if taken out band, but that sounds like code bloat.

-- PeterThoeny - 16 Feb 2006

The current access control mechanism may be clunky - but is it really inefficient? In case of a PIM checkAccess is practically a no-op because I can set $TWiki::cfg{UseClientSessions} to off. There aren't any ALLOWfoobar variables in any topic in my PIM.

New wikizens seem to easily grok the current access control mechanism, and they seem to find out for themselves how to embed their access control into HTML comments to take them out of the visible area.

I can see some drawbacks of the current mechanism (most important first):

  1. A more formal way to enter access control data, say, via a form in oopsmore, could reduce the probability of user errors when entering their access control data (was that ALLOWTOPICHANGE?)
  2. Access control lists are topics, which need to be TML-parsed - which is considerably slower than a more formal data storage would be.
  3. Having the access control in the topics creates a fixed relation between the right to write content and the right to manage access. This isn't how Unix or Windows access control work.

Given that there are a gazillion of TWiki pages in the wild controlled by today's access control: Adding a new mechanism, however clever, would add to the complexity from a user's or TWiki admin's point of view. I'm shuddering at the mere thought of the unit tests we'd have to design....

-- HaraldJoerg - 16 Feb 2006

The solution is to have "pluggable" access control implementations. The default should be the current mechanism. A small improvement could be extract the access control from the topic when it's being saved into a more appropiate storage.

-- RafaelAlvarez - 16 Feb 2006

Please take care that the "pluggable" solution doesn't create more problems than it solves, especially when moving things out of today's core: PluggableIsHarmful

-- HaraldJoerg - 17 Feb 2006

The terminology may be confusing, but by "pluggable" I don't mean "by using a plugin". I mean something more in line with "pluggable implementation", much like what was done for the password management.

-- RafaelAlvarez - 17 Feb 2006

hi there..

We are using tiwki 2004. Now every time user create his web page, it add on to a huge .acl file that we already are maintaining. Also if user want to do some modify the restriction on a page, they have to contact the admin group. I would like to know if it is possible that we could let the user manage the access to their own pages following below criteria.

1. Authentication v's Access Control

Authentication will still have to be done against the our corporate server.

However, the access control should move to the pages themselves. That is, me be we should just be able to add special access-control markup to the pages when editing them.

May be we can stop using .acl file.

To do this, do we need a newer version of TWiki. I don't know for sure. If we need than, how about migrating from TWIki 01 Sep 2004 to the current stable version available from http://TWiki.org.

I have read that upgrading TWiki is not always easy.

Please tell me what should i do ASAP.

Thanks and Regards

-- SapinAmin - 14 Jul 2008

Maintaining a .acl file that the user has to ask the admin group to setup.

What horror. How un-wiki. Who the heck introduced a thing like that in your company (don't answer).

Using the standard ALLOWTOPICVIEW and ALLOWTOPICCHANGE feature that also existed in Cairo (The 2004 version) is what you should have done from the beginning.

Since TWiki 4.0 you can now also apply access control settings in "Edit Settings" under the "More topic actions" which makes them hidden in meta instead of being in the topic text. This ensures that the user does not delete them by mistake but still gives the user the access to set them up - like it should be on a wiki.

Using a setup where an admin has to be contacted on a wiki is the same as killing a wiki from the beginning. That is absolutely not recommended.

If an admin setup a wiki which contains corporate confidential information for a specific project then TWiki provides this feature in an easy and efficient way.

You assign a web to be secured. In WebPreferences you define an ALLOWWEBVIEW = SomeGroup and ALLOWWEBCHANGE = SomeGroup

And then in the Main web you create a group topic where you add all the project members. You now have a secure web in which all topics by default are visible only to this project group without the group having to remember to setup access rights for every page. And later it is dead easy to add an additional person simply by editing the group topic.

You can do all this with the 2004 version. If you want to upgrade then wait for the 4.2.1 version out in a few weeks.

It is not difficult to upgrade from 2004 to 4.2.1. But you should always follow the upgrade guide and you should always - even if it is easy - reserve a good working day for the job on a weekend.

-- KennethLavrsen - 15 Jul 2008

There's one other point to keep in mind. TWiki's startup procedure is a resource hog, mostly because it creates the internal representation of all - I mean ALL - WebPreferences, which includes the ACLs as well. This happens on every click. This is a typical "Look, mummy, I just found the same WebPreferences again" and needs to be avoided. Moving out the ACLs in some sensible way might be an opportunity to do that. However, caching WebPreferences all together would do that as well.

In any case, we can't leave things as they are today. Just to get the facts right: each click reads every WebPreferences in every web, mostly just to please WEBLIST. But that does not matter infact. Point is, that inside this mess, ACLs are created along the way, because they are modelled the way it is today. That's why I think we really do need action in this area to get a BetterAccessControls - last but not least in the sense of performance.

-- MichaelDaum - 15 Jul 2008

Note that I was answering Sapin's question. Naturally in a new storage model the access controls and preferences has to be in indexed database so we avoid walking through every file again and again. I think we all agree on that. Crawford's proposal is from 2006 - way before the storage model was debated. But for sure addressing this problem is what the RoadMap addresses already. But for Sapin the problem was to allow the users to setup access controls and here it seems the admin that setup the old Cairo made some strange authentication setup that prevents using the normal access controls

-- KennethLavrsen - 16 Jul 2008


First of all Thanks to Kenneth and Michael for the answers.

After reading the comments for my questions, i had few other doubts..

→ We only have to add an entry to the web server .acl file when a user wants a file restricted. By default all pages are open until someone requests a restriction.

Our .acl file has nothing to do with TWiki. It's part of the web server configuration.

We still need to authenticate against the corporate LDAP server [not part of TWiki] but use TWiki's access control features (instead of the web server .acl file).

In the forum - don't confuse 'ACL' [TWiki's access control list] with our .acl - which is a separate thing entirely.

So, finally my question is:

"For Twiki version 2004, can we continue to authenticate against our corporate LDAP server - but use Twiki's access control directives, like ALLOWTOPICVIEW and ALLOWTOPICCHANGE etc. - and remove our web server .acl file? If so, how?"

Thanks and Regards,

-- SapinAmin - 18 Jul 2008

Sapin, I think you are asking a question here that should really be directed to the Support web. The access controls in TWiki 2004 (Cairo) work just the same as in the latest TWiki version, and the work required to migrate from your .acl solution to TWiki access controls is the same in both versions. As far as I am aware there is no "out of the box" solution to your problem (but I'd be happy to help you develop one).

A more interesting question is "how could you integrate your existing .acl implementation with TWiki". Right now there is no simple way to do this, but if you are interested in helping develop an external ACL solution, read on.....

Back to the original topic; "Crawford's proposal is from 2006 - way before the storage model was debated" - the storage model has been openly debated since at least 2001 and probably before that. I never envisaged moving access controls into TWiki meta-data; to me that's pointless, as the access control module would still have to read every topic. What I had in mind was something more like the code I implemented for the WebDAVPlugin, which uses an external database to cache the access control information.

  1. Non-TWiki code can efficiently access the access control information. In the case of the WebDAVPlugin, the twiki_dav Apache module uses the cache to control DAV access to topics and attachments (c.f. Sapin's questions).
  2. The actual implementation of the access control DB is "pluggable" in the way that Raf was alluding to above. The store module is a client of the access controls, not an provider of them. You can implement the access control module however you like independently from the store e.g. as a web service.
  3. Integration of external acl implementations, such as the one described by Sapin, becomes feasible.

BTW I never answered Peter's (very valid) point about audit trail. Yes, that's correct, changes to ACLs at the moment leave an audit trail, and that's a valid requirement. A related and highly relevant requirement that TWiki currently fails to deliver on is the ability to change access controls on old revisions.

  1. Change access controls on prior revisions (e.g. to allow a new staff member to read topic histories)
  2. Audit trail of access control changes, showing who changed what and when

-- CrawfordCurrie - 18 Jul 2008

Edit | Attach | Watch | Print version | History: r15 < r14 < r13 < r12 < r11 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r15 - 2008-07-18 - FranzJosefGigler
  • 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-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.