Skip to end of metadata
Go to start of metadata

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.

Provisioning to SQL

This is in development and will be done soon, for full sync and incremental

Provisioning to other systems (e.g. Box, Azure, Atlassian, etc)

Lets 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

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

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.

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.

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...


  • No labels