...
There are now 2 LDAP provisioners. One provisions LDAP groups with user entires, and the other provisions LDAP users with Group entries. Lafayette's LDAP DIT (OpenLDAP) is not configured to synchronize groups and users automatically, so parity is maintained via application code. In this case, the same message is delivered to both provisioners so that LDAP accounts and groups have the same information.
Architectural Update - May 2016
In Lafayette's development environment, there have been some interesting and exciting changes made to the Grouper provisioning architecture. The diagrams below tries to capture these changes pictorially. One significant change is that the message routing logic has been removed from the event sources (e.g. the Grouper change log consumer). Event sources send their messages to an exchange that delivers the message to a Provisioner Delivery Service (PSD). The PSD parses the messages it receives and determines routing keys to add to the output messages it delivers to a provisioner. The routing logic is based mostly on the groups related to the message. For example, a message about a member being added to the VPN group could be tagged with a "vpn" field in its routing key.
Additionally, this architecture recognizes a difference between membership provisioners and account provisioners. The College's LDAP provisioners are prime examples of membership provisioners. They only care about subject's relationships to groups. Viewed another way, membership provisioners apply "tags" to subjects in the systems they provision.
Account provisioners, on the other hand, are concerned with identity data associated with a subject. For example, Lafayette uses cloud based services that require users to have accounts within the vendor system. Typical provisioning strategies involve data extracts and nightly file transfers. However, some vendors provide REST APIs for manipulating accounts. Grouper can work in conjunction with an account provisioner to provision and deprovision accounts based on memberships/tags applied to a subject. Because the provisioning process may require identity data other than the subject identifier (e.g. given name, surname, email), the PSD has the ability to resolve subject attributes from external sources. The resolved attributes are included in the messages delivered to account provisioners.
This allows a new event source, an "Entity Change Notifier", to alert account provisioners when the attributes of a subject have changed. Interested account provisioners can update the identity data for a subject in the systems they target.