About Organizational Identity Sources

Organizational Identity Sources allow for the creation of Organizational Identities linked to an external source or "system of record". These sources can include LDAP servers, REST APIs, SQL databases, flat files, and so on. Custom plugins can be written for arbitrary sources.

Organizational Identity Sources can only be defined on a per-CO basis. If org identities are pooled, Organizational Identity Sources are not supported. Once configured, Organizational Identities can be created from these sources in several ways:

Organizational Identity Sources can be linked to Registry Pipelines in order to automatically create CO Person records.

(warning) When an Organizational Identity is created from a source, it is linked to that source and cannot be manually edited, not even by an administrator. However, it can be manually resynced to pull changes from the source.

(warning) If the corresponding record is removed from the Organizational Identity Source, on the next sync the Org Identity will be set to status Removed, but the Org Identity itself will remain available – it is not deleted.

(warning) If Attribute Enumerations are enabled for any attributes, permitted values for those attributes are constrained to the enumerated options. Source records containing a non-enumerated value will fail to process correctly.

Organizational Identity Sources are available in COmanage Registry v2.0.0 and later.


The terminology used by Registry can be a little confusing when looking at person records related to Organizational Identity Sources.

Sync Modes

Job Shell

Organizational Identity Sources can be configured in one of several sync modes to allow periodic automatic synchronization of records via the Registry Job Shell. Prior to Registry v4.0.0, this is handled with the syncorgsources and forcesyncorgsources tasks. As of Registry v4.0.0, this is handled via the Core Job Plugin Sync job.

(warning) Not all Organizational Identity Source plugins support all sync modes. Check the documentation for any limitations.

Syncing via Job Shell can be disabled on a per-CO basis via CO Settings >> Disable Org Identity Source Sync.


As of Registry v3.1.0, Org Identities associated with an Organizational Identity Source can be resynced on user login to Registry. This is enabled on a per-Organizational Identity Source basis, by enabling the Sync on Login setting.

Because user login crosses COs, when a user logs in the identifier they used to login will be searched against all Organizational Identities (regardless of CO) for matching CO Person records. Then, any Org Identity associated with those CO Person records will be checked for an associated Organizational Identity Source for the Sync on Login setting. In other words, a login event will resync any suitably configured record, not just the one associated with the identifier used to login.

If external databases are configured as Organizational Identity Sources to sync during login, users may experience login delays related to querying those databases.

Sync on login is not supported when Organizational Identities are pooled. Unexpected results may occur.

Linking a Record to a CO Person

By default, creating an Org Identity (via Add New Org Identity From Source or any other mechanism) will not create a CO Person.

If the Org Identity Source is attached to a Pipeline, then that Pipeline will likely create a CO Person for the new Org Identity. If a Pipeline Match Strategy is configured, then the Pipeline may attach the new Org Identity to an existing CO Person if the match conditions are satisfied.

To manually link an Org Identity to an existing CO Person, there are two options:

  1. If no Pipeline is attached to the Org Identity Source, simply link the record manually.
  2. Define an Enrollment Flow. A typical configuration would be
    1. Authorization: CO Admin (or COU Admin)
    2. Identity Matching: Select
    3. Attach an appropriate Enrollment Source, in Select mode
    4. Do not define any Enrollment Attributes

Creating ePPNs

When syncing records from an Org Identity Source, Registry can automatically create an identifier of type ePPN to be injected into the Org Identity created from the Source. This can be useful for (eg) automatically calculating the ePPN of an IdP associated with the Source. There are two settings:

An ePPN will not be generated if one is found in the Org Identity record created from the Source.

CO Group Mappings

Organizational Identity Sources can generate CO Group Memberships via Group Mappings, when the relevant OIS Plugin implements the appropriate interfaces. However, since group memberships attach to a CO Person and not an Organizational Identity, for this to be useful the OIS must typically be attached to a Pipeline, which will then create CO Group Memberships attached to the relevant CO Person record. For OIS Plugins that support this feature, the steps to enable it are:

  1. Make sure the group(s) you want to add memberships to already exists. Automatic groups (such as members groups) cannot be used here.
  2. View the OIS configuration (ie: use the Edit button, not the Configure button), and click Configure Group Mapping.
    1. (info) In Registry versions prior to v3.1.0, the Configure Group Mapping button is available on the index page of Organizational Identity Sources.
    2. The OIS must be connected to a Pipeline for CO Group Memberships to be assigned.
  3. Add one or more mappings.
    1. Attribute: The attribute found in the Organizational Identity Source.
    2. Target Group: The group for which a membership will be created, when the Org Identity has an Attribute matching the specified Comparison and Pattern.
  4. At this point, if you search the Organizational Identity Source, any records matching the defined mappings will also show what CO Group memberships would be assigned if a CO Person record were created from or attached to this source record. However, an action triggering the Pipeline (as described above) must take place. (warning) This means group memberships for existing records will not be assigned until there is a manual sync or a change in the source record.

If a CO Person already has a CO Group Membership (either manually created or from another Organizational Identity Source), a new membership will not be created.

Manually rerunning a Pipeline will not correctly recalculate group memberships, as the original source record is not available for processing. Completely resyncing the Org Identity from Source (which will in turn rerun the Pipeline) will work correctly.

Storing Cached Source Records

When a record has been synced to Registry from the Organizational Identity Source, a cached copy is stored in the Organizational Identity Source Record so that Registry may detect when the source record has been updated. By default, this is a full copy of the record as returned to Registry from the backend (in whatever format is returned from the source, eg JSON, XML, etc). This is also useful for tracing problems, as it is possible for an administrator to look at a cached copy of the data.

However, there may be privacy or data retention concerns that make storing a full copy less desirable for a given deployment. As an alternative, Registry can create a hash of the data to be stored instead. This can be enabled via the Hash Source Records configuration option.

When this configuration is changed, existing records are not affected. Furthermore, since the cached copy will no longer match the current source record, all records from the Source will be considered out of date the next time a sync is performed. It is best to determine the appropriate value for this setting prior to significant production usage.

An additional consideration when enabling Hash Source Records for privacy or data retention reasons is that older copies of the source records are maintained by Changelog Behavior. It is insufficient to enable this setting and perform a full sync to remove all old records from the database, rather manual intervention is required. The following SQL is for general guidance and should not be used directly without first testing against a test server:

SQL> update cm_org_identity_source_records set source_record=md5(source_record) where org_identity_source_id=? and (deleted=true or org_identity_source_record_id is not null);

Filtering Inbound Records

As of Registry v4.1.0, Organizational Identity Sources support Data Filters. Data Filters apply to the structured Org Identity record created by the plugin, and not the cached source record. The cached source record will have the original values obtained from the source, unless Hash Source Records is enabled.