Question

To enhance security, my company wants to set up authorization for individual webs. For example, if we have 2 webs underneath Main, say ThisWeb and ThatWeb , we want to have our TWikiUsers for ThisWeb authenticate only on ThisWeb, not ThatWeb and not Main. I know that groups and users offer lots of control here, but my boss feels that anyone with some knowledge of TWiki could get into the main web and make themselves an admin.

Is it possible to move the .htaaccess method into subwebs? Is it best just to configure it through httpd.conf? Is it best to have several different TWiki installations? Should I get a manicure? So many questions .

• TWiki version:12 2001
• Web server: apache
• Server OS: Debian
• Web browser: various
• Client OS:

-- HowardHolden - 16 Oct 2002

Answer

Sounds like the real problem is your boss 'feeling that anyone could become an admin'... Have a look at SoftSecurity as well - sounds like he is operating in the hard security model.

As for your question, I'm not sure how you could do this easily - you could just have several TWiki installations of course, or you could create sub-bin directories (see the TWiki web for some info on how to do this) using symbolic links to the real scripts. Then you could create .htaccess files in the sub-bin directories. Fairly horrible, and perhaps someone has a better suggestion, other than 'don't do it!!'

-- RichardDonkin - 17 Oct 2002

I agree with RichardDonkin, the hard security model under which TWiki runs is:

• Apache security is applied to the individual TWiki scripts (view, edit, etc.) as per TWikiAccessControl
• Basic security checks are carried out inside the scripts themselves for the webs and topics (this has some holes, though).

So, no, there is no easy way to apply Apache security to the individual topics and/or webs handled by the TWiki. If you still want to go down this path, I would suggest:

• Alternative 1 (easier to deploy, but hard to automate, mantain, and use)
  1. Divide the different webs into different apache paths, being handled by diferent configured TWikies. These paths could be populated, as Richard suggests, by symlinks except for the all important .htaccess and TWiki.conf files.
  2. Create a home page that has the appropriate links for each one of the different TWikies.
• Alternative 2 (harder to deploy, but easier to mantain and use)
  1. Proceed as alternative 1 above
  2. Modify the source code of the TWiki scripts (at the very least the view script) to recognize the different webs and security domains to route links apropriately (you might need some syntax extensions in the setting pages to facilitate the total management process)
  3. Modify the code to use a more secured down version of the global configuration pages, like WebPreferences.
• Alternative 3 (complicated infrastructure, but avoids the modification of the TWiki itself)
  1. Place a proxy in between all your TWiki traffic, that recognizes the different web hierarchies, and applies the right policy checks to them (this should be doable inside Apache).

But anyway, basic security can go a long way, and as long as the twiki code has no access to critical functions (i.e. chrooted, or at least runs under suExec in Apache), your .htacces file hierarchy is reasonable (the standard TWiki .htaccess policy is fairly lax), and the really security-critical applications are kept separate, I would say that the code is very secure.

If the only problem is the possibility of someone becoming and administrator, the simple unix solution would be to change the ownership and permissions of the the TWikiAdminGroup topic, after it has been configured through the TWiki.

-- EdgarBrown - 31 Oct 2002

Thank you, Gentlemen.

-- HowardHolden