1. About Provisioning: Overview
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 using Push Provisioning. Using Registry plugins, Registry notifies applications when relevant data has changed.
Push Provisioning
In order to enable Push Provisioning, one or more Provisioning Plugins must be installed. By default, Registry ships with various Provisioning Plugins.
Provisioners included with COmanage:
- LDAP
- Grouper
- Mailman
- Salesforce
- Changelog provisioner
You can also write a custom plugin. The Wiki has more information.
Plugin Status
There are four possible values for the Provisioning Plugins:
- Automatic Mode
- Enrollment Mode
- Manual Mode
- Disabled
Automatic Mode Status
Plugins configured for Automatic Mode will be invoked automatically whenever COmanage Registry notices data suitable for provisioning has changed. This data includes
- Address (attached to CO Person Role)
- CO Group Membership
- CO Person Record
- CO Person Role Record
- CO Terms And Conditions Agreement
- Email Address (attached to CO Person)
- Identifier (attached to CO Person)
- Name (attached to CO Person)
- TelephoneNumber (attached to CO Person Role)
- URL (attached to CO Person)
Which records are provisioned are determined by CO Person and Person Role Status.
Enrollment Mode Status
Plugins in Enrollment Mode will only be invoked once, at the conclusion of an Enrollment Flow.
Manual Mode Status
Plugins configured for Manual Mode will only be invoked when a CO Admin explicitly does so. Once one or more Provisioning Targets are defined, you can try them out manually by viewing any active CO Person⚙️ and clicking on Provisioned Services from the menu to the right of the edit screen, and then clicking the Provision target that you have created.
Identifiers & provisioning
Often the unique identifier is provisioned to LDAP using the Registry LDAP Provisioner and then either the application is configured to consume it directly from LDAP or a SAML attribute authority (AA) is configured to resolve it from LDAP and then the SAML service provider (SP) for the application queries the AA to consume the identifier.
Handling Unconfigured Attributes
At times during provisioning, COmanage will have attributes that do not exist in the target system. This situation could arise because,
- COmanage has information that the target system doesn’t yet have, or may never store. (i.e., this information in the target system is NOT authoritative.) In this situation, COmanage should just ignore that these attributes are not configured.
- COmanage has information that is no longer valid, and the target system is more up-to-date. (i.e., the information in the target system is authoritative.) In this situation, COmanage should remove these attributes to update its records.
For some Plugins this choice can be configured in the Provisioning Target rules.