| Include Page | ||||
|---|---|---|---|---|
|
Provisioning tasks
| Task | Description | Status |
|---|---|---|
| Ldap Dao | New interface implementation for efficient LDAP operations | In progress |
| External systems in UI | Endpoints, usernames, passwords, with wizards in UI | In progress |
| New USDU daemon | Resolve all subjects, update unresolvable status, and cache provisioning sync attributes | Almost started |
| Provisioning configuration in UI | Mark folders and groups as provisionable and provide specific configuration | Done |
| Provisioning change log consumer | Look at "sync" objects and provide provisioner with "processed" view of work to do | Done |
| Shadow objects in database | "sync" tables keep track of target system status and cache attribute | Done |
Provisioning in LDAP/AD
Should be handled by the PSPNG. Im not against making a simpler / higher performant option here, or leveraging connid, but for now its PSPNG. Im interested in Duke's implementation and Penn's implementation to get ideas for an alternative, among others.We will leverage PSPNG and retool this into a new component that solves the issues that PSPNG has
Provisioning to SQL
This is in development and will be done soon, for full sync and incrementaltweaked for the new provisioning framework
Provisioning to other systems (e.g. Box, Azure, Atlassian, etc)
...
Or, a lambda (or some other runtime, or service or whatever) can be setup with grouperClient, the jar for this provisioner, and dependent jars. The grouper ESB can send events to SQS FIFO (or rabbitmq or whatever), and those events can run grouperClient code to see if should provision, check the remote info, and issue the same calls as in change log consumer. The Grouper UI would know messages are sent, but doesnt know if the destination is up to date, if messages are out of the queue, etc. You would need separate monitoring to know that messages are read and processed correctly, and you would need to look in separate logs about errors. Calls to Grouper WS can get Grouper data.
Shadow objects
MidPoint has "shadow objects" or state about the target in provisioning, inside of grouper. This makes things a lot easier as far as troubleshooting. We can hold provisioning state separate from the objects themselves so we know things about the provisioned objects even if the group or membership is deleted is grouper. Troubleshooting will be drastically improved.We have shadow objects for subjects, groups, and memberships
Conclusion
I dont know why you would use messaging (option 2) for grouper built in supported provisioners, since you lose a lot and dont gain anything I think. If you have your own custom provisioners (could be written in non-java) and like to run from messages then knock yourself out.
...