What is the CalGroups service?
CalGroups is an access management system based on the Grouper application. It allows campus members to create and manage groups that are synchronized among these primary group stores: Grouper, LDAP, AD, and bConnected. CAS and campus applications consume group information from these sources for authorization purposes. In effect, the group you create is the same group, everywhere.
CalGroups Data Flow
What is a CalGroup?
A CalGroup is a collection of CalNet identities. All CalGroups are stored in Grouper and propagated in real time to the rest of the primary group stores: LDAP, AD and bConnected. Campus applications can consume CalGroup membership information from any one of these group stores.
CalGroups are also referenced by CAS for access management purposes. Campus applications can configure authorization rules in CAS that limit access to the members specified CalGroups.
What is CalGroups for?
Access Control
CalGroups are used for making access control decisions: membership in a group determines access to a service. You can set up CalGroups to map to your application’s roles and allow only members of these groups to access your application via CAS. This has the added benefit of providing automated de-provisioning via links to official groups (see below on how this works).
Communication Lists
CalGroups may also be used for communication lists. An application’s role groups can be available in bConnected as Google Groups that can receive email. Please note that while CalGroups may be configurable for some functions of mailing lists, it does not replicate the full features of a mailing list application.
What are the types of CalGroups?
|
Type |
Description |
Group Creation and Membership Updates |
Example |
|
Ad hoc |
A group where the membership is manually maintained |
Grouper |
People in a project team |
|
Automated |
A group that is created programmatically from a source application |
From the source application |
bCourses class list |
|
Official |
An automated group derived from official systems of record (UC Path, SIS, ADVCON) |
From attribute changes in the official systems of record |
All employees from UC Path |
|
A group that is the product of two or more groups |
Any update to one of the member groups changes the membership of the composite group. |
An intersection of people in an ad hoc BFS access group and the All Employees official group |
How is the CalGroups Service organized?
Grouper is organized in a hierarchy. At the top level, the following four folders represent the main divisions of the group space.
|
Folder |
Description |
Group Type |
|
App |
Groups that are programmatically derived from source applications |
Automated |
|
Official |
Groups that are programmatically derived from official systems of record (UC Path, SIS) |
Official |
|
Org |
Groups that are managed and consumed by departments. A department will be given their own subfolder in which to manage their own groups |
Ad hoc, Automated or Composite |
|
Community |
Groups created by the individual user |
Ad hoc or Composite |
How do I set up automated deprovisioning in CalGroups?
The power of the CalGroup’s infrastructure as an access control mechanism is the ability to combine ad hoc groups for rapid on-boarding with official groups for fail safe de-provisioning. To set up automated de-provisioning, see: How to Make an Access Group.
What is the best practice for defining access groups?
To take advantage of CalGroup’s automated de-provisioning feature, all access control groups should be defined as access groups. At a minimum, all access controls should be based on a composite group at the intersection of an ad hoc group and the All Employees or All Students groups, depending on the application’s target population.
How do you update a CalGroup?
In order for the CalGroups service to be an effective access control mechanism, all CalGroups must have current, accurate membership reflected in the Grouper central group repository.
Automated and official groups are updated in their respective source applications and propagated to Grouper via APIs.
Ad hoc group updates are made in Grouper via the Grouper UI.
Use Cases
Use Case 1: A composite group is created and mapped to a role within the Peoplesoft apps like HR, SIS and BFS for access control. The group is built at the intersection of an ad hoc group and the appropriate departmental group. People are given access to the role functionality by a manual process of adding them to the ad hoc group. People have their access revoked when they are either removed from the ad hoc group manually, or their affiliation changes in the identity registry and they are automatically removed from the departmental group.
Use Case 2: Membership in a similar composite group is used to determine access to a CAS protected web page.
Use Case 3: A composite group is used to manage access to a bDrive.