Workgroup Manager is a web application that gives Stanford community members a place to define groups of community members for use in various online applications, including web authentication. Though the name "workgroup" may imply usefulness only to faculty or staff, workgroups can be helpful to, and maintained by, anyone with a current SUNet ID.

A group is one or more people with something in common that can be identified by a common trait. For example:

A workgroup is a list of members in a group, identified by their SUNet IDs, and given a name that uniquely identifies it. A workgroup may also contain subgroups - other workgroups identified by their name.

Workgroups come in two flavors:

1. workgroups owned by departments, divisions and projects


  • identified by the department's assigned stem

2. workgroups owned by individuals


  • identified by the owner's SUNet ID preceded by a tilde

The first part (stem) of a workgroup's name, before the colon, is the workgroup's owner; the second part (id) is the specific name of the group. The combination of the two parts (stem:id) creates a unique name that can be used to refer to the workgroup.

How are workgroups used?

A workgroup by itself doesn't do anything. It just exists as a way to identify a group of people by a single name. Workgroups are a tool to be used by other applications and services.

Workgroups are not:

The advantage of workgroups is that they are defined independently of any specific application and can therefore be used by multiple applications. Some examples:

Individuals can use workgroups to restrict access to web pages, by naming the workgroup in a .htaccess file. For example, if student Jane Doe wants to make some pages available only to members of her study group, she could do the following:

  1. create a workgroup named "study_group" with her stem (~jdoe), and include as members the specific classmates she wants to be able to access the pages, then
  2. create a .htaccess file in the directory where the pages are located, containing these 2 lines:

    AuthType WebAuth
    require privgroup ~jdoe:study_group

When anyone attempts to access the directory containing this .htaccess file, they'll be asked to login via WebAuth. Only members of the workgroup ~jdoe:study_group will be given access to the directory.

For more details about using workgroups to control web site access see Workgroups and WebAuth, below.

System-maintained groups

There is a set of system-maintained privgroups and workgroups.

These privgroups can be used in a .htaccess file:

stanford:faculty includes regular faculty, emeritus faculty, faculty on leave, incoming faculty, faculty affiliates, and other teaching faculty;
does not include
nonactive faculty
stanford:staff includes regular staff, academic staff, staff on leave, emeritus staff, and other teaching staff;
does not include
casual staff (less than 50% time), temporary staff (less than a 6-month appointment), affiliate staff, Medical Center staff (sumc), retired staff, student staff or nonactive staff
stanford:student includes regular students, students on leave, and MLA students;
does not include NDO (non-degree option) students, incoming students, contingent students, students not registered, recent students, or nonactive students
stanford:stanford union of faculty, staff, and student groups above
stanford:academic faculty and student groups above, plus NDO (non-degree option) students, retired faculty, and academic staff
stanford:administrative faculty and staff groups above, plus retired faculty, casual staff (less than 50% time), temporary staff (less than a 6-month appointment), and sponsored affiliates (anyone sponsored for a full or base SUNet ID)

Creating personal, department, project, application, etc. workgroups

All SUNet ID owners are able to create personal groups with their ~sunetid stem. Just log into Workgroup Manager, and this feature will be available to you.

To create a group with an organizational stem, you must be a designated maintainer for that stem. To find out the stems for which you are a maintainer:

  1. log into Workgroup Manager
  2. click Create a new group
  3. click the Group ID drop-down
    All the stems for which you are a maintainer (including your ~sunetid stem) will be listed.

If you know a stem exists, and you need to be able to create and maintain groups with that stem, send a request to HelpSU.

If you need a new stem created for a group or project, send a request to HelpSU. We also recommend that the stem be more than 8 characters. It should also be limited to alpha and numeric characters, underscores or dashes.

Workgroup membership filters

You can restrict membership in your workgroup to only active members of the Stanford community, or to active students, faculty, and/or staff—automatically excluding or including members whose status changes—without you having to manually update your workgroup. Membership filters are based on the system-maintained groups described above. When you apply a membership filter to your workgroup, any members of your group who are not also members of the selected system-maintained group will be filtered out of your group's effective membership. These members are not deleted from the group—they can become active again if their status changes (or if you change the filter).

The available membership filters are:

You can view and change the filters for your workgroup on the group's Properties tab.

Example: A workgroup owner wants to limit membership in a specific workgroup to only active students and selects a membership filter of Specific affiliation: student. The filter will affect the workgroup's membership something like this:

Membership filter = "Specific affiliation: student"

  • includes regular, on-leave, & MLA students
  • excludes NDO, incoming, contingent, not-registered,
    recent, or nonactive students

Effective membership in the workgroup:

  • Ann Doe (student)
  • John Doe (student)
  • Quinn Doe (MLA student)
  • Wen Doe (student on leave)

Filtered out:

  • Jane Doe (recent student)
  • Orville Doe (incoming student)
  • Sophie Doe (NDO student)

Workgroups and WebAuth

A principal benefit of workgroups is that they can be used with WebAuth to control access to Web pages. WebAuth looks for instructions in a file named .htaccess, in the same directory as pages you wish to protect. The instructions can refer to individuals (by their SUNet IDs) or to workgroups (by their name).

Limiting access to specific individuals looks like this in a .htaccess file:

AuthType WebAuth
require user tdoe nguyen jclerc

The AuthType WebAuth statement indicates you are restricting your pages to people who can authenticate (login) by their SUNet ID and password (an older version of the WebAuth software used Authtype StanfordAuth, and .htaccess files using that form still work with WebAuth, though with some slight differences from what's described here). The require user statement lists people who can access the pages in this directory.

You may already be familiar with how to limit access to system-wide, or "stanford:" privgroups:

AuthType WebAuth
require privgroup stanford:faculty stanford:student

Using workgroups is just like that, except you specify the name of a workgroup in place of a Stanford privgroup:

AuthType WebAuth
require privgroup helpdesk:consultants

You can specify multiple groups, and types of groups, at once; and you can name groups and individuals in the same .htaccess file. This example includes a personal workgroup and a departmental workgroup, plus two individual users:

AuthType WebAuth
require privgroup ~jclerc:colleagues french_dept:faculty
require user tdoe nguyen

Setting up a .htaccess file to use workgroups

  1. Using a text editor, create a plain text file named .htaccess.
  2. Enter the following lines in the file:
    AuthType WebAuth
    require privgroup helpdesk:consultants helpdesk:managers
    • list all the workgroup names you want to include on the same line, each separated by a space
    • enter the complete workgroup name (stem:id), including the tilde (~) for personal workgroups
    • end with a blank line
  3. Transfer the file to the directory you want protected (using Dreamweaver or any other file-transfer method).