Enter the full Grouper stem or folder under which the CO groups will be created. A typical deployment pattern is to use the name of the CO as the leaf stem, but it is not a requirement. If the stem does not exist the provisioner will attempt to create it.
The GrouperProvisioner assumes control over all groups under the stem. If you need to "mix" the memberships of groups provisioned by the COmanage GrouperProvisioner with other groups in Grouper that should be done outside of the stem the GrouperProvisioner controls since it will delete groups that it does not recognize. |
The details below only apply if you are using and configuring the deprecated mechanism for how Registry provisions the identifier for Grouper to use as the subject. |
If you are using the deprecated mechanism for how Registry provisions the identifier for Grouper to use as the subject:
When in legacy mode the Grouper Provisioner automatically creates a (per-CO) SQL view that Grouper can use as a source of subjects or users. Before Grouper can use the view, however, you must create a user in your database and grant it SELECT privileges on the view. For example with MySQL/MariaDB you might enter
CREATE USER 'grouper_subject_query'@'localhost' IDENTIFIED BY 'some_password'; GRANT SELECT ON cm_co_grouper_subjects_1 TO 'grouper_subject_query'@'localhost'; |