Weblogin and Access Control

The recommended method to add access control to your pages is to use Weblogin for authentication (to verify a user is indeed who he or she claims to be) and various Apache commands for the authorization (to verify the authenticated user is allowed access to the information.)

The www.washington.edu servers allow you to limit access based on users UNIX groups, UW affiliations, or groups in the UW Groups Service. These can also be mixed and matched.

These commands should go into a .htaccess file in the directory you wish to protect. It will also protect all subdirectories.

Allowing Users

To enable only users "john" and "jane" you could use:

AuthType UWNetID PubcookieAppID "MyApplication" require user john jane

The value for PubcookieAppID should be unique to your application.

The .htaccess file should only exist in the topmost directory you wish to protect. For example, if you have all your images in a subdirectory named "graphics/", that directory should not have its own .htaccess file.

Allowing Unix Groups

The www.washington.edu cluster allows the use of the UNIX groups defined for Red, Bank, and Shiva. To allow access for only users in the UNIX group named "private", but to also allow the user "jack":

AuthType UWNetID
PubcookieAppID "MyApplication"
require ugroup private

Allowing Affiliations and UW Groups

If you wish to limit access based on affiliation (such as staff or faculty), you could use:

AuthType UWNetID
PubcookieAppID "MyApplication"
require type staff faculty

You can also limit to UW groups. For example, to only allow in UW Technology users:

AuthType UWNetID
PubcookieAppID "MyApplication"
require group u_cac_all

Warning: Only very few UW groups are predefined, but you can view what groups have been created and create your own using the web browser interface to the UW Groups Service.

Mixing Permissions

You can also mix require commands. To allow in all students, the unix group "private", and users "john" and "jane", you would use:

AuthType UWNetID
PubcookieAppID "MyApplication"
require type student or ugroup private or user john jane

These commands can be split into multiple lines:

AuthType UWNetID
PubcookieAppID "MyApplication"
require type student
require ugroup private
require user john
require user jane

Use the not keyword to reduce the number of people who can access. To allow all students except "john" and "jane":

AuthType UWNetID
PubcookieAppID "MyApplication"
require type student and (not user john jane)

Note that you cannot use the deny command, since the UWNetID authorization module does not support that command.

Allowing All Authenticated Users

If you wish to allow access to all users who successfully authenticate to Weblogin, you would use:

AuthType UWNetID
PubcookieAppID "MyApplication"
require valid-user

Allowing Locally-Defined Groups

If you wish to define your own local groups, you can use Apache's Groupfile Authorization Module. It is important to point out that this file must be referenced by a full path on the web server (which must work for both development and production servers), and you cannot mix locally-defined groups with Unix groups (require ugroup above), UW groups (such as require group u_cac_all), or affiliations (require type above).

The steps involved in creating a locally-managed group are:

Create the file in wwwudev (such as /usr/local/wwwudev/world/mydirectory/.htgroup) which contains your group definitions.
Install this into production:
% wwwuinst -push world/mydirectory/.htgroup
Reference the group file in your .htaccess file:

AuthGroupFile /www/world/mydirectory/.htgroup

After you have completed these steps, you can use those groups, or even combine multiple groups and users. When you have AuthGroupFile in your .htaccess file, each user or group must be on an individual line, such as:

AuthType UWNetID PubcookieAppID "MyApplication" AuthGroupFile /www/world/mydirectory/.htgroup require group group1 require group group2 require user user1