You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

About ID Match Integration

Registry v3.3.0 and later support integration with an ID Match server that implements the SOR-Registry Strawman ID Match API, such as COmanage Match. Support is currently available for Organizational Identity Sources (OIS) connected to Pipelines. External ID Match is not currently supported for use with Enrollment Flows.

Registry supports two models for ID Match Integration:

  • Match Before Registry: ID Match is called before SOR data is initially presented to Registry, such that the SOR data already includes the Reference Identifier.
  • Match At Registry: ID Match is called by Registry upon receipt of a new SOR record. The SOR data does not include the Reference Identifier.

Match Before Registry

If the Reference Identifier will already be included in the OIS record, use the Identifier Pipeline Match Strategy. Records with the same Identifier of the specified type will automatically be linked together.

When Match Before Registry is used, the Match Reference Identifier will be available in the Org Identities associated with each backend, as well as the CO Person Record.

Match At Registry

The remainder of this document describes Match At Registry.

When Match At Registry is used, the Match Reference Identifier will be available in the Org Identity Source Record (Org IdentityView Organizational Identity Source Record), but not in the Org Identity itself. It will also be available in the CO Person Record.

Match Attributes

Currently, Registry will look for the following attributes in the Org Identity record and pass those found to the Match server during a match operation:

  • Primary Name (sent as type official)
  • Date of Birth (must be YYYY-MM-DD format)
  • National ID (Identifier of type national)

In addition, the Organizational Identity Source Backend's unique ID (key) will be used as the SOR ID.

Support for additional attributes is expected in a future release.

System of Record Labels

The Match API operates with the concept of a System of Record Label, which is used to identify the calling system making the request to the ID Match server. Registry supports two models for OIS based matching:

  1. Single SOR: A single SOR Label is defined (eg: registry) and used for all Match requests. This model is simpler to set up, but only works if SOR IDs are unique across all OIS backends (and not just within the backend asserting a particular record). For example, if the Student System and HR System might assign the same SOR ID, this model cannot be used.
  2. SOR per OIS: A SOR Label is defined for each OIS backend (eg: sis, hris). This model requires more configuration, but provides for better data isolation.

Match Servers

To define a Match Server, go to RegistryServers(plus) Add a New Server. Set the server type to Match.

On the configuration page, set the appropriate values to connect to the Match Server:

  • Server URL: The URL prefix for Match request. This should look something like https://match.university.edu/match/api/3/v1.
  • Username and Password: As configured.
  • SOR Label: As defined on the Match server, and in accordance with the model selected above. If the SOR per OIS model is chosen, then a Match Server will need to be defined for each SOR Label.

Pipeline Configuration

Configure the Pipeline to have a Match Strategy of External, and select the appropriate Match Server, defined above.

Handling Fuzzy Matches

If the match request is inconclusive, the Pipeline will fail. An administrator must login to the Match server and resolve the conflict. On the next attempt to process the Pipeline, the Reference ID will be obtained and processing will complete.

(warning) When connected to COmanage Match, the SOR should be configured with a Resolution Mode of External.

Updating Match Attributes

Once a Reference Identifier is assigned, if the underlying OIS record is changed (eg: if the person's name is updated in the upstream data source) no automatic rematching will take place. However, an Update Match Attributes request will be sent to the Match server, so that the Match server has the latest attributes for future matching operations.


  • No labels