Workgroups
Overview
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:
- My family: Dad, Mom, Janey, Aunt Meg ...
- Lunchtime volleyball team: Craig, Tom, Karen, Brian, Nan ...
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 its:directors |
|
2. workgroups owned by individuals ~jdoe:book_exchange |
|
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:
- email distributions lists
Email lists are a collection of addresses created specifically to route email to. - access control lists (ACLs)
...but they can be used by an application in place of local access lists.
The advantage of workgroups is that they are defined independently of any specific application and can therefore be used by multiple applications. Some examples:
- The Graduate School of Business uses workgroups to identify affiliates and other special individuals who are not in GSB but who need to have privileges in their systems.
- The MaIS Registries team uses workgroups to manage administration privileges across its applications.
- Oracle Financials uses workgroups to record who has completed specific authority prerequisites, such as Cost Policy Training.
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:
- 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
- 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 facultystanford: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 staffstanford: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 studentsstanford: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:
- log into Workgroup Manager
- click Create a new group
- 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.
Workgroups and guest accounts
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 jdoe@yahoo.com. 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.
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:
- No filter. Members will remain active in your workgroup until you remove them.
- Stanford academic & administrative. Members of your workgroup must also be in the stanford:academic or stanford:administrative system-maintained groups.
- Specific affiliation: faculty, staff, student. You can select one or more of these groups. Selecting all three groups is equivalent to the stanford:stanford system-maintained group.
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:
|
||
Filtered out:
|
||
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
- Using a text editor, create a plain text file named .htaccess.
- 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
- Transfer the file to the directory you want protected (using Dreamweaver or any other file-transfer method).


