Computer Laboratory

Access control and passwords on web servers

This page explains how you can restrict access for some of your web pages to certain domains, users, or groups of users. You can do this by creating a .htaccess file in the relevant subdirectory, which allows you to control access to all files in this directory and all its subdirectories.

On 2016-10-04 we shall be upgrading the main Lab web server from Apache 2.2 to Apache 2.4. Unfortunately the mechanism to restrict access changed between Apache 2.2 and 2.4 meaning that .htaccess files need to be reviewed. Including the Apache Module mod_access_compat eases the transition, but does NOT cope with mixed use of machine and user authorisation. More information on the migration and some tools are available at /anfs/www/tools/share/migration/README.txt and on the Lab WiKi.

Apache access control

Our Apache web servers have three ways to identify (“authenticate”) users who request files:

  1. by the domain name or IP address of the client machine
  2. using the University’s Raven web authentication system (Ucam-WebAuth protocol)
  3. via a HTTP password

Method (1) is useful for permitting password-free access for every user connected to a departmental or the University network. You normally want to combine it with one of methods (2) or (3) for the benefit of users who access from outside the University network, e.g. from their home PC.

Methods (2) and (3) are mutually exclusive, so you have to decide first whether you want to rely on the Raven password that users have already received from the Computing Service, or whether you want to maintain your own password file. Raven authentication is much less effort for you to set up, and is more secure, but it can currently only authenticate members of the University who have been assigned a Computing Service identifier (CRSID). All the examples below use method (2).

Method (3) involves editing a password file using the Apache htpasswd command-line tool.

For details on all three options, read the Apache documentation section on Authentication, Authorization and Access Control for 2.2 or Authentication and Authorization for 2.4. (Unfortunately, the mechanisms are very flexible and this part of the Apache manual is not written in the clearest possible style, both of which together can be rather confusing.) The next section covers the simplest cases.

Common configuration examples

The following examples show some of the most commonly used .htaccess configurations, which define which users are permitted (“authorized”) to access the directory for Apache 2.2 and Apache 2.4:

Apache 2.2

  • Cambridge-wide access – allow access to anyone who is connecting from within the University of Cambridge or who is able to login to Raven:
    Order Allow,Deny
    Satisfy Any
    Allow from
    Require valid-user
  • Lab-wide access – allow access to anyone who is either using the Computer Laboratory LAN (excluding the PWF student PCs) or who is a member of the Computer Laboratory:
    Order Allow,Deny
    Satisfy Any
    Allow from
    Deny from
    Require group all-cl-users

Apache 2.4

  • Cambridge-wide access – allow access to anyone who is connecting from within the University of Cambridge or who is able to login to Raven:
     Require host
     Require valid-user
  • Lab-wide access – allow access to anyone who is either using the Computer Laboratory LAN (excluding the PWF student PCs) or who is a member of the Computer Laboratory:
     Require host
     Require not host
    Require group all-cl-users

Apache 2.2 or 2.4

Access controls which implement only a logical OR of one or more Require directives are compatible between the two. Where there are no Allow or Deny directives being used, any Order or Satisfy directives are redundant and should be removed, because Apache 2.4 no longer understands them.

Apache 2.2 has an implicit default of

Order Allow,Deny
Satisfy Any

Apache 2.4 around the outermost level of any Require directives an implicit segment

  • Course-specific access – allow access to anyone who is a member of the group students-part1b, all-cl-users, or cl-supervisors:
    Require group students-part1b all-cl-users cl-supervisors
  • Password access (non-Raven) – deactivate Raven and allow basic password-controlled access to user “supervisor” (the hash value of the password of each user is listed in file /homes/mgk25/.htpasswd):
    AuthType Basic
    AuthName "supervisor login available from Markus Kuhn"
    AuthUserFile /homes/mgk25/.htpasswd
    Require user supervisor
    (The “htpasswd” tool for changing your .htpasswd file is in the Ubuntu Linux package “apache2-utils”.)

Predefined user groups

By default, our main web server defines the following groups of users (AuthGroupFile /auto/anfs/www/auth/group-raven):

students-part1a-cst CST Part IA students
students-part1a-otherNST Part IA, PPS Part I students
students-part1a both of the above
students-part1b CST Part IB students
students-part2 CST Part II students
students-part3 CST Part III students
students-acs MPhil ACS students
students-all all of the above
wednesday departmental teaching officers, senior staff, SRAs
all-cl-users all resident members of the department (including research students, visitors, interns, but excluding students on bachelor/masters courses)
undergrad-directors-of-studiesmembers of the Computer Science DoS mailing list of the same name
cl-supervisorsmembers of the Lookup group of the same name

Each of the students-* groups has a year-specific alias, with (mostly) immutable membership. For example, between early October 2008 and early September 2009, the group students-part1b can also be refered to as students-part1b-0809. Sometimes in September 2009, this group disappears and the new alias students-part1b-0910 becomes available for the next lot. This facility is useful for giving students of a particular year access to solution notes after the end of supervisions, without risking that this access will be transfered accidentally next September too early to the next lot.

Denying access to groups “all-cl-users”, “students-part3”, or “students-acs” may be ineffective. In most cases, our main web server serves files by accessing them from the filer “elmer” via NFS, according to the “other” access-control bits set for the file and its parent directories. Anyone with access to the filer (roughly all-cl-users and masters students) can also see the same files that the web server serves via NFS or CIFS, and can bypass .htaccess restrictions this way. Routinely allowing access to members of “all-cl-users” ensures that the access control settings reflect what can realistically be enforced at present. (Future plan: run the web server under a proper LDAP-known user and group id “www-cl”, such that we can grant to it access via the “user” or “group” permission bits. – RT #74735)

It is also possible to test membership of Lookup groups via LDAP (although this is still a somewhat experimental facility).

Oder and Satisfy directives in Apache 2.2

The first two lines in some Apache 2.2 examples select the semantics of how the following access control list will be interpreted. Apache 2.2 actually supports four different semantics, but all examples here use the same one only. We previosly suggested that you do the same and start all your access control lists with these same two lines in the interest of simplicity:

  • The Order Allow,Deny directive chooses that any Deny directive that matches will override any Allow directive that might also match. This directive also causes access to be denied by default.
  • The Satisfy Any directive chooses that a user will be granted access either based on the host address from which the request came (Allow or Deny directive), or based on the user id or group membership (Require directive). Fulfilling only one (“any”) of those two conditions will suffice to get access.

For the exact syntax of the relevant directives, please follow the above links to the relevant reference pages in the Apache manual.

To prepare for the switch to Apache 2.4, we suggest that you remove any Oder or Satisfy directives from any .htaccess files that do not also contain Allow or Deny directives, because in that case they were redundant anyway.

General policy

As a general rule, the Computer Laboratory aims to make all its information as freely available as possible. Access on its web site should only be restricted where there is a specific reason to do so.

Typical examples for material where access control may be necessary:

  • Personal data
  • Material for which the copyright holder has not given permission for web release
  • Model answers to exercises and past exam questions
  • Draft publications that are not yet ready for release