Intent Driven Provisioning

Registry v4 provisioning is implemented by ProvisionerBehavior, which operates during callbacks (mostly afterSave). This approach, referred to as Side Effect Driven Provisioning, has a certain simplicity, but also requires significant annotation during more complex operations (eg: during Enrollment Flows, Pipelines, or higher level API transactions) to prevent superfluous provisioning of intermediate state.

In Registry PE, only the primary provisionable models (eg: Person, Group, Service) will implement the new ProvisionerBehavior. ProvisionerBehavior will not intercept callbacks, but will instead make available a provision() function on these models. Any model that wishes to trigger provisioning on update, including secondary models such as Identifier as well as plugin based models such as Authenticators, will declare the types of primary models that are supported via a TableMetaTrait function.

For singleton updates via the UI or API, StandardController will check which provisionable models are supported, and if appropriate trigger provisioning for the subject. For more complex operations, the appropriate code will trigger provisioning where desired (as opposed to the v4 method of suppressing provisioning when it is not desired).

The default Provisioner Target configuration will be "Queue on Error", not "Automatic".

Supported Models

Additional models, including some configuration models such as COUs, will be available as Supported Models, creating a unified interface for Primary Models (People, Groups, Services) and reference data (COUs, Terms & Conditions).

Changes to Plugin Interface

  1. Plugins will declare which Supported Models they are interested in, and will not be called for undeclared models.
  2. At provisioning time, the data passed to the Plugin will include External Identity information as part of the request.
  3. A clearer interface will be implemented for Plugins to return a Provisioning Target-specific identifier (PTI). Once generated, this identifier will be passed to the Plugin. (Use of this Identifier will be optional.)
  4. ProvisioningActionEnum will be simplified down to these values:
    1. Eligible: The subject is eligible for full provisioning (eg: Active, Grace Period)
    2. Ineligible: The subject is not eligible for full provisioning (eg: Suspended, Locked, Expired), but it may be desirable to maintain a skeletal record for referential integrity
    3. Deleted: The subject's record has been deleted or set to Archived status
  5. Records that are in an incomplete state (eg: Pending Approval) are not eligible for provisioning.
  6. Expired or Suspended attributes (Group Membership, Person Roles, etc) will continue to be removed from the data passed to the plugin.
  7. A new interface will be defined to allow a Plugin (using the PTI) to query for the state of a subject. enabling bidirectional reconciliation via JobShell.
  8. A new interface for "dry run" model will allow plugins to report on what changes would be made based on the current provisioned data.

  • No labels