1. As the platform administrator or a CO administrator use the Collaborations menu to select the CO as the active working CO.
  2. From the Configuration menu choose Provisioning Targets to open the Provisioning Targets view.
  3. Click "Add Provisioning Target".
  4. Complete the form for the new provisioning target:
    1. Enter a description for this provisioner, such as "Primary Grouper Deployment".
    2. Choose "Grouper Provisioner" as the plugin.
    3. Select "Automatic Mode" as the status.
  5. Click "Add" to create the provisioner. A form to configure the Grouper Provisioner instance will be opened.
  6. Complete the form to configure the Grouper Provisioner instance:
    1. Enter a URL with scheme and host for the Grouper WS instance, eg. https://some.server.edu
    2. Enter the context path on the server where the Grouper WS can be found, eg. /grouper-ws
    3. Enter the login for the user that will access the Grouper WS and invoke WS calls, eg. GrouperSystem
    4. Enter the password for the user that will access the Grouper WS and invoke WS calls

    5. 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.

    6. Choose the identifier to be used as the Grouper subject identifier. You may use any identifier that is attached to CO Person records. The identifier may be generated by Registry or may only be consumed by Registry. Grouper must be able to find the subject in one of its configured subject sources. If Registry is generating the identifier you will probably want to provision it using another provisioner to a system that Grouper can use as a subject source. A LDAP directory server and the Registry LDAP Provisioner Plugin are common choices when Registry is creating the identifier. A commons scenario is to use the CO unique identifier if you defined one, configure it to be provisioned to LDAP as part of the person record, and then configure the Grouper Provisioner to use it as the subject source.
    7. Choose the identifier to be used as the Grouper UI login identifier. You will probably want to use the CO unique identifier if you defined one.
    8. Choose the email identifier to be used as the email attribute for the Grouper subject or user. A typical deployment pattern is to use the official email for the CO Person.
    9. Click "Save" to save the configuration.

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:

  1. Check the Legacy subject box. The configuration for the Grouper subject identifier is hidden and the configuration for the subject source view name is revealed. The subject source view name is pre-populated with a default in the text box. We strongly recommend using the recommended default.  Please note the name of the view.
  2. Click "Save" to save the configuration.

  3. 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';
  • No labels