[unix4ever]

Security with HTTP Authentication

You probably don't want to allow open access to certain parts of your web interface. In many cases, you may want to restrict access to everything. HTTP gives basic authentication support that is compatible with all browsers and is easy to use. You can use this facility so that you don't have to handle the authentication details yourself.

The main drawback of the basic HTTP authentication is that the password is included, virtually in plain text, in every request. This means that the password can be sniffed unless every page is served using HTTPS. For this reason, you may want to have HTTP access inside of your private network but only allow HTTPS access to the same content when the user is coming from outside of your private network. You can easily do this by configuring your router or firewall to only allow external access to the server over port 443.

Creating the htpasswd File

The first thing you must do is create an htpasswd file. This is similar to the system password file because it contains usernames and encrypted passwords. Your web server most likely comes with the htpasswd program that is used to create and manage this file. You can place the file anywhere on your system, but you should place it outside of any web directories so that it cannot be accessed over HTTP. You may create the file as /etc/htpasswd, for example. You can create the file using the command:

# htpasswd -c /etc/htpasswd username
New password:
Re-type new password:
Adding password for user username

The -c switch tells the program to create a new file. Once the file has been created, you can add additional users by running the same command, but without the -c:

# htpasswd /etc/htpasswd user2
New password:
Re-type new password:
Adding password for user user2

How many accounts you should create depends on your system and how much control you want over system access. If every user will have complete access, you can create just one account with one password and all of the users can share that account. The advantage of this is easier management—that is, you can quickly change the password on that one account whenever you need to. The disadvantage is that you lose accountability, meaning that you don't know what user did what because they are all using the same account.

The other alternative is to create a separate account for each user. This allows your scripts to limit access based on the remote user. It also stores the username in the web server's access logs. The disadvantage is that you have to create a web interface to allow users to change their passwords. If you do not, you will have to manually manage all of the accounts or, more likely, the passwords will never get changed.

In any case, you need to make sure the htpasswd file itself, as well as all directories leading up to it, are readable and executable, respectively, by the user running the web server.

Restricting Access

Assuming you have your router/firewall configured to not allow external hosts to spoof internal IPs (a pretty basic ability, especially if your internal IPs are one of the reserved private networks), you can tell your web server not to require a password when the request is coming from an internal system. This gives access control from external hosts, but it also gives hassle-free access internally. You should, of course, make sure that any internal wireless network does not allow this access control to be circumvented by somebody outside your company with a wireless network card.

If you are using the Apache web server, you can restrict access in the main configuration file (such as /etc/httpd/conf/httpd.conf). Assuming you want this restriction applied to every page served by your web server, you can use these commands:

<Directory />
AuthUserFile /etc/htpasswd
AuthType Basic
AuthName "Administration System Access"
require valid-user
Satisfy any
order deny, allow
allow from 192.168.0.0/255.255.0.0
allow from 127.0.0.1
deny from all
</Directory>

This allows the system itself and all hosts in the 192.168 private network access to the system without authentication. For anybody else, the user must provide a username and password that matches an entry in the /etc/htpasswd file.

Note that this access control applies to the directory / and everything under it. This means it applies to every file and directory on the system when they are accessed through the web server—unless you have other blocks that override the settings for specific subdirectories. This is the safest way to make sure you catch all the files on your system, even if you later add virtual hosts, aliases, and other configuration items.

If you provide each user with a different account and want to log the user- names, you would not want this type of configuration because local users would never be authenticated. In this case, you should just require authentication in all cases:

<Directory />
AuthUserFile /etc/htpasswd
AuthType Basic
AuthName "Administration System Access"
require valid-user
</Directory>

Depending on the size of your company and the people that work there, you may want to use this second access control configuration anyway. There are many companies where it would be a bad idea to allow open access to a system configuration web interface.

Accessing the Username

If you have assigned different accounts to different users, it is nice to be able to retrieve this information from within Mason. It is actually stored in an environment variable, just as with the traditional CGI interface. The environment variable is $REMOTE_USER. You can test this as follows:

<P>
You are logged in as: <% $ENV{'REMOTE_USER'} %>
</P>

Remember that the environment variable will not be defined unless you require authentication for the page in your web server's configuration. There are other interesting environment variables as the following page can show you:

% foreach my $var (keys %ENV) {
<br />Name = <% $var %>, Value = <% $ENV{$var} %>
% }