How to set fine-grained access controls in conjunction with WebAuth using the Stanford Web Application Toolkit

From Web Services Wiki

(Difference between revisions)
Jump to: navigation, search
(New page: == Problem == You want to protect a script using WebAuth but with more fine-grained controls (e.g. allowing only certain users to access parts of a script, rather than disabling access to...)

Revision as of 12:41, 11 March 2009



You want to protect a script using WebAuth but with more fine-grained controls (e.g. allowing only certain users to access parts of a script, rather than disabling access to the entire script). For example, you may wish to give certain users access to the administration section of your application, but only grant delete privileges to some of them.


First enable WebAuth and then use the StanfordAuthorization class to create a basic access control list and check if the currently logged in user should be granted access to the resource.

Set up WebAuth-based authentication

Setting up WebAuth is as simple as placing a .htaccess file containing the following two lines in the highest level directory to be protected. All files stored in and under the directory containing this configuration file will require users to log in with their SUNetID and password.

AuthType WebAuth
Require valid-user

Please note that in the example above, valid-user may be too broad for your application's needs, as it includes all Stanford affiliates, both active and non-active. Using WebAuth, you may limit an application to only students, faculty, a custom group, or any combination of the available settings. Go to Middleware and Integration Services to learn more about workgroups. Visit IT Services for additional information on WebAuth user authentication.

Basic usage

Include and initialize the StanfordAuthorization class. Create a list of SUNetIDs that should be allowed access, then add them to the access control list (ACL) using require_users. Check if the currently logged-in WebAuth user should be given access to the script using the method permit_current_user.

// Include StanfordAuthorization
// Create a new StanfordAuthorization object
$auth = new StanfordAuthorization();
// Create list of SUNetIDs to permit
$admins = array("my_sunetid", "other_sunetid", "another_sunetid");
// Add to ACL
// Check if the currently logged-in user is in the list
if($auth->permit_current_user() == true) {
  // Authorized
  echo "<h2>Welcome!</h2>";
else {
  // Not authorized
  echo "<h2>Forbidden</h2>";

Creating ACLs

There are two basic functions for editing an ACL: require_users and deny_users.

Note: You may also use the singular form of these functions: require_user and deny_user. These functions accept a string representing one SUNetID as an argument.

Allowing some users and denying all others

When your ACL contains one or more permit entries, which are created using require_users, all other users are implicitly denied.

// Create a list of authorized users
$admins = array("my_sunetid", "other_sunetid", "another_sunetid");
// Add to ACL

Denying some users and allowing all others

When your ACL contains only deny entries, which are added to the list using deny_users, all other users are implicitly permitted.

// Create a list of evil people
$bad_people = array("spy_sunetid", "hacker_sunetid", "competitor_sunetid");
// Add to ACL

Mixed ACL

If you first allow a user and later deny them within the same ACL, the latter (deny) takes effect. The ACL is read from the top down and a decision is made using the last matching entry.

Note: You may call both require_users and deny_users any number of times without overwriting the effects of the previous function calls. Each time these methods are called, new entries are added to the ACL. There is no way to remove items from an ACL.

// Create a list of active members
$current_members = array("member1", "member2", "member3", "member4", "member5");
// Add to ACL
// Create a list of members whose access is temporarily disabled
$away_members = array("member2", "member5");
// Add to ACL
// member1, member3, and member4 are permitted; all other users are denied


Personal tools