Evaluation of midPoint against TIER Requirements on an Entity Registry and Related Components

1

Identity Registry

1. Paths in and out

1. RESTful API

2. Asynchronous messaging interface (PUB/SUB, etc)

3. Administrative interface console

1.1 Yes

1.2 No (coming)

1.3 Yes

3

Identity Registry

For new records, assign a permanent unique identifier to map between various source system identifiers. This entity identifier must be made available to the SOR as a response to the entry from the SOR. 

4

Identity Registry

When SOR notifies Registry of an entity/person, the Registry should return the unique identifier that the registry is willing to share externally. The institution may extend what is returned (?) 

5

Identity Registry

Change (add/modify/delete) notifications/events to Provision when an “attribute” changes on a Person record.  Minimally registry records  entity, attribute identifier, verb, old value, new value, timestamp of change

6

Identity Registry

An entity/person can have multiple simultaneous affiliations with an organization. We will use the term affiliation

Yes

7

Identity Registry

Each relationship has a “type” (affiliation) and can have its own set of data describing the individual and this relationship (start/end dates (possibly in the future), dept/center, title(?), who/what added the entry, affiliation type owner); this is data about the 'membership', not about the person who is the member

? This speaks to the need to have, say, membership create date phone # associated with a specific affiliation

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)

9

Support start and end (sunrise/sunset) dates for attributes. Many attributes should support these dates. Phone, email, name(s), affiliations, etc. The date serve as triggers and allow for a live history to be built for an entity.

10

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 conceptual data containers: Entity/Person registry, Groups and Privileges, Party (person/organization) ODS/MDM data stores.   

11

Support extensible local and/or auxiliary information about entities

12

Identity Registry

Associate a “level of confidence” with various attributes (eg self-asserted, verified via gov’t documents, etc)

14

Email notification to user indicating change/pending change to key registry profile information.   (data awareness vs data management)

15

Support Batch purging of entries (e.g., applicants) [May require 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 might even add an affiliation former applicant. A repetitive calling of the API/message (see #1) is the process or doing this. Institution would set up a process to take in a list and call the service. This assures that edit, triggers and all logic involved in setting individuals and communicating changes is followed.

? Batch

"Staus" for soft delete?

51

 Identity Registry?

Access Management?

A Person may have multiple personas that an organization may require them to “act in the role of”, An easy way of switching personas should be constructed as a part of the final solution. Really an acccess management issue

manage with authZ groups? Application specific; Limited registry use case around workflows (e.g. approving request as an X vs Y

35

Identity Registry

Associate multiple authentication methods with an entity in the Registry; ability of UW System students to use credentials from any school they are connected with and be recognized as the same person

?Account linking; Outside systems could handle non-mP authn methods

36

Methods can be internal (ie managed by the organization) or external (ie rely on a different organization to perform the authentication and assert its result; eg social)

Yes, but check. (Federation support); related to #35 above

37

Identity Registry

Each Authn method should have an associated LOA - Assurance measure/value (support for MFA

61

Support various management models for GUEST types ( eg self-registration, require a Sponsor with specific Roles, etc)

62

Support specific terms for GUEST type (eg must be renewed every N months)

57

Ability to spin up "collaboration services" for campus researchers and other groups, where a campus member is designated as the collaboration administrator and can invite other participants, and can enable applications (such as file storage and email lists) for the collaboration.

Yes via group-based provisioning; check with Benn;

56

Ability to store comments associated with any identity and access management edits (including running comments); any time there is a manual change to registry data there should be support for a comment.

2

Identity Matching

As part of Registration from an SOR, invocation of Identity Matching Engine . Registry attempts to match with an existing record

• match  - can positively identify an existing Registry entity/person  - becomes an update
• no match - Can not identify a preexisting registry entity/person - becomes and add
• indeterminate (maybe) identifies possible collisions but match logic is not scored high enough to determine a specific match.  This requires a human interaction and mapping of information.    A new record will be added with a  "suspect duplicate status" .  A data steward (human) type responsibility to resolve these using the merging/splitting function.   The institution will need to decide if provisioning is allowed to these cases prior to resolution.   It is the working groups recommendation that these suspect duplicates are not candidates for service provisioning until they are resolved and no longer a suspect duplicate record.

 deleted former 17 and 18 row duplicate to this.

?

Identity matching is required function. Might be a service call to a Identity match service , Solution to be determined,

47

Identity Matching

Support for finding potential duplicates ("suspect duplicates") entity/persons and adding/merging/splitting records to resolve and the resolution of these registry entries.

19

Identity Registry

Identity Matching

Identity merging needs to be well managed and low impact. The assignment of provisional ids is a method for special use cases of merging

20

Identity Registry

Identity Matching

Attempts to match with an existing record in the Registry use heuristic algorithms

21

Identity Registry

Identity Matching

May rely on “attribute assurance level” when matching input values against Registry entries

e.g. Self-asserted vs SoR authority at attribute level

mP: Scripting of attribute resolution

42

Identity Registry

Audit

Events performed by any of these components must be recorded such that an Audit system can perform queries in various ways and see the results of those queries

43

Audit

Maintain a secure permanent audit record /  history of ALL changes related to an entity record.

32

Identity Registry Authentication

Users must be able to authenticate to the Admin Console

33

Identity Registry Authentication

The Registry should support authentication via CAS and Shibboleth(SAML2) or other methods supported by TIER. The Identifier provided by the authentication mechanism should be used to search the Registry to find the matching record.

34

Identity Registry Authentication

External services must be able to authenticate to the RESTful  /messaging endpoints exposed by the Registry

53

Beyond WEB Only Authentication (e.g. ECP and CLI protocols) for authentication must be enabled as for Research/Collaborative computing

Not registry function;

Make sure it doesn't prevent non-web authN; investigate

40

Credential Mgmt /Storage

Provide a mechanism for (possibly) storing and propagating various secrets supporting authentication (eg passwords, personal certificates, two-factor secrets, lower quality passwords (eg synched gmail), KBA questions/answers

41

Password Reset capabilities must be standardized upon and deployed in the out of the box solutions, with sufficient flexibility to meet institutional business practices. (Probably need to talk through the non-password self-service interface -- )allow emailed one-time links, one-time printed tokens, 2FA and other "private token" mechanisms)

38

Various events can raise and lower the associated LOA (eg password reset over the phone could lower a password-based LOA)

39

Credential Mgmt /Storage

If an internal method has Identity Vetting Requirements support them in some fashion

49

Credential Management

Support for out-of-band password reset mechanism ,(SMS/email, etc)

13

45

Identity Registry

UI Console

Search for users (including users who are no longer active)

46

Identity Registry

UI Console

Support for “renaming” users, and changing any of their attributes (including their various identifiers)

48

Identity Registry UI Console

Support for creating entities in the Registry

50

Identity Registry

 UI Console

Support for authentication to Admin console using various authentication methods

54

 Identity Registry

UI Console

Allow users to see (portions of) their records, and maintain the self-asserted attributes in their record

16

Groups

There is a need to identify a “primary” Affiliation? (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.  

52

Support for authorization framework (different People/Roles authorized to see/change different attributes; LOA of authentication method affects permissions)

60

Groups

Provide support for the creation and maintenance of a type/affiliation of “GUEST” affiliation and many others on Registry records

23

Provisioning

When an “attribute” changes on an entity data was placed for provisioning to consume based on the event.  Entity record an event to be provisioned with minimal field including: entity, attribute identifier, verb, old value, new value, timestamp of change.  

24

Provisioning

Rules that specify Provisioning Operations can trigger these events (invoking specific outbound Connectors associated with specific target systems)

25

Provisioning

These events can be consumed by internal processes which then change other Attributes (eg passing an End Date causes Status to change Active to PENDING)

26

Provisioning

These events can also be consumed by “Connectors”, which then effect changes in external systems.

27

Provisioning

Semantics of a change are determined by each Connector (eg ldap vs google vs LMS, etc)

28

 Provisioning

Receive from the Provisioning System an event describing a change in the Person record; they map that change to the appropriate sequence of events to transmit to their associated external system. (eg provisioning accounts, synchronizing passwords, changing permissions, etc)

29

Provisioning

Events contain: attribute identifier, verb, old value, new value)

30

Provisioning

A mechanism to augment the catalog of Core Connectors must be provided to the community for inter-institutional sharing and implementation.

31

Provisioning

A set of pre-built connectors should be supplied “out of the box” (eg ldap, AD, kerberos, Grouper, SCIM, some popular cloud based services (eg Canvas), etc), Initial for LDAP, Kerberos only

44

It MUST be possible to see the relationships between events in the different components (eg a Registry change triggers a Provisioning change triggers a Connector action)

55

Support for workflows that involve administrative sign-off from specific users (eg approval for certain types of edits)

 Yes

58

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 difficult to define. There are a number of underlying conditions that seem to lead to "partitioning"; these should probably be teased apart and treated individually, as none of them yet seems compelling on its own. (Most seem like a data presentation question - perhaps a locally defined attribute for an account which is then important when Connectors are invoked).

63

Community Documentation and Interaction

Solution extensions must be available in the form of a Marketplace or some other suitable means of presenting a catalog of available functionality, contributed by the community, for utilization by others.

64

Solution must enable the sharing of a common documentation repository as well as a place for school practitioners and service providers to go to find useful instructions, standards, practices and guidelines for building 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

Log files should be available to monitoring tools.

Should be able to discern what data was seen and changed during a session, Which features were used..

Audit log has much of this information, but it is stored in the mP database rather than going to a log file.

Log files are accessible to common log processing tools