Currently, Grouper sends messages (via AMQP or Amazon SNS) regarding changes going on in grouper with create/read/update/delete messages pertaining to groups, privileges, memberships, attribute changes, and possibly other activities. With respect to memberships in particular, the change and resulting message is incremental and includes essential information about the change along with the subject, the group and the action - usually ADD/DELETE. While there appears to be general agreement Identity Management related messages need to be delivered in order and never deleted (a deleted message implies not delivering in order), it remains possible actions represented by messages "get lost" either by the message broker system or by the consumer/processor itself on the receiving end of Grouper messages, OR an application fails in some way and needs to be synchronized with data/groups from Grouper.
There are various models for handling this overall problem.
- Sync and Call-back method: send a "sync-and-callback" message to the consumer/application and then it turns around and communicates with Grouper or LDAP or other systems to synchronize data. Grouper Web Services could be used or if Grouper is provisioning to LDAP then reaching out to LDAP might be viable as well. Implied here is not only having a message consumer reading from a queue (usually with appropriate access control to the queue) but also includes configuring Grouper or LDAP or whatever other component to have access control configured as well for the case of the "sync-and-callback" message. A sync message could be identified by the consumer in a variety of ways:
- additional field in the message indicating a "sync-and-callback" message
- the absence of a subject in the incremental message implies 1-(a)
- FULLSYNC method: send a "FULLSYNC" message to the consumer/application looking like an incremental change message for membership and populating the subject array (normally only having 1 item) with all the full membership of the group.