Skip to end of metadata
Go to start of metadata

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

TaskDescriptionStatus
Ldap DaoNew interface implementation for efficient LDAP operationsIn progress
External systems in UIEndpoints, usernames, passwords, with wizards in UIIn progress
New USDU daemonResolve all subjects, update unresolvable status, and cache provisioning sync attributesAlmost started
Provisioning configuration in UIMark folders and groups as provisionable and provide specific configurationDone
Provisioning change log consumerLook at "sync" objects and provide provisioner with "processed" view of work to doDone
Shadow objects in database"sync" tables keep track of target system status and cache attributeDone

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

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


  • No labels