Date: Fri, 29 Mar 2024 07:44:24 +0000 (UTC) Message-ID: <300149344.7639.1711698264665@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_7638_1181967588.1711698264665" ------=_Part_7638_1181967588.1711698264665 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Organizational Identity Sources allow for the creation of Organizational Identiti= es linked to an external source or "system of record". These sources ca= n 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. I= f org identit= ies 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 automatic= ally create CO Person records.
When an Or= ganizational Identity is created from a source, it is linked to that source= and cannot be manually edited, not even by an administrator. However, it c= an be manually resynced to pull changes from the source.
If the cor= responding record is removed from the Organizational Identity Source, on th= e next sync the Org Identity will be set to status Removed, b= ut the Org Identity itself will remain available =E2=80=93 it is not d= eleted.
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.
Organizational Identity Sources can be configured in one of several sync=
modes to allow periodic automatic synchronization of records via the =
Registry Job Shellforcesyncorgsources
tasks. A=
s of Registry v4.0.0, this is handled via the Core Job Plugin Sync
job.
syncorgsources
task will skip any unchanged records, w=
hile the forcesyncorgsources
task will =
process records even when they are unchanged. forcesyncorg=
sources
is available as of Registry v3.2.0. As of Registry v4=
.0.0, it is accessed via the --force
flag of the CoreJob Sync job.forcesyncorgsources
task is run, the getChangeList() capability supported =
by some plugins cannot be used. This may result in significantly longer pro=
cessing times. Not all Or= ganizational Identity Source plugins support all sync modes. Check the docu= mentation 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
Because user login crosses COs, when a user logs in the identifier they = used to login will be searched against all Organizational Identities (regar= dless of CO) for matching CO Person records. Then, any Org Identity associa= ted with those CO Person records will be checked for an associated Organiza= tional Identity Source for the Sync on Login setting. In othe= r words, a login event will resync any suitably configured re= cord, 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.
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 crea= te a CO Person for the new Org Identity. If a Pipeline Match Strategy is co= nfigured, 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:
When syncing records from an Org Identity Source, Registry can automatic= ally create an identifier of type ePPN to be injected into the Org Identity creat= ed from the Source. This can be useful for (eg) automatically calculating t= he ePPN of an IdP associated with the Source. There are two settings:
@<=
/code>.
An ePPN will not be generated if one is found in the Org Identity record= created from the Source.
Organizational Identity Sources can generate CO Group Memberships via&nb= sp;Group Mappings, when the relevant OIS Plugin implements the app= ropriate interfaces. However, since group memberships attach to a CO Person= and not an Organizational Identity, for this to be useful the OIS must typ= ically be attached to a Pipeline, which will then create CO Group Memberships attached to th= e relevant CO Person record. For OIS Plugins that support this feature, the= steps to enable it are:
If a CO Person already has a CO Group Membership (either manually create= d or from another Organizational Identity Source), a new membership will no= t be created.
Manually rerunning a Pipeline will not correctly recalculate group membe= rships, as the original source record is not available for processing. Comp= letely resyncing the Org Identity from Source (which will in turn rerun the= Pipeline) will work correctly.
When a record has been synced to Registry from the Organizational Identi= ty Source, a cached copy is stored in the Organizational Identity Source Re= cord so that Registry may detect when the source record has been updat= ed. By default, this is a full copy of the record as returned to Registry f= rom the backend (in whatever format is returned from the source, eg JSON, X= ML, etc). This is also useful for tracing problems, as it is possible for a= n administrator to look at a cached copy of the data.
However, there may be privacy or data retention concerns that make stori= ng a full copy less desirable for a given deployment. As an alternative, Re= gistry can create a hash of the data to be stored instead. This can be enab= led via the Hash Source Records configuration option.
When this configuration is changed, existing records are not af= fected. 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&n= bsp;for privacy or data retention reasons is that older copies of the sourc= e records are maintained by Changelog Behavior. It is insufficient to enable this setting and per= form a full sync to remove all old records from the database, rather manual= intervention is required. The following SQL is for general guidance and sh= ould not be used directly without first testing against a test server:
SQL> = update cm_org_identity_source_records set source_record=3Dmd5(source_record= ) where org_identity_source_id=3D? and (deleted=3Dtrue or org_identity_sour= ce_record_id is not null);
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 i= s enabled.