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.
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 are those which Registry automatically manages the memberships of.
Identifiers cannot be assigned to Automatic CO Groups. (CO-1829) |
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.
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:
GroupEnum::Admins
and a null cou_id
. The default name for the group is CO:admins
.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:
admin
group determines CO Administrators.admin:couname
determine COU Administrators.Approvers Groups are used to determine Enrollment Flow approvers. Approver Groups are automatically created when a CO or COU is created.
Since v4.3.0:
GroupEnum::Approvers
and a null cou_id
. The default name for the group is CO:approvers
.GroupEnum::Approvers
and a non-null cou_id
. The default name for COU approver groups is CO:COU:COU_Name:approvers
.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:
GroupEnum::ActiveMembers
and a null cou_id
. The default name for the group is CO:members:active
.GroupEnum::AllMembers
and a null cou_id
. The default name for the group is CO:members:all
.GroupEnum::ActiveMembers
and a non-null cou_id
. The default name for the group is CO:COU:COU_Name:members:active
.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:
members
group holds all CO People within the CO.members:couname
hold all CO People with a role in the specified COU.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.
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 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. |
As of Registry v4.0.0, it is possible to apply boolean operators to Group Nestings. The configuration takes place in two places:
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.
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.