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
2. workgroups owned by individuals
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.
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:
| 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.
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)
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:
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.
Stanford now supports the creation of guest accounts to provide access to certain University services that use Shibboleth to control access. A website or service may be configured to use Shibboleth access control based on membership in a specified workgroup. A Stanford community member sends a non-Stanford colleague an invitation to a Stanford guest account, then adds that guest account to the appropriate workgroup. When the individual accepts the invitation, s/he can use the guest ID to login to the "shibbolized" website.
A guest ID may be any fully-expressed non-Stanford email account, such as firstname.lastname@example.org. These IDs can be added to workgroups just like SUNet IDs - a workgroup may include any combination of SUNet IDs and guest IDs. However, a guest account cannot be made a workgroup administrator (and guest accounts cannot login to Workgroup Manager).
For more information about guest accounts and how to create them, see the Guest Accounts service page.
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:
Note: These filters apply to Stanford community members only. Guest Account members are not affected by any workgroup membership filters.
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"
Effective membership in the workgroup:
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:
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:
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:
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:
require privgroup ~jclerc:colleagues french_dept:faculty
require user tdoe nguyen
| AuthType WebAuth
require privgroup helpdesk:consultants helpdesk:managers