Child pages
  • New person from institutional source
Skip to end of metadata
Go to start of metadata

Narrative

  1. Record is created in institutional source system.
  2. Institutionally defined logic invokes the Person Registration and Update service either via REST API calls (synchronous) or by inserting Person Update messages into the Person Update queue (asynchronous).
  3. Person Registration and Update service invokes the Person Match / De-duplication service to determine if the record supplied matches an existing record
    1. If Person Match returns a definite match, Person Registration invokes Unique Identifier Creation to generate any additional identifiers (if needed), links with an existing person, add any address, contact and affiliation data to Master Person Store and either calls the Group Update Service (synchronous) or puts a message on the Person Update queue (asynchronous).
    2. If Person Match returns a possible match (verification required), Person Registration puts a message in a Person Record Verification queue, or calls an institutionally defined API. Verification is accomplished according to institutionally defined rules and processes, and the decision (match or do not match) is registered using the Person Registration and Update Service.
    1. If Person Match returns no possible match, person registration invokes Identifier Assignment to generate any needed identifiers,  registers record to Person Data Store , and puts a message on the Person Update queue.
  4. Person Registration Service calls the Group Update Service (synchronous) or inserts a Person Update message in the Person Update Queue (asynchronous).
  5. Groups Service recognizes the new person message in the Person Update queue and adds group memberships based on person and affiliation data.
  6. Groups Service inserts group update messages into the Group Update Queue.
  7. Provisioning component runs rule-based provisioning based on data-driven group memberships
    1. Could be based on new Group Update messages in Group Update Queue
    2. Could also be triggered by Orchestration Engine
  8. Accounts and access are provisioned according to data-driven group membership
  9. Provisioning system may generate identifiers. If so, it will generate a Person Update message and place it in the Person Update queue
  10. Provisioning system may generate additional group memberships. If so, it will generate a Group Update message and place it in the Group Update queue.
  11. User is now able to access resources that are protected by institutional access control systems. Group and attribute data can be released to local and federated applications to provide authorization information for use in access control decisions.

See also

  • No labels