The Grouper Provisioning Plugin provisions groups and memberships in groups to an Internet2 Grouper instance using the Grouper web services interface.
Registry CO Person Transaction | Grouper Action |
---|---|
Add | None, provisioning is for CO Group records and memberships only |
Edit | None, provisioning is for CO Group records and memberships only |
Enter Grace Period | None, provisioning is for CO Group records and memberships only |
Expiration / Becomes Inactive | None, provisioning is for CO Group records and memberships only |
Unexpire / Becomes Active | None, provisioning is for CO Group records and memberships only |
Delete | None, provisioning is for CO Group records and memberships only |
Manual Provision | None, provisioning is for CO Group records and memberships only |
Registry CO Group Transaction | Changelog Action |
---|---|
Add | Provision CO Group record (including memberships) to Grouper |
Edit | Provision CO Group record (including memberships) to Grouper |
Delete | Delete CO Group record (and memberships) to Grouper |
Manual Provision | Provision CO Group record (including memberships) to Grouper |
Provisioning of groups from Registry into Grouper is per CO with all groups for a CO provisioned under a single (configurable) stem or folder in Grouper. All groups in Registry, with the exception of the 'admin' and 'members' groups for COUs, are provisioned directly under the configured stem or folder for the CO. The 'admin' and 'members' groups for COUs are provisioned into a stem or folder hierarchy that mirrors the COU parent-child relationship (if any) in Registry.
A change in the COU hierarchy in Registry, such as changing a parent-child COU relationship or deleting a COU parent, will not be reflected in Grouper. At this time the Grouper web services component does not support moving stems or folders. A request to the Grouper team to implement such a feature for the web services component has been made (CO-1043). We do not recommend changing the COU parent-child relationships once established when using the Grouper Provisioner. Renaming COUs and deleting COUs (with no children or roles) is supported. |
If you plan for users to access the Grouper UI and for that access to be managed using COmanage Registry, we recommend you create a CO unique identifier and use it as the expected identifier that the Grouper UI will see and map to subjects (Grouper users). |
Before configuring a Grouper Provisioner for a CO the Grouper deployment must be operational. Specifically you will need:
We recommend that before configuring a Grouper Provisioner for a CO you have already enrolled or onboarded at least one user to create a CO Person record with an active status. |
Ensure that the Registry database user (configured in database.php in the Config directory for your Registry deployment) has the CREATE VIEW privilege. For example with MySQL you might do
GRANT CREATE VIEW ON registry.* TO 'comanage'@'localhost'; |
if your Registry database is named 'registry' and the user is 'comanage'.
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 you might enter
CREATE USER 'grouper'@'localhost' IDENTIFIED BY 'some_password'; GRANT SELECT ON cm_co_grouper_subjects_1 TO 'grouper'@'localhost'; |
Grouper needs to be configured to use the view as a subject source. To do this you must edit the Grouper configuration file sources.xml and add a <source> element (and child elements) section for the database view for the CO. Note that a Grouper sources.xml file may include multiple <source> elements (some are for internal use by Grouper itself).
Depending on the details of your Grouper deployment and how you manage it, you may need to edit the sources.xml file in three different places (the Grouper API, the WS tree, and the UI tree). You may, again depending on the details of your deployment, need to redeploy the Grouper WAR file(s). You will definitely need to restart the Grouper WS and UI after making changes to the sources.xml file(s). |
It is critical that the Grouper API (used for example by the Grouper loader), the UI, and the WS all use the same version of the sources.xml file, or you will experience unpredictable behavior with Grouper and the COmanage Registry Grouper Provisioner. |
To test the COmanage subject source (view) for Grouper browse to the Grouper UI as a privileged user (often 'GrouperSystem'). In the UI search box (top right) enter the name of a person in the CO. Grouper should find the CO Person. Click on the user name to see the details that COmanage Registry makes available for Grouper.
You can initiate the initial provisioning and reconciliation of groups and memberships from COmanage Registry to Grouper by choosing Configuration -> Provisioning Targets and then clicking 'Reprovision All' for the Grouper Provisioner instance you have configured.