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     gsb:affiliates     helpdesk:consultants	identified by the department's assigned stem
2. workgroups owned by individuals    ~jdoe:book_exchange    ~santa:naughty_children	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:

• 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:

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:

• 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.

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).