Date: Fri, 29 Mar 2024 13:38:50 +0000 (UTC)
Message-ID: <1527818357.8035.1711719530800@ip-10-10-7-29.ec2.internal>
Subject: Exported From Confluence
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="----=_Part_8034_1229091909.1711719530797"
------=_Part_8034_1229091909.1711719530797
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Location: file:///C:/exported.html
New person from institutional source
New person from institutional source
Narrative
- Record is created in institutional source system.
- Institutionally defined logic invokes the Person Registration and Updat=
e service either via REST API calls (synchronous) or by inserting Person Up=
date messages into the Person Update queue (asynchronous).
- Person Registration and Update service invokes the Person Match / De-du=
plication service to determine if the record supplied matches an existing r=
ecord
- If Person Match returns a definite match, Person Registration invokes U=
nique 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 (sync=
hronous) or puts a message on the Person Update queue (asynchronous).
- If Person Match returns a possible match (verification required), Perso=
n Registration puts a message in a Person Record Verification queue, or cal=
ls an institutionally defined API. Verification is accomplished according t=
o institutionally defined rules and processes, and the decision (match or d=
o not match) is registered using the Person Registration and Update Service=
.
-
- If Person Match returns no possible match, person registration invokes =
Identifier Assignment to generate any needed identifiers, registers r=
ecord to Person Data Store , and puts a message on the Person Update queue.=
- Person Registration Service calls the Group Update Service (synchronous=
) or inserts a Person Update message in the Person Update Queue (asynchrono=
us).
- Groups Service recognizes the new person message in the Person Update q=
ueue and adds group memberships based on person and affiliation data.
- Groups Service inserts group update messages into the Group Update Queu=
e.
- Provisioning component runs rule-based provisioning based on data-drive=
n group memberships
- Could be based on new Group Update messages in Group Update Queue
- Could also be triggered by Orchestration Engine
- Accounts and access are provisioned according to data-driven group memb=
ership
- Provisioning system may generate identifiers. If so, it will generate a=
Person Update message and place it in the Person Update queue
- Provisioning system may generate additional group memberships. If so, i=
t will generate a Group Update message and place it in the Group Update que=
ue.
- User is now able to access resources that are protected by institutiona=
l 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
------=_Part_8034_1229091909.1711719530797--