Page tree
Skip to end of metadata
Go to start of metadata

COmanage Groups (CO Groups) are defined at the CO level, and CO Group Memberships attach to the CO Person. CO Groups are fairly basic, for more sophisticated needs COmanage can be connected to Grouper using the Grouper Provisioning Plugin. By default, any CO Person can create a new CO Group.

CO Group Attributes

Open vs Closed

An open group is one that allows anyone to join. Participants can self-join, no administrator action is required. Memberships in a closed group can only be set by the group owner.

In addition, CO Administrators can manage any CO Group within their CO.

Automatic Groups

Automatic Groups are those which Registry automatically manages the memberships of.

Identifiers cannot be assigned to Automatic CO Groups. (CO-1829)

CO Group Membership Attributes

Member vs Owner

A group member is simply a participant in the group. A group owner has permission to add and remove members to and from the group, including closed groups. A CO Person can be a member, and owner, both, or neither.

The CO Person who creates a CO Group is automatically set as both a member and owner of the new group.


As of Registry v3.2.0, CO Group Memberships can have Valid From and Valid Through dates attached. See Registry Validity Dates for more information.

Special CO Groups

Admin Groups

Admin Groups are used to determine Registry Administrators. Admin Groups are automatically created when a CO or COU is created. The Platform Administrator typically sets the initial CO Administrator, and then the CO Administrators.

Since v2.0.0:

  • The admin group is indicated by the group type GroupEnum::Admins and a null cou_id. The default name for the group is CO:admins.
  • The admin groups for COUs are indicated by the group type GroupEnum::Admins and a non-null cou_id. The default name for COU admin groups is CO:COU:COU_Name:admins.

Prior to v2.0.0:

  • The admin group determines CO Administrators.
  • Groups of the form admin:couname determine COU Administrators.

Members Groups

Members Groups are automatic groups that are updated with all members of the CO or COU. Members Groups are automatically created and updated.

Since v2.0.0:

  • Members of the CO in Active or Grace Period status are available in the group identified by the group type GroupEnum::ActiveMembers and a null cou_id. The default name for the group is CO:members:active.
  • All members of the CO (except those in Deleted status) are available in the group identified by the group type GroupEnum::AllMembers and a null cou_id. The default name for the group is CO:members:all.
  • Members of a given COU with an Active or Grace Period status role are available in the group identified by the group type GroupEnum::ActiveMembers and a non-null cou_id. The default name for the group is CO:COU:COU_Name:members:active.
  • All members of a given COU (except those with only roles in Deleted status) are available in the group identified by the group type GroupEnum::AllMembers and a non-null cou_id. The default name for the group is CO:COU:COU_Name:members:all.

Prior to v2.0.0:

  • The members group holds all CO People within the CO.
  • Groups of the form members:couname hold all CO People with a role in the specified COU.

CO Group Memberships and Enrollment

CO Group Memberships can be added as part of an Enrollment Flow by adding an attribute of the appropriate type. For more details, see Registry Enrollment Flow Configuration.

CO Group Memberships can also be added via Organizational Identity Sources when connected to Pipelines.

Nested Groups

As of Registry v3.3.0, Nested Groups allow the members of one group (the "nested" or source group) to automatically be included as members of another group (the "target" group). Nested Groups only confer group membership, they cannot be used to manage group ownership.

To nest a group, edit the target group and click (plus) Add Nested Group. Select the desired source group. Currently, only CO and COU admins can create or remove nestings.

Nested Groups do not imply any sort of hierarchy (CO-1223).

Nested Groups are not designed to scale to very large groups, and in particular manual reconciliation of a very large group with one or more Nested Groups may be problematic. The exact threshold will vary according to the specifics of a given deployment. Deployments experiencing problems reconciling large groups may wish to consider a solution such as Grouper.

Nested Group Boolean Logic

As of Registry v4.0.0, it is possible to apply boolean operators to Group Nestings. The configuration takes place in two places:

  1. AND/OR: Conjunction and disjunction is configured on the Target CO Group, using the setting Require All For Nested Memberships.
    • When enabled, the CO Person must be a member of all nested groups (and not be a member of any exclusion group) in order to become a member of the target group.
    • Otherwise, the CO Person may be a member of any nested group (and not be a member of any exclusion group) in order to be a member of the target group.
    • Changing this setting on the Target CO Group does not automatically recalculate memberships in the group.
  2. NOT: Negation is configured on the CO Group Nesting itself, via the setting Negate Nesting. This setting can be used to create an "exclusion" group, or "negative memberships".
    • When enabled, members of the nested group can not become members of the target group via nesting. (The CO Person can still be added directly to the target group manually.)
    • This setting does not impact CO People who are not members of the source group.
    • CO Group Nestings cannot be edited once created, so the negation setting cannot be changed on an existing nesting. However, the Nesting can be removed and then recreated.

CO Group Nesting Logic

Nested Groups and Validity Dates

Group Nesting honor CO Group Membership Validity Dates. If a Membership is not yet valid or has expired, it will not propagate to the Target Group.

When a CO Group Member valid from or valid through date takes effect, Group Nesting changes will not automatically happen. The ValidateGroupMember job must be used to process these changes.

Group Reconciliation

In general, nested group memberships and memberships of automatic groups are updated in real time as needed. However, If an automatic group or a group with nested groups appears to have incorrect group memberships, the group may be manually reconciled to fix incorrect memberships. To reconcile a group, edit the desired group and click Reconcile.

Manually reconciling a group will not automatically reconcile related groups. For example, if Group A has nested Group B which in turn has nested Group C, and Group C is manually reconciled, it will probably be necessary to also manually reconcile Group B.

See Also

  • No labels