IRT supports Stanford University Web Authentication (WebAuth), which provides a way of restricting access web pages to users in the Stanford community, by requiring SUNet IDs. Web materials can be restricted to all Stanford users, or to specific users (named by SUNet ID). You can request installation of WebAuth via the Web Help form, or install WebAuth yourself.
Installing WebAuth
Access to files is controlled at the directory level. This means that all the files in a given directory will be restricted. It's a good idea to provide an unsecured "landing page" where users are instructed on who is permitted, and how to request access.
To protect a given directory with WebAuth, you will need to include a file in that directory named ".htaccess". The .htaccess file tells the Web server how to authenticate users. You must use Dreamweaver to place the file. If you are a Contribute user, contact Web Help.
- Within your local site files as defined in Dreamweaver, create a new file within the directory to be protected and name or re-name the file ".htaccess"
- Replace all the text in the file code with the appropriate directives, depending on who you wish to allow (see links below to jump to a specific approach).
- Upload the file to your site, and test the protection through your Web browser.
Restricting access to any valid SUNet ID
The content of the file should be the following text only. Be sure to have a blank line after last line of text.
AuthType WebAuth
require valid-user
Restricting Access to Specific SUNet IDs
You can limit access to a single SUNet ID or list of multiple IDs, typically as listed in Stanford.Who. All of the SUNet IDs must be on one line (no paragraphs or carriage returns; word-wrap in the Dreamweaver code window is OK). Be sure to have a blank line after last line of text.
AuthType WebAuth
require user bjones jsmith lmccoy
Restricting Access to a Workgroup
Using the previous method can be tedious when users come and go. It's more convenient to manage lists of users' SUNet IDs using workgroups. Once a workgroup is established, owners of the workgroup manage membership using the Workgroup Manager site (SUNet ID required...there is also an unsecured page explaining workgroups).
Personal vs. Organizational
Anyone with a SUNet ID can create a new workgroup under their personal prefix. These take the form "~yoursunetid:groupname" Important: Personal prefix workgroups are deleted when the user leaves Stanford.
To create workgroups with an organizational prefix that will outlive the members' and admins' SUNet IDs, you must first request a new "stem" from ITSS through the HelpSU form. You can also request that your first group be set up under that stem. These take the form "organization:groupname"
It can take several days to get your organizational prefix workgroup set up. It's perfectly fine to start out using a workgroup you set up under your personal prefix, and then switch to the organizational one when it's ready.
Here's the .htaccess document syntax for personal prefix workgroups. Be sure to have a blank line after last line of text.
AuthType WebAuth
require privgroup ~yoursunetid:groupname
Here's the .htaccess document syntax for organizational prefixes. Be sure to have a blank line after last line of text.
AuthType WebAuth
require privgroup organization:groupname
Restricting Access to a System-maintained Privgroup
Access can also be restricted to broad classes of users, such as faculty, students, staff or combinations of these classes. See System-maintained groups on the ITSS site for a detailed list of these groups and who is and isn't included in them. IRT has not found this capability especially useful, as "faculty" means all Stanford faculty, "staff" means all Stanford staff, etc., which is usually overly broad.
Here's the .htaccess document syntax to allow any Stanford faculty.
AuthType WebAuth
require privgroup stanford:faculty
Using WebAuth Protected Pages
To protect the full transaction between the user's browser and the server, one should always use "https://" rather than "http://" to access a WebAuth-protected page or directory, and an absolute URL using the long med.stanford.edu domain name. So, even if you're protecting a directory in a site with the custom domain URL "yoursite.stanford.edu" you must still link to the protected files using a full https URL, i.e.
"https://med.stanford.edu/yoursite/protected/securepage.html"
When a user clicks on a link to a WebAuth-protected page they are redirected to a central Stanford WebAuth login page; upon authenticating, the user is directed back to the original page requested. Users who are not "valid-user"s or specifically listed after "require user" will not be allowed to view the page or directory.
Secure and Unsecured
Another common source of problems occurs when the user encounters both secure and unsecured pages within the same browser window, sometimes because of frames, more often because of problems with page coding.
More information about WebAuth is available from ITSS.
You might also be interested in how to restrict pages with basic authentication (i.e. an arbitrary, non-SUNet ID, username and password) or by machine IP address, which can also be combined with WebAuth.