Provisioning refers to action of using Registry data to create or remove access to applications and services. COmanage Registry defines a mechanism to extract Registry data for provisioning (via plugins), but there are multiple ways to provision applications from Registry:
In order to enable Push Provisioning, one or more Provisioning Plugins must be installed. By default, Registry ships with the following Plugins:
Plugin | Description | Notes |
---|---|---|
Exports transactions as JSON to a changelog file | Disabled by default | |
GitHub Provisioning Plugin | Provisions group (team) memberships to GitHub | |
Provisions data to a MACE Grouper deployment |
| |
Provisions Unix home directories | Experimental | |
Provisions data to an LDAP server |
|
You can also write a custom plugin.
The first step to setting up provisioning is to define a Provisioning Target.
Once one or more Provisioning Targets are defined, you can try them out manually by viewing any active CO Person record (Organizations > YourCO > People > My Population), clicking on Provisioned Services, and then clicking the Provision action.
It is possible to reprovision all records for a given target, via Organizations > YourCO > Configuration > Provisioning Targets and then selecting the appropriate Reprovision All button. This effectively calls manual provisioning for each defined CO Person and CO Group (whether or not they are active). For large datasets, this operation may take a while.
Note that reprovisioning has no way of knowing how to clear entries from the provisioning target that are not known to COmanage Registry. A typical pattern for reprovisioning all records would be to first clear out the target entirely (eg: delete all records from the LDAP server) and then execute Reprovision All.
Automatic Provisioning is triggered whenever data used for provisioning is changed. This data includes
Which records are provisioned are determined by CO Person and Person Role Status.
Provisioning can be disabled on a per model/save basis by passing the option |
When provisioning is triggered automatically by an update, there is not currently a way to pass to the end user the results of the provisioning operation (other than manually clicking on the Provisioned Services link for the CO Person) (CO-582). If a provisioning plugin fails in such a situation, an error message will be syslog()d (at LOG_ERR
). It is recommended that syslog be suitably configured and monitored to catch any errors with automatic provisioning.
Additionally, a Notification will be generated and sent to the CO Administrators.
Generally, pull provisioning from Registry is not recommended, as it ties applications tightly to the Registry implementation. Use of an intermediary such as LDAP is recommended. |
This model is not currently supported (CO-583).