Diagram

Description

Functional Walk-Thrus

  • Data enters the Provisioning Engine in one of three primary ways – "pushed" into the provisioning interface via a trigger (or other mechanism) fired from the layer above (presumed to be one of the IdM registries), "pushed" into the provisioning interface via an administrative UI (for use by administrators in manually "forcing" provisioning actions to occur), or through a set of adapter API routines designed to allow the provisioning engine itself to retrieve data from the layer above (eg., in the event that completing a provisioning task started by a trigger from an IdM registry requires access to other data in the same or a different registry). It is the responsibility of the "Collection" layer and its associated modules to manage the interface between the registries and the Provisioning Engine, and to marshal and collect the information required by the Provisioning Engine.
  • The provisioning engine in turn is responsible for applying business logic, including attribute access controls, attribute transformations, and dependency computations.
  • The Delivery layer is then responsible for taking the finalized output of the provisioning engine and, based on pre-arranged subscription information, selecting particular consumers and their associated delivery mechanisms and triggering them to provision data (according to their own configuration and protocol specifications) to consumer systems.
  • The Delivery layer relies on a collection of protocol- and/or consumer-specific modules to actually drive its provisioning efforts. Multiple consumers may use the same delivery protocol module (eg., SCIM may be used to provision into more than one consumer) but multiple protocol modules may be used by multiple different consumers.
  • A special case collection of consumers are the presentation layer interfaces (eg., directories). Provisioning into those consumers is not typically performed for their own purposes, but in order to allow still other, secondary consumers to access the provisioned information via "pull" methods (eg., via LDAP). Some consumers may also use custom APIs to directly "pull" data directly from the IdM registries (much as the API adapters associated with the provisioning engine's collection layer do) but those are not considered in-scope in this diagram).
  • All layers of the provisioning stack are responsible for interacting with an audit logging interface, whose responsibility is to build and maintain audit trails suitable for debugging as well as reporting on the history of data passed through the provisioning stack.
  • The stack includes persistence and scheduling mechanisms in support of time-dependent provisioning operations (eg. to support a rule of the form "all terminated employees' "employee" affiliations should be removed at the time of termination, and their electronic mailboxes and Kerberos principals should be disabled 14 days following their termination). The same persistence mechanism might also be used to support "retry-on-failure" options (eg., if a triggered event cannot be processed immediately due to a failure in the consumer system or in the network between the provisioning system and the consumer, the event might be queued and retried on some fixed schedule some number of times before being completely dropped).
  • Scenario 1 - Last Name Change by Employee (update push from registry to consumers with persistence)
  1. Sarah Jones marries and changes her legal last name as recorded by the SSA from "Jones" to "Morgenstern". Her HR representative is notified, and after properly validating her new legal documentation, records the last name change in the HR ERP.
  2. That change makes its way from the HR ERP into a campus person registry, where it results in an update to the "SN" attribute in the person registry for Sarah's entry.
  3. That update causes the registry to call out to an "update" trigger in the provisioning module, passing Sarah's unique identifier, a "change SN" operation tag, and "prior value" and "new value" qualifiers of "Jones" and "Morgenstern" as arguments.
  4. The update routine in the data collection layer of the provisioning module in turn passes the information to the engine layer, which consults subscription data and business logic definitions to determine that three consumer systems are subscribed to SN changes for Sarah's entry, and that the SN value is to be passed to all three of them unmodified.
  5. The engine layer in turn hands off the update to two connector modules – the SCIM module (which passes the update via a SCIM "push" request to two of the three subscribed consumers) and a custom LDAP update module (which passes the update directly into a campus-wide LDAP directory used for white pages searches).
  6. The SCIM updates both succeed, but due to the LDAP consumer being in maintenance mode at the time of the update, the LDAP update fails, and the custom connector module reports an unsuccessful return code back to the engine layer. The Engine layer sends the update to its persistence module, where the update is archived for later resubmission to the custom module.
  7. Some 20 minutes later, the scheduling module triggers a scan of the persistence repository for failed updates, and re-queues the update of Sarah's SN attribute to the custom LDAP module that failed it previously. The LDAP consumer is now in an operative state, and accepts the update. The connector reports successful completion of the operation back to the engine, which records the update as successful via a call to the audit logging module and discards it.
  • Scenario 2: Side Effects of Affiliation Changes (and additional data collection)
  1. John Wesley Harding has been a full-time employee in Accounts Payable for three years, taking a part-time course load in an effort to complete a Masters degree in Finance. He decides to complete his last two semesters of course work as a full-time student, and resigns his staff position to become a full-time student.
  2. The employee ERP system registers John's termination as en employee, while the student ERP system registers his transition from part-time to full-time student status, and notifies the person registry of these changes. The person registry recomputes John's affiliation and primary affiliation attributes, changing his records to reflect that he is now primarily a full-time student.
  3. As an employee, John's preferred name has been restricted to matching his official first name, but as a student, he reported in his enrollment paperwork that his preferred first name is "Wes". As a student, John has the right to assert FERPA protections over some of his student records information, and he has requested anonymity under FERPA (out of concern that his boss might think ill of him were he to find out about his part-time enrollment in the Finance graduate program).
  4. When the person registry calls the provisioning module's "update primary affiliation" trigger to change his affiliation from "staff" to "student", the provisioning engine detects that four consumer systems are subscribed to changes in John's affiliation. It also detects that three of those four consumer systems need to implement FERPA restrictions, while the fourth (an internal system used for student registration) is authorized to maintain student records information despite FERPA restrictions.
  5. The provisioning engine calls out to an API interface in the collection layer to retrieve John's FERPA preferences and his "student preferred first name" attribute from the person registry. After applying the associated business logic, the engine passes affiliation updates to four separate consumers via the SCIM, SPML, and two custom delivery adapters, and passes a "givenName" update to the student registration application via SPML (replacing John's official employee-derived first name of "John" with his preferred student first name of "Wes"). All updates succeed, are recorded via the audit logging layer, and subsequently discarded.