User Authentication

Overview

Most people create web pages knowing they can be seen by anyone anywhere on the world wide web. This is a good thing. On the other hand, it's not uncommon to want only certain people to see certain pages, depending on their content. There are two ways to do this.

• WebAuth: This allows only Stanford people (all Stanford people, or just particular Stanford people, etc.) to see your web pages. WebAuth is the most often used method for protecting your pages at Stanford.
• User Authentication (this page): Lets you allow only non-Stanford people (or some combination of Stanford and non-Stanford people) to see your pages.

This tutorial supplies basic information you'll need to protect your pages with User Authentication

Controlling access at the file level

You need to protect your pages at the file level first. Web pages are, after all, just files in your AFS home directory. Since AFS is a distributed file system (it's on machines all over campus and the world), it's possible for anyone who knows AFS (at MIT, say, or Carnegie Mellon or Berkeley, etc.) to access the web files in your home directory and open them up to read them. To restrict access to the files in your web directory, just use AFS permissions to keep unwanted people out of that directory. Step by step instructions on how to do this are provided on the Setting Permissions pages. The crude basics:

1. Log into Unix


2. Go to your web directory


3. Issue the following commands

   fs setacl dir system:www-servers read
   fs setacl dir system:anyuser none

   where dir is the name of the web directory you're protecting.

Controlling access at the server level

In order to restrict access from web browsers, you will need to set up as many as three files depending on what type of access control you would like:

.htaccess (required)

This file provides its directory with access control. Any web directory (which must be at or below the WWW directory level) whose access you would like to control must have this file. To protect all your web pages, put a .htaccess in your WWW directory.

Subdirectories of a directory with an .htaccess file will be under its control unless they have their own .htaccess file.

.htpasswd (optional)

This file is necessary if you are using the "Basic" authentication method. Each line of this file pairs a user with an encrypted password.

.htgroup (optional)

This file allows you to assign sets of users to named groups.

Setting up your access control file

Sample .htaccess file

AuthUserFile /afs/ir/users/y/o/yourname/.htpasswd
AuthName ByPassword
AuthType Basic

order deny,allow
deny from all
allow from .stanford.edu
require valid-user

Access to the pages in this access file's directory is limited to users in the given password file (using "Basic" authentication), from machines within the Stanford domain. Note that it is the first three lines that restrict access for people while the last four restrict access for machines/networks. It is not necessary to have both sections in your access file.

Note: Always make sure your .htaccess file has a line return after the last line.

Configuration directives

• AuthTypetype

  For User Authentication, where you're restricting people via the random usernames/passwords you've given to them, replace "type" with the word Basic. (If you were using WebAuth and restricting access by SUNet IDs/passwords, you'd have used the word WebAuth.

• AuthNamename

  The symbolic name of this access file. It shows up when a user is prompted for a password. Specify whatever you think is appropriate. Only applies if you are using the Basic auth method.

• AuthUserFilefile

  (Basic) Specifies the absolute path of the user's password file.

• AuthGroupFilefile

  (Basic) Specifies the absolute path of the user's group access file.

Access directives

The following three access directives are used for domain protection - you'll always have order first, followed by the other two:

• orderorder

  Specify allow,deny for "everyone but those" and deny,allow for "only these". Spaces aren't allowed next to the comma.

• deny fromdomain

  Specify either all, a domain name, or a host name.

• allow fromdomain

  Specify either all, a domain name, or a host name.

Only one directive controls which users are eligible for password verification: require. It takes one of these three forms (which are additive, i.e. a user gets the page if they satisfy any of the require lines:

• require useruser1 user2 ...

  Specify which users (separated by spaces) in the AuthUserFile file are allowed access upon providing a valid password.

• require groupgroup1 group2 ...

  Specify which groups of users in the AuthGroupFile are allowed access upon providing a valid password.

• require valid-user

  Allow all users in the AuthUserFile file access upon providing a valid password. (When used with the AuthType of WebAuth it allows any user who has provided a valid SUNet ID and password to see the file.)

Setting up your password file ("Basic" auth method)

These user names and passwords are not related to SUNet ID usernames and passwords. The passwords that you assign your users (or that they give themselves) should therefore not be SUNet ID passwords.

Run the htpasswd program to create your password file and to add users to it. For example:

htpasswd -c /afs/ir/users/y/o/yourname/.htpasswd user1

The program will then ask for user1's password and add it to the newly created password file. When you want to add another user, leave out the "-c" switch:

htpasswd /afs/ir/users/y/o/yourname/.htpasswd user2

Remember, the server will need read permission on the directory that has your .htpasswd file. You can put it outside your WWW directory to keep it from getting served as a web document, but the server still needs to be able to read it.

Setting up your group file

These groups are not related to AFS or Unix groups. They are just a convenience so that you don't have to provide long lists of users repeatedly.

Each line consists of a group name followed by a list of users. For example:

friends: clewis benr bpowell
co-workers: sisyphus clewis

For more information

See the Security Notes for information about protecting your password and group files.

See the WebAuth page for information protecting pages with SUNet IDs.

See Organizational Path Names for information about paths to your AFS home page.

Apache has detailed information on the directives used to control access.