| Include Page | ||||
|---|---|---|---|---|
|
This page details plans for Grouper provisioning, to be implemented in 2020 after the release of Grouper 2.5. See also the Grouper Generic Provisioning Framework.
The new approach will likely eventually replace PSPNG.
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
We will leverage PSPNG and retool this into a new component that solves the issues that PSPNG has
Provisioning to SQL
This will be tweaked for the new provisioning framework
Provisioning to other systems (e.g. Box, Azure, Atlassian, etc)
Let's say we have a java interface in the grouperClient that approximates this pseudocode. Note, different provisioners have different capabilities based on availability of service at endpoint
| Code Block |
|---|
Java interface RemoteProvisioner {
getRemoteGroups()
getRemoteMemberships(group)
addRemoteMember(group, user)
removeRemoteMember(group, user)
addRemoteGroup(group)
removeRemoteGroup(group)
// batch methods only used if available
getAllRemoteUsers()
getRemoteMemberships(groups)
addRemoteMembers(List<Tuples>[group, user])
removeRemoteMembers(List<Tuples>[group, user])
addRemoteGroups(groups)
removeRemoteGroups(groups)
} |
That is implemented in a jar for a provisioner and has some jar dependencies.
The grouper client can do the Grouper side (getGrouperGroupsForProvisioner(), getGrouperMemberships(group), etc). The grouperClient also does the logic of comparing Grouper results with remote results, and knowing when to issues the calls for addRemoteMember(group, user), etc.
Deployment option for CLC
Then that interface can be hooked up to a change log consumer and run in grouper, and the All Daemons Screen can give end to end information on if provisioning is happening. We can make provisioning specific screens to do this too, and provision a group, or kick off a full sync, and see the progress etc. The diagnostics monitoring can tell you end to end provisioning is happening. One place to look in logs, etc. And those logs can be in the Grouper UI. Calls direct to the database are faster than calls that go through the WS.
Deployment option outside of Grouper
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
We have shadow objects for subjects, groups, and memberships
Conclusion
I don't 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.
We need to keep the number of programming languages in the Grouper project to a minimum so at this point we need to keep things Java centric where possible.
If we can use connid to implement that interface, I think that would be a big win to be able to have dynamic configuration screens with validation, take advantage of connid library, share connectors with midpoint, etc.
Other enhancements
We should make a table to keep track of which CLCs process which change logs, so things can happen out of order if a CLC wants to do that...
See Also