Post PSP Provisioning
Following on from the discussion on the July 3, 2013 Grouper Dev call and the July 29, 2014 Grouper call, this page captures thoughts about the future of the PSP and directions for provisioning strategy. General consensus:
- The PSP is weighted heavily towards trying to be all things to all people.
- Due of the above, it suffers horribly in the area of performance.
- Small, specially built modules focused on quickly and efficiently provisioning specific targets would be more useful to the community than a general solution until such time that a clear market direction emerges in the form of 90% of things speak (SPML/SCIM/Whatever-next-thing)
General Requirements
General requirements moving forward for these purpose built provisioners:
- Support incremental provisioning
- Support bulk reconciliation. Note: they may not be the same executable, but should retain and reuse code and configs where possible/practical.
- When doing bulk-reconciliation the provisioner shall support optionally being pointed at a particular group or folder to reconcile
- Each module should be capable of being run in parallel with other modules
- All provisioning modules will follow the Grouper configuration paradigms with properties overlays and expression language.
- Modules shall provision based either on the location of a group in the tree as done today or using an attribute that will instruct the provisioner to provision the group and/or how to provision the group
First Implementations
Prospective first implementations for Grouper 2.3 are:
- LDAP
- Active Directory (this could be part of the LDAP provisioner or it could be separate)
- Google Applications
- Message Queue (such as Active MQ, Amazon SQS, etc)
Hook vs Changelog Consumer
There was some discussion on the grouper call for July 30, 2014 about whether to use the Change Log for getting notifications about changes or whether to use Grouper Hooks. The argument for Hooks was that it is far faster than the ChangeLog. However, this speed comes at the cost of potentially losing changes if there was a crash during the processing of an event. The result of the discussion was that we'd stick with changelog consumers.
Configuration
The provisioning modules will be configured via properties files using standard grouper configuration mechanisms. Modules will be activated by either calling them from GSH for batch/reconciliation functions, or by the changelog consumer. The provisioners will support two kinds of configuration:
Global Configuration
Global configuration of the modules will be done by properties files specific to all instances of that module. Some of the envisioned properties set in these files include
- Hostnames / connection endpoints of provisioned systems
- Authentication information for provisioned systems
- Logging options
- Scheduling for running batch reconciliations
- Conflict handling
- Thresholds to prevent a provisioner from performing a change that would affect N% of users in a group
- Transformation instructions for turning group names or membership names into a format that the downstream system expects
Group-Level Configuration
Group level configuration would be handled by attributes placed upon groups or folders. The following standard attributes are envisioned:
- $NameProvision – when set on a group, that provisioner will provision the memberships to the target system. When set on a folder, all groups under that folder will be provisioned to the downstream system.
Specific provisioners may specify additional attributes they will use to determine how to provision that group's membership. Some examples are:
- Attribute to describe where in the LDAP DIT the group shall live. If this is set, it will override any global configuration.
- Attribute to describe the type of provisioning (members of this group shall represent Google Apps Organizations vs Google Apps Groups)
- Customized provisioning thresholds (for this group, refuse to provision if more than N% of the membership is affected)