...

In Registry v2.0.0, Organizational Identity Sources were introduced as a first step towards fixing this problem. Organizational Identity Sources are basically interfaces to external data sources, and create read-only Organizational Identity records that can only be updated when the authoritative upstream record is updated.

However, the gathering of external identity, especially in a federated context, is unreliable. Attributes might be released, but might not be accurate or corrected in a timely manner. Attributes might not be released at all. Identity providers might not even participate in the federation. As such, there will still be a need manually enter or override Organizational Identity information.

Proposal

Shadow Organizational Identities

Organizational Identities will become read only entities that can only be created from an Organizational Source. To allow for corrections and manual entry, the concept of Shadow Organizational Identities (CO-1635) will be introduced. Shadow Organizational Identities will be implemented using the existing OrgIdentity model, and can be used in one of two ways:

1. Linked: A Shadow OrgIdentity can be linked to an OrgIdentity that was created from an Organizational Identity Source. In this case, the Shadow OrgIdentity's attributes will override the OrgIdentity's attributes in context like Pipelines, allowing corrections and changes to authoritative attributes.
2. Independent: A Shadow OrgIdentity can be created independently of an existing OrgIdentity. In this case, they can be used to represent an external affiliation without a proper link to an authoritative source. It will not be possible to attach login identifiers to Independent Shadow OrgIdentities, since these identities are not bound to an identity provider. (An OIS like EnvSource should be used to create a proper OrgIdentity if an authoritative source is available.)

Shadow OrgIdentities can only be created by being attached to an existing CO Person. It will not be possible to create a standalone Shadow OrgIdentity.

Transition

In Registry v6.0.0, it will no longer be possible to manually create or edit "normal" Organizational Identities. Identities created directly in Registry will consist only

...

of CO Person attributes.

...

1. The user interface

...

1. for

...

1. manually creating Organizational Identities will move from being a top level Registry Object (ie: a link in the main menu) to being an additional attribute on a CO Person record (similar to CO Person Roles).
2. The OrgIdentity REST API will not permit a record to be created without a CO Person ID.
3. Enrollment Flows will no longer be configurable to collect Organizational Identity attributes as part of the Petitioner Attributes step.
   1. This implies that features like "Copy Org Identity Attributes to CO Person Record" will go away.

...

1. 1. A new step will allow for the creation of Shadow Organizational Identities after the CO Person is created, similar to how Identity Documents can be attached via the NationalityEnroller (but maybe not via a plugin). This will allow for prompts like "please indicate your institutional affiliation". Fields for this step will be configurable, and fields like name might default to the CO Person values.
   2. See also Org Identity Enrollment Refactoring Design Discussion.

...

1. Existing OrgIdentities that are not linked to an Organizational Identity Source will automatically become Shadow Organizational Identities.
   1. If there is a Login Identifier attached, the OrgIdentity will become a Shadow OrgIdentity attached to an OrgIdentity that in turn is attached to an EnvSource OIS.
2. It will be possible to create records directly in Registry consisting of CO Person attributes only (CO-870).
   1. In order for these identities to be able to login to Registry, either an external Organizational Identity must be attached, or an Authenticator must be used.
   2. For Authenticators, Identifiers attached to a CO Person can be flagged as login. Then, the SP protecting Registry can be configured to authenticate against an IdP the uses the appropriate Authenticator repository for authentication.

(Note it would be possible to sync CO Person records from one COmanage CO to become Organizational Identities in another COmanage CO, but this is something of a special case.)

...

1. Remove Organizational Identity attributes from Enrollment Flows. These attributes will not be recreated as CO Person attributes. Administrators attributes may be converted to Shadow OrgIdentity attributes if a straightforward conversion process can be developed. Otherwise, Administrators will need to manually reconfigure their Enrollment Flows.
2. Copy and Organizational Identities attached to an Organizational Identity Source.
This implies that as part of
3. Existing OrgIdentities will be transitioned as described above. Note this transition may happen in Registry v5.0.0,
there should be some mandatory transition to EnvSource of existing Org Identities, linking legacy identities to an EnvSource OIS, and maybe disabling old style $REMOTE_USER collection from Enrollment Flows (CO-1545)
4. as part of the Org Identity Enrollment Refactoring Design Discussion.
5. Provisioners will no longer look at Org Identity data, even as exceptions. Old configurations will (probably) not be migrated.

...