Date: Fri, 29 Mar 2024 14:01:24 +0000 (UTC) Message-ID: <1056534537.8065.1711720884093@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_8064_325827169.1711720884091" ------=_Part_8064_325827169.1711720884091 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Support/advertise a strong conceptual difference b= etween email and user ID
Support widely used standard authn/authz protocols= for federations (OAuth2 + SAML2)
Support multi-site replication and synchronization=
Support unicode (and make clear what character set= is supported)
Avoid/disallow re-use of persistent identifiers (o= r define =E2=80=9Cpersistent=E2=80=9D better!)
Allow non-person Entities
Client /Agents
Service Accounts
Department/Organization
Internet of Things (devices, IOT)
= li>Suggest various ways people can model their data; = Do we want a registry that could host different models?
Relational vs LDAP
Use as delivered vs. customize
=E2=80=9CBuilt in=E2=80=9D schemas vs. common = configurations (that can be customized)
Companion Doc for Data minimal requirement for ite= ms marked registry Mi= nimal Entity Registry Definition/Logical Design
# |
Component |
Requirement |
R1 - minimum registry feature |
Notes |
---|---|---|---|---|
1 |
Identity Registry |
|
yes |
Flat file removed by consensus of the workgroup = .("bulk up/downloa= d"; SFTP or similar to make the file available to ingest via message or API= logic) |
3 |
Identity Registry |
For new records, assign a permanent unique identifier to map be= tween various source system identifiers. This entity identifier = must be made available to the SOR as a response to the entry from the SOR.&= nbsp; |
yes |
This is perhaps the single most important thing = the registry must do. |
4 |
Identity Registry |
When SOR notifies Registry of an entity/person, return relevant= info to that SOR . Minimally, the unique identifier assigned by the Entity= Registry and the institution may extend what is returned. |
yes |
SOR return INFO can be extensible |
5 |
Identity Registry |
Change (add/modify/delete) notifications/events to Provision wh= en an =E2=80=9Cattribute=E2=80=9D changes on a Person record. Minimal= ly registry records entity, attr= ibute identifier, verb, old value, new value, timestamp of change = span> |
yes | This feeds the requirement 23 for Pro= visioing Component. |
6 |
Identity Registry |
An entity/person can have multiple simultaneous affiliations&nb= sp;with an organization. We will use the term affiliation |
yes |
Need consistency on =E2=80=9Crelationship=E2=80=9D =E2=80=9Crol= e=E2=80=9D =E2=80=9Caffiliation=E2=80=9D |
7 |
Identity Registry |
Each relationship has a =E2=80=9Ctype=E2=80=9D (affiliation) an= d can have its own set of data describing the individual and this relations= hip (start/end dates (possibly in the future), dept/center, title, who= /what added the entry, affiliation type owner) |
yes |
Anything more than this should be handled in the Groups co= mponent. It will be deemed not a registry function. |
8 |
Identity Registry |
An entity can have multiple affiliation relationships with= the same "type" value (eg faculty member who is associated= with multiple academic departments) |
yes |
This would also be handled by the groups database. How af= filiation is handled by the registry vs the grouping component is to some d= egree institutionally selectable. The workgroup believes that the affi= liation relation ships are significant enough to belong in the registry.&nb= sp; The may be simultaneously built out in the grouping componen= t or fed as data events from the registry to the grouping component. &= nbsp; Choice to be made. |
9 |
Identity Registry | Support start and end (sunrise/sunset) dates for attributes. Ma= ny attributes should support these dates. Phone, email, name(s), affi= liations, etc. The date serve as triggers and allow for a live = history to be built for an entity. |
yes | The live history allows the data to provid= e all names a person has been known as or ... , data is rarely (maybe never= ) deleted they are simply not current info. |
10 |
Identity Registry | The Registry does not need to hold all IAM data within it= . Rather data is to be considered to be contained in one of three con= ceptual data containers: Entity/Person registry, Groups and Privileges,&nbs= p;Party (person/organization) ODS/MDM data stores. = |
yes | These can take the forms of relational data, LDA= P, etc The need for a FAT everything registry is a waning techn= ique. Organizations have built Perdon ODS data, person data hubs that= serve all applications . These can include the IAM Entity Registry.&= nbsp; |
11 |
Identity Registry | Support extensible local and/or auxiliary information about ent= ities |
yes | |
12 |
Identity Registry |
Associate a =E2=80=9Clevel of confidence=E2=80=9D with various = attributes (eg self-asserted, verified via gov=E2=80=99t documents, etc) |
no | This is different than the entities LOA.&n= bsp; It is a measure on how data was collected and vetted on an attribute /= sourcing level. For example: a person may self assert their name is = John Doe, but at personal gov't documents indicate John Doe should really b= e Jonathon Doe. The level of confidence for the info is better after = the vetting at HR than when self asserted. |
14 |
Identity Registry | Email notification to user indicating change/pending change&nbs= p;to key registry profile information. |
yes | Similar features should exist for Credential man= agement and provisioning/de-provisioning |
15 |
Identity Registry | Support Batch purging of entries (e.g., applicants) [May requir= e a different concept than "purge". "Permanent disable"?, should use a soft delete mechanism= ]. Generally this will be the ending of an affiliation like applicant it mi= ght even add an affiliation former applicant. A repetitive calling of= the API/message (see #1) is the process or doing this. Institution wo= uld set up a process to take in a list and call the service. This ass= ures that edit, triggers and all logic involved in setting individuals and = communicating changes is followed. |
No |
Should be a soft delete concept - usage og= f one of the methods in item 1. Flat file batch will not be supported= . The use of this is standard affiliation management |
51 |
|
A Person may have multiple personas that an organization may re= quire them to =E2=80=9Cact in the role of=E2=80=9D, An easy way of switchin= g personas should be constructed as a part of the final solution. |
yes | Not R1, but data model should support extension later |
35 |
Identity Registry=
|
Associate multiple authentication methods with an entity in the= Registry |
yes | 36 is same requirement |
36 |
|
Methods can be internal (ie managed by the organization) or ext= ernal (ie rely on a different organization to perform the authentication an= d assert its result; eg social) |
yes | Not =E2=80=9Cmust support anything=E2=80=9D, but must support a= n external authN method |
37 |
Identity Registry |
Each Authn method should have an associated LOA - Assurance mea= sure/value |
no | not sure if minimum - but is a good requir= ement |
61 |
|
Support various management models for GUEST types ( eg self-reg= istration, require a Sponsor with specific Roles, etc) |
yes | |
62 |
|
Support specific terms for GUEST type (eg must be renewed every= N months) |
yes | Must have a parameter specified duration begin end date above= span> |
57 |
|
Ability to spin up "collaboration services" for campus research= ers and other groups, where a campus member is designated as the collaborat= ion administrator and can invite other participants, and can enable applica= tions (such as file storage and email lists) for the collaboration.<= /p> |
maybe | Restful API / VO membership / &nbs= p; May be related to Groups as well. ??? Is this minimum. ? = |
56 |
|
Ability to store comments associated with any edits (including = running comments) |
yes | Manual over ride. stewardship/admin ...&nb= sp; - move to Audit. |
2 |
Identity Registry Identity Matching = |
As part of Registration from an SOR, invocation of Identity Mat= ching Engine . Registry attempts to match with an existing record
|
kh, wc, hs, eg |
deleted former 17 and 18 row duplicate = to this.
Identity matching is required function. Might b= e a service call to a Identity match service , Solution to be determined,= p> |
47 |
Identity Matching <= /td> | Support for finding potential duplicates ("suspect duplicates")= entity/persons and adding/merging/splitting records to resolve and th= e resolution of these registry entries. |
Moved to pair with the requirement -= matching function item # 2 | |
19 |
Identity Registry Identity Matching |
Identity merging needs to be well managed and low impact. The a= ssignment of provisional ids is a method for special use cases of merging= span> |
||
20 |
Identity Registry Identity Matching |
Attempts to match with an existing record in the Registry use h= euristic algorithms |
||
21 |
Identity Registry Identity Matching |
May rely on =E2=80=9Cattribute assurance level=E2=80=9D when ma= tching input values against Registry entries |
||
42 |
Identity Registry Audit |
Events performed by any of these components must be recorded su= ch that an Audit system can perform queries in various ways and see the res= ults of those queries |
kh, wc=
, hs, eg |
|
43 |
Audit |
Maintain a secure permanent audit record / history o= f ALL changes related to an entity record. |
||
32 |
Identity Registry Authentication |
Users must be able to authenticate to the Admin Console<= /p> |
eg | IF Admin console is not included (see #1)<= /td> |
33 |
Identi= ty Registry Authentication |
The Registry should support authentication via CAS and Shibbole= th(SAML2) or other methods supported by TIER. The Identifier provided by th= e authentication mechanism should be used to search the Registry to find th= e matching record. |
kh, wc=
, hs, eg |
OAUTH2, etc are valid candidates assupport is considered = moving forward. |
34 |
Identi= ty Registry Authentication |
External services must be able to authenticate to the RESTful&n= bsp; /messaging endpoints exposed by the Registry |
kh, wc=
, hs, eg |
This security function is currently being = discussed(march 2017) |
53 |
Ide= ntity Registry Authentication | Beyond WEB Only Authentication (e.g. ECP and CLI protocols) for= authentication must be enabled as for Research/Collaborative computing |
|
|
40 |
Credential Mgmt /Storage |
Provide a mechanism for (possibly) storing and propagating vari= ous secrets supporting authentication (eg passwords, personal certificates,= two-factor secrets, lower quality passwords (eg synched gmail), KBA questi= ons/answers |
see 41 and 42 are these the same. |
|
41 |
Credential Mgmt /Storage | Password Reset capabilities must be standardized upon and deplo= yed in the out of the box solutions, with sufficient flexibility to meet in= stitutional business practices. (Probably need to talk through the non-pass= word self-service interface -- )allow emailed one-time links, one-time prin= ted tokens, 2FA and other "private token" mechanisms) |
Do we need to call out the ability to mana= ge account and passwords securely? wc | |
38 |
Credential Mgmt /Storage | Various events can raise and lower the associated LOA (eg passw= ord reset over the phone could lower a password-based LOA) |
||
39 |
Creden= tial Mgmt /Storage |
If an internal method has Identity Vetting Requirements support= them in some fashion |
yes | vetting/ proofing etc.. |
49 |
= Identity Registry= p> UI Console |
Support for out-of-band password reset mechanism ,(SMS/email, e= tc) |
similar to 41 | |
13 |
Credential Management | Support for provisioning codes (one-time use link/code/token) f= or account claims |
Reclassified to Credential management | |
45 |
Identity Registry= UI Console |
Search for users (including users who are no longer active) |
eg | needed by other functions (eg password reset) |
46 |
= Identity Registry= p> UI Console |
Support for =E2=80=9Crenaming=E2=80=9D users, and changing any = of their attributes (including their various identifiers) |
eg | eg: =E2=80=9Cany=E2=80=9D is oversta= ted for r1 |
48 |
= Identity Registry UI Console |
Support for creating entities in the Registry |
eg | eg: Unless this is solely PoC, ne= ed some ability to create people not from SoR wc: = do we need this in the POC, need to review 1.4 and 48 (are these the same)<= /span> |
50 |
= Identity Registry= p> UI Cons= ole |
Support for authentication to Admin console using various authe= ntication methods |
||
54 |
= Identity Registry= p> UI Conso= le |
Allow users to see (portions of) their records, and maintain th= e self-asserted attributes in their record |
eg: seems an easy addition; tempted = to put as R1 As : POC | |
16 |
Groups |
There is a need to identify a =E2=80=9Cprimary=E2=80=9D Affilia= tion? = (Primary affiliation calculation is a requirement to assist in handling the= EduPerson Primary affiliation., calc required when individual has multiple= distinct types of affiliation student and employee for example institution= must decide how they handle this. |
Seems to be best handled in the Grouping t= ool. This could be fed to registry based on grouping result. | |
52 |
Groups | Support for authorization framework (different People/Roles aut= horized to see/change different attributes; LOA of authentication method af= fects permissions) |
kh, wc=
, hs |
Handle with Groups eg: This seems= broader than =E2=80=9Cdifferent permissions=E2=80=9D. I think this was ref= erring to literally a general purpose privilege management service.<= /span> |
60 |
Groups |
Provide support for the creation and maintenance of a type/affi= liation of =E2=80=9CGUEST=E2=80=9D affiliation and many others on Regi= stry records |
seems like a group feature related to affi= liation(s) that are loosely attached to the institution | |
23 |
Provisioning |
When an =E2=80=9Cattribute=E2=80=9D changes on an entity data w= as placed for provisioning to consume based on the event. Entity= record an event to be provisioned with minimal field including: entit= y, attribute identifier, verb, old value, new value, timestamp of change.&n= bsp; |
wc, hs, eg | Likely to use a logging concept initially, think= through this in more detail. An API call or a messaging channel shou= ld be the consumer. traditional connectors are valid in this use= case as well. Grouping facility (grouper or something else) clearly = must be a consumer of the event. The knowledge sharing of en= tity info seems well suited for ayschronous messaging to pub-sub style cons= umers. However, technology can vary by institution. (Prov= isioning and Connectors 23-31 wc 4/22) |
24 |
Provisioning |
Rules that specify Provisioning Operations can trigger these ev= ents (invoking specific outbound Connectors associated with specific target= systems) |
eg | |
25 |
Provisioning |
These events can be consumed by internal processes which then c= hange other Attributes (eg passing an End Date causes Status to change Acti= ve to PENDING) |
||
26 |
Provisioning |
These events can also be consumed by =E2=80=9CConnectors=E2=80= =9D, which then effect changes in external systems. |
eg | |
27 |
Provisioning |
Semantics of a change are determined by each Connector (eg ldap= vs google vs LMS, etc) |
kh, eg= , wc |
|
28 |
Provisioning
|
Receive from the Provisioning System an event describing a chan= ge in the Person record; they map that change to the appropriate sequence o= f events to transmit to their associated external system. (eg provisioning = accounts, synchronizing passwords, changing permissions, etc) | eg | |
29 |
Provisioning |
Events contain: attribute identifier, verb, old value, new valu= e) |
||
30 |
Provisioning |
A mechanism to augment the catalog of Core Connectors must be p= rovided to the community for inter-institutional sharing and implementation= . |
||
31 |
Provisioning |
A set of pre-built connectors should be supplied =E2=80=9Cout o= f the box=E2=80=9D (eg ldap, AD, kerberos, Grouper, SCIM, some popular clou= d based services (eg Canvas), etc), In= itial for LDAP, Kerberos only |
wc, hs, eg | IAM side of connector speaks messages and/or restful APIs |
44 |
Provisioning | It MUST be possible to see the relationships between events in = the different components (eg a Registry change triggers a Provisioning chan= ge triggers a Connector action) |
||
55 |
Provisioning | Support for workflows that involve administrative sign-off from= specific users (eg approval for certain types of edits) |
|
|
58 |
Consent | The solution may enable user to be in control of their personal= data stores such that when relying parties are requesting access to those = data, users should have fine-grained controls over what pieces of personal = data are shared with such parties. |
||
59 |
Partitioning |
Partitioning is mentioned in several use cases, and is difficul= t to define. There are a number of underlying conditions that seem to lead = to "partitioning"; these should probably be teased apart and treated indivi= dually, as none of them yet seems compelling on its own. (Most seem like a = data presentation question - perhaps a locally defined attribute for an acc= ount which is then important when Connectors are invoked). |
??? DO not understand this. = Can anyone clarify.. Is this from investor sessions.. &nb= sp; or ??? |
|
63 |
Community Documentation and Interaction= |
Solution extensions must be available in the form of a Marketpl= ace or some other suitable means of presenting a catalog of available funct= ionality, contributed by the community, for utilization by others.= p> |
||
64 |
Community Documentation and Interaction | Solution must enable the sharing of a common documentation repo= sitory as well as a place for school practitioners and service providers to= go to find useful instructions, standards, practices and guidelines for bu= ilding end-to-end services based on TIER components |
||
65 |
Standards and Enforcement |
The program must assert and enforce Policy Standards = |
||
66 |
Policy and Performance Monitoring = td> | Log files should be available to monitoring tools. Should be able to= discern what data was seen and changed during a session, Which features we= re used.. |
kh, wc=
, hs |
Use ELK stack eg. Agree in princi= ple, abstain on anything but =E2=80=9Clog files exist and monitoring tools = can be made to read them=E2=80=9D |