Grouper: Automated Provisioning and Deprovisioning

Grouper has capabilities for automated provisioning and deprovisioning.

In this article:

• Data Synchronization and Automation
• Loaders (the pipeline)
• Basis Groups (the source of truth)
• Reference Groups (refined users lists)
• Policies (authorizing access to resources)
• Provisioning - The Basics
• Deprovisioning - The Basics

Data Synchronization and Automation

Grouper has automated provisioning and deprovisioning capabilities that ensure that when someone joins or leaves a team, their access rights to apps, folders, or systems are automatically added or removed. The automated process starts with loaders pulling data from the source system into Grouper. 

Loaders (the pipeline)

Loaders are automated background tasks that pull data from the University's source systems (such as HR) into Grouper. 

• Loaders are scheduled to run throughout the day, providing near real-time information. 
• Loaders identify individuals who meet certain criteria—such as being a student, staff, or faculty member—and automatically updates their membership in the corresponding Basis Groups. As people join or leave the University, the loaders ensure they are added to or removed from these groups automatically.

Basis Groups (the source of truth)

Created by Grouper administrators, basis groups represent raw data pulled from systems of record (e.g., HR, student information systems). They are typically simple, granular subsets, such as "all active employees" or "engineering students".

As people are added or dropped from the source systems, they appear or are removed from the results of the loader's query, which then updates the Basis Group. 

Basis Groups can be configured to cover any university record, with hundreds currently based on specific attributes. Examples of Basis Groups

Reference Groups (refined users lists)

While Basis Groups provide raw data from across the University, Reference Groups are created by combining basis groups to form more meaningful, reusable cohorts, and are made available for wider consumption by teams or departments. An example would be, "All students and faculty in the Math department."

A Reference Group can be built from two main sources:

• Automated Reference Groups: Existing Basis Groups (e.g., only those in a specific department, campus, degree, year, etc.)
• Ad-Hoc Reference Groups: Grouper admins will set up ad hoc groups for you to manually add or remove specific individuals who may not be captured by the automated data. Ad hoc groups are needed in situations where: 
  • The population is "human-defined": No database attribute can identify who belongs. Examples include a standing committee, a research team, or a specific project group, or a temporarily assigned resource.
  • You need "exception" handling: You have an automated group (e.g., "All Faculty") but need to manually add a guest researcher or manually exclude someone for a specific security reason.
  • Delegated management is preferred: You want to empower your group's updater or owner to manage their own members via the Grouper UI without involving IT or updating a database.

Policies (authorizing access to resources)

"The Policy Group is the final output of the Grouper logic. Policies define who gets access to your system and what they can do once they log in.

Policies are provisioned to a directory endpoint (such as LDAP, AD, or Entra ID), which then connects to your downstream systems. 

Because you understand your local business needs best, you define the 'rules of the game' for your applications' Grouper policies. You tell us the 'logic' of who should have access, and we build that custom 'Stem' (folder) for you. Once the structure is built, we hand over the keys, allowing your team to manage those local policy decisions and ad-hoc memberships independently.

• COE Grouper admins:
  • We ensure the data from HR and Student systems is clean, reliable, and always up-to-date in the Basis and reference Groups.
  • We build the "Stems" (the containers or folders) for your groups
  • We configure the logic for your policies

• You, the stakeholders:
  • You define the policy requirements
  • You manage the manual/ad hoc group memberships
  • You conduct attestations (usually twice yearly)

See Typical Policy Configuration for an example of how policies in an average app stem might be configured. 

Provisioning - The Basics

• The Provisioning (The Delivery): Grouper automatically pushes the final (composite) Policy Group out to the University's central directories (like Active Directory, LDAP, or Entra ID), where it appears as a standard security group (AD) or part of a members list (LDAP)
• The Integration (The Connection): Your specific application is configured to "point" to this group in the directory, treating it as a simple "Yes/No" gate for granting access. Your application or resource simply looks at that list to see who is allowed in.
• The Enforcement (The "Lock"): Once a user is removed from this directory group—whether by an automated loader or a manual change—the "signal" to your application is cut off. Because your system or resource authorizes directly through that directory, the unauthorized user is immediately blocked from entry.
• The Result (The Access): Your application always reflects an accurate, authorized list of users, ensuring that your local resources are protected from unauthorized access at all times.

Deprovisioning - The Basics

Grouper architecture is designed to handle Institutional Offboarding with zero-touch automation. When an individual's relationship with the University officially ends—through graduation, retirement, or termination—Grouper immediately identifies the change in the source system and revokes all associated access across target directories.:

• The Loader removes them from the Basis Group.
• The Reference Group and Policy update instantly.
• The Provisioner immediately tells LDAP/AD/Entra ID to remove them from the specified policy. Once a user is removed from this directory group—whether by an automated loader or a manual change—the "signal" to your application is cut off. Because your system or resource authorizes directly through that directory, the unauthorized user is immediately blocked from entry. 
• The user's access is cut off campus-wide in seconds.

For Internal Transfers, the system applies a risk-based approach. While a staff member moving between departments will generally retain their broad access to prevent workflow disruptions, any membership in a group designated as 'High-Security' at the application stem level will trigger an automatic deprovisioning. This ensures that access to the University's most sensitive systems is instantly retired upon a change in departmental affiliation, while leaving the management of standard access to the discretion of the local stakeholders during the transition.