Do we miss one level in our access control scheme to control who can change the access control settings at the topic level ?

Hi all,

As new to TWki I spent some time working on a project with it and I'm quite happy because of this unique feature of buildings small applications. That said I'm also thinking about other project I could do with TWiki and I fall on some access control requirements.

I understand that we have access control at the webs level, that can be overwritten at the topic level. I also understand that the only way to control who can change the topic access settings is to control who can make change in the topic (that is to say edit and add attachment) and this is where IMHO come the big issue. If you want people to still be able to contribute to a topic, in my understanding (but I may be wrong), for example, there is no way to guaranty that one won't change the settings and make public something that must stay private, unless the all site is lock !

At the enterprise level this a no go issue.

If we still want to deal with the wiki way and also face some security requirements we must have something that gives the ability to control who can change the access settings at the topic level. Unless that, site with public and private topics will never be fully secure because we will never be able to guaranty that the access settings will never be changed in the wrong way !

Many CMS and wikis don't have strong ACL that meet the enterprise or project requirements. IMHO this a must have for any apps targetting the enterprise level otherwise we can't be trust !

Any thought ?

-- Contributors: EricCharikane - 30 Oct 2007

Discussion

Hi Eric,

If your concern is to left private content private, then an access control setting will not solve the problem. Anyone with access to private content can make it public, by many ways: creating another topic with content, mail content to a public list, print and distribute, etc.

If your concern is to avoid that accidental changes make a private topic public, you can set the access preference on meta information, instead of topic content ("More topic actions" => "Edit settings"). I'm sure this work on 4.1.1 and later, I don't know about older versions. This way people can contribute to the topic content without the risk of changing the access preference, that is specified within meta text, separated from topic content.

But if someone changes access preference, even if it is set within meta text, then, thanks to revision control, it will be possible to know who made the change and take necessary actions (probably specified within some information or security policy of the organization).

-- GilmarSantosJr - 30 Oct 2007

What Gilmar says is 100% correct. Both technically and the other thoughts.

The Edit Settings way to protect topics prevents accidental changes. But if you want to prevent users from changing access rights, then it is not a wiki you are looking for. Wiki's work by soft security. That is the whole idea. I see too many traditionalist users adding stupid access rights simply by "we have always done that". And I keep removing them when I see them. The whole wiki idea builds on teamwork and trust. TWiki is about collaborating and allowing anyone to create new powerful applications. TWiki is about creating value and opportunities. Dumb CMS type websites are about turning people into trivial robots. TWiki contains the access rights you need in a business environment. You can keep private information private. You can prevent editing (which is a bad thing to do in general with very few exceptions). And you can lock WebPreferences and some of the topics newbies modify by accident because they fumble around. Like the UserForm. And you can lock site level preferences. But the principle that if a person has write access he also has access to change the access rights is a really powerful thing and it prevents over protective IT managers from taking away the most powerful part of TWiki - the empowerment to create and innovate.

I use TWiki in a large corporation and for business purposes and the access rights we have in TWiki are more than adequate.

A good advice is to use a single sign on authentication scheme like LDAP and disallow viewing to anyone not authenticated. This makes a warm fuzzy feeling among managers and IT staff that the basic security level is always high and that removing an access setting never open reading to a non-employee. And once you have this, try and limit any other access rights to large groups. Groups are easy to manage and the group based access rights ensures that at least among the groups people can collaborate freely. Make sure you cannot authenticate as TWikiGuest.

TWiki's security idea is the combination of

• In general we trust you BUT
• We know who you are
• We know exactly what you did (and you know that we know)
• We can revert to any earlier version if you accidently do something
• We can add access rights to viewing as well as writing when things need to be confidencial or we need to protect accidents.

You do not release the power of TWiki by implementing it for a single totally locked down application. You release the innovation and collaboration in ways you never imagined by keeping things as open as possible. Give the first teams a good 1 hour intro training and coach them the next months. And after one year you will wonder how you lived without it and you will see people creating one small application after the other that fits THEIR needs. It is amazing the power of Wikis. But you have to let go of the traditional CMS thinking. Wikis are not a CMS with an edit button. They are much more. And TWiki is in a business environment absolutely fantastic.

-- KennethLavrsen - 30 Oct 2007

Kenneth, you build upon Gilmar's comment in a clean and understandable way. Well put!

-- PeterThoeny - 31 Oct 2007