Question

• TWiki version: (TWiki version: 01 Feb 2003)
• Perl version: 5.6.1
• Web server & version: Apache
• Server OS: SunOS + Linux
• Web browser & version: Internet Explorer 6.0
• Client OS: Windows XP

I admit to overall ConfusionAboutAuthentication; this is one particular aspect.

My company's IT group would like me to use the htpasswd file they administer, /home/www/htpasswd/.htpasswd.FOO (for which they do neat things like automatically keeping it in synch with the UNIX passwd file, etc.)

I'm using this successfully. It required me to put a .htaccess.FOO file referring to this password file in a directory leading up to my TWiki installation. It asks me for passwords when I start.

I could add my own .htpasswd file, but prefer not to.

Q: is this what you mean by "If the server is authenticated"?

Q: do I need to move TWikiRegistrationPub to TWikiRegistration? Or is that obviated by use of the company .htpasswd?

My guess is that, when I am using IT group mandated authentication as above, TWikiRegistrationPub is irrelevant, as are all the TWiki pages that talk about changing passwords, etc., inside TWiki.

I need to restrict access to particular topics and webs. Insofar as I understand the twiki documentation, I need to add appropriate .htaccess.FOO files in the web's data directories.

Q: are these .htaccess.FOO files interpreted by Apache, or by twiki? I assume the former, but admit that I cannot see how that would arise, since Apache has already given control over to the twiki cgi-bin scripts.

Q: if I am using the official server side authentication, not the authentication built in to twiki, can I still use .htaccess.FOO files in twiki's webs?

See comments I have added at the bottom of ChangePassword: so far as I can tell, ChangePassword applies to some, but not all, configurations of TWiki (and is quite confusing because of this).

My apologies if that was not appropriate to do.

-- AndyGlew - 03 Apr 2003

OK, I am slowly figuring this out (would help if I was not interrupted).

A .htaccess type of file in, e.g., the cgi directory that contains the TWiki Perl scripts (or, in my case, in the cgi directory that contains setgid scripts that exec the TWiki Perl scripts, see ArrangingOwnershipOfTWikiFiles) is interpreted by Apache.

This file may specify authentication, e.g. by pointing to the company .htpasswd file, and specifying something like "require valid-user". It may also do some access control.

Thereafter, once the TWiki scripts are running, TWiki access control using the ALLOW/DENY variables in webs and topics is done. It may use either the "official" webserver authenticated user IDs, or it may use the TWiki internal user IDs.

The large number of TWiki topics that assume that only TWiki internal authentication exists is confusing.

I still have a problem: I can use webserver authentication "require valid-user" and TWiki access control. However, if I use "allow to all" for most of the wiki, by the time I get to a denied page I seem to have no opportunity to log in using the webserver authentication.

-- AndyGlew - 11 Apr 2003

Answer

What is meant by "if the server is authenticated" is exactly that: it's entirely possible to configure TWiki on a server to not use any authentication at all, and just let everyone do anything.

To answer one of your questions: you do not want to overwrite TWikiRegistration with TWikiRegistrationPub; you are correct in assuming this is obviated by using the company .htpasswd. With TWikiRegistrationPub, TWiki will attempt to manage the .htpasswd file and expect write access to it. With the default, it assumes (correctly in this case) that the registration file is managed externally. And you're right to assume that all the password-changing TWiki stuff is both irrelevant and nonfunctional in this case.

What you should have it set for is to use authentication on all of the binaries.

Why need registration at all? Because the TWiki authentication system depends on the existence of TWiki users...so every company user needs to sign on and register to generate a linked TWiki user account that they're then automatically referred to from then on. Apache interprets the .htaccess file, and tells TWiki only one thing - the logged-in username. TWiki will then do a lookup to find the linked TWiki username (by default the same as the login, but different in case the login isn't a WikiName). THEN TWiki will be able to look up what TWiki groups the user is in and from there what they're allowed to do.

Also note that the ALLOW/DENY variables are hierarchial: the ones in TWikiPreferences are overridden by the ones in WebPreferences which are overridden by the ones in a topic. Generally though, you want to set them up to allow view access to anyone I think - since your company's authentication is used, anyone who can actually access the view script to see a topic has a valid username/password. I'm not entirely sure how user and group settings interact when both apply; best thing is probably to avoid situation, but I'd imagine user settings should override group settings.

I've closed this request, but if this isn't clear enough or you have further concerns just reopen it when you reply on the form at the bottom.

-- WalterMundt - 11 Apr 2003

Minor quibble:

• What is meant by "if the server is authenticated" is exactly that: it's entirely possible to configure TWiki on a server to not use any authentication at all, and just let everyone do anything.

I think the phrase in question should be "if the server uses authentication".

The phrase "the server is authenticated" means that the server, e.g. the apache httpd webserver, has authenticated itself to the user, e.g. by engaging in challenge/response with a user smart card.

Or, possibly, that the twiki cgi scripts, which you might call the twiki server, have authenticated themselves to the apache httpd webserver, e.g. by passing on a password received from the user.

I frankly suspect that the phrase "if the server is authenticated" was written by a non-native English speaker. My suspicion is weakened by the fact that I think the apache pages have similar text, but I am pretty confident that is not correct usage, in English, of security related terminology.

I think it should be changed to read more clearly.

It helps a lot it you seperate out the two concepts of

• Identifcation

• Authentication

Data can be "authentic" - that is having the quality of integrity. It may have a MD5 checksum that is correct. But its "label", its name that says whether its a Linux CD ISO image or and update to a dtabase of credit card information is seperate from that.

The problem - the confusion - is that we often tie identification and authentication together, sometimes in a way that makes the latter meaningless. For example, relying on a cookie or an IP address is only identification, the authentication is "automatic". Since its easy to fake-out (aka spoof) both cookies and IP addresses this method should not be used except for closed private communities.

Twiki has a great potential for granularity and configurability of access control. That is the application level. It is seperate from the access control performed by Apache.

The Apache layer, be it in httpd.conf or the localized .htaccess deals only with whether the server is allowing access to files and scripts. It is a system level function.

TWiki's own groups and userid mechanism is an application level function. It is also configurable at the appication level. However it relies on the Apache functionality for identification, which it may map to its own internal name scheme (see TWiki.pm).

This may be "obvious", but it seems a lot of confusion has arisen and some discussion threads do not adequately draw those boundaries.

To sumamrise:

1. Identification need not automatically mean authentication
2. Apache does the identification
3. Apache config controls access to the CGI scripts
4. TWiki's access control determines if a particular topic can be viewed, edited, moved, etc

Yes, this is all "obvious", but keeping those basic principles and separation of duties in mind cuts though much of the confusion that seems to have arisen.

See TWikiAuthenticationMethods

-- AntonAylward - 14 Jun 2003

There are different terminologies for the same things. The TWiki docs use:

• "Authentication" (find out who the user is)
• "Authorization" (grant or deny access once user is authenticated)

-- PeterThoeny - 14 Jun 2003