This page documents the various operations and when a messaging consumer may have to call back into Grouper or other systems for more information
In general, what's needed here is:
Possible transformations could be made by the consumer to make the name meet naming standards in the target endpoint.
When a group is updated, we receive a little bit more information via the changelog, so it's not anticipated that a callback would be needed
Deletion of a group is pretty straight-forward. The provisioner will have to keep in mind that if it receives a Delete Stem
Depending on the downstream system this may or may not be a NOOP.
Depending on the downstream system this may or may not be a NOOP.
When this happens, we need to also delete the groups under the stem. We will have to keep track of the fact that those groups were deleted to handle any out-of-order later Delete Group calls.
In this set of operations, attributes may be used to control how a group appears in the endpoint system. One example could be adding a mail attribute to a group in the target system to give it an email address. The changelog entry should contain enough information for handling the management of this.
When it comes to memberships, the one thing we need to keep in mind is that the Grouper SubjectID may not be the end-user's ID in the target system. This will necessitate a potential lookup in either grouper, the source of the grouper subjects, or some other translation table.
Like Membership updates, callbacks may be necessary here to perform the SubjectID end-system ID translation