Date: Fri, 29 Mar 2024 06:02:49 +0000 (UTC)
Message-ID: <992273773.7521.1711692169138@ip-10-10-7-29.ec2.internal>
Subject: Exported From Confluence
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="----=_Part_7520_1907633433.1711692169136"
------=_Part_7520_1907633433.1711692169136
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Location: file:///C:/exported.html
Background
Organizational Identities are intended to record representa=
tions of identities created outside Registry, such as those from Identity P=
roviders or Systems of Records. However, in the early days of COmanage, pul=
ling these identities from outside sources was challenging, and so early on=
the ability to manually create Organizational Identities via Enrollment Fl=
ows (or directly via the UI) was added. In retrospect, this was probably a =
mistake.
In Registry v2.0.0, Organizational Identity Sources were in=
troduced as a first step towards fixing this problem. Organizational Identi=
ty Sources are basically interfaces to external data sources, and create re=
ad-only Organizational Identity records that can only be updated when the a=
uthoritative 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 r=
eleased at all. Identity providers might not even participate in the federa=
tion. As such, there will still be a need manually enter or override Organi=
zational Identity information.
Proposal=
Shadow Organizational Identities
Organizational Identities will become read only entities th=
at can only be created from an Organizational Source. To allow for correcti=
ons and manual entry, the concept of Shadow Organizational Identit=
ies (CO-1635) will be introduced. Shadow Organizational I=
dentities will be implemented using the existing OrgIdentity model, and can=
be used in one of two ways:
- Linked: A Shadow OrgIdentity can be =
linked to an OrgIdentity that was created from an Organizational Identity S=
ource. In this case, the Shadow OrgIdentity's attributes will override the =
OrgIdentity's attributes in context like Pipelines, allowing corrections an=
d changes to authoritative attributes.
- Independent: A Shadow OrgIdentity ca=
n be created independently of an existing OrgIdentity. In this case, they c=
an 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 t=
o an identity provider. (An OIS like EnvSource should be used to create a p=
roper OrgIdentity if an authoritative source is available.)
Shadow OrgIdentities can only be created by being attached to an existin=
g CO Person. It will not be possible to create a standalone Shadow OrgIdent=
ity.
Transition
In Registry v6.0.0, it will no longer be possible to manually create or =
edit "normal" Organizational Identities. Identities created directly in Reg=
istry will consist only of CO Person attributes.
- The user interface for manually creating Organizational Id=
entities will move from being a top level Registry Object (ie: a link in th=
e main menu) to being an additional attribute on a CO Person record (simila=
r to CO Person Roles).
- The OrgIdentity REST API will not permit a record to be cr=
eated without a CO Person ID.
- Enrollment Flows will no longer be configurable to collect=
Organizational Identity attributes as part of the Petitioner Attributes st=
ep.
- This implies that features like "Copy Org Identity Attributes to CO Per=
son Record" will go away.
- A new step will allow for the creation of Shadow Organizational Identit=
ies after the CO Person is created, similar to how Identity Documents can b=
e attached via the NationalityEnroller (but maybe not via a plugin). This w=
ill allow for prompts like "please indicate your institutional affiliation"=
. Fields for this step will be configurable, and fields like name might def=
ault to the CO Person values.
- See also Org Identity Enrollment Refactoring Design Discu=
ssion.
- Existing OrgIdentities that are not linked to an Organizat=
ional Identity Source will automatically become Shadow Organizational Ident=
ities.
- If there is a Login Identifier attached, the OrgIdentity w=
ill become a Shadow OrgIdentity attached to an OrgIdentity that in turn is =
attached to an EnvSource OIS.
- It will be possible to create records directly in Registry consisting o=
f CO Person attributes only (CO-87=
0).
- In order for these identities to be able to login to Regi=
stry, either an external Organizational Identity must be attached, or an Au=
thenticator must be used.
- For Authenticators, Identifiers attached to a CO Person c=
an be flagged as login. Then, the SP protecting Registry can be co=
nfigured to authenticate against an IdP the uses the appropriate Authentica=
tor repository for authentication.
(Note it would be possible to sync CO Person records from o=
ne COmanage CO to become Organizational Identities in another COmanage CO, =
but this is something of a special case.)
Transmogrification
When importing records from earlier versions of Registry, R=
egistry PE will:
- Remove Organizational Identity attributes from Enrollment=
Flows. These attributes may be converted to Shadow OrgIdenti=
ty attributes if a straightforward conversion process can be developed. Oth=
erwise, Administrators will need to manually reconfigure their Enrollm=
ent Flows.
- Existing OrgIdentities will be transitioned as described =
above. Note this transition may happen in Registry v5.0.0, as part of the&n=
bsp;Org Identity Enrollment Refactoring Design Discussion.
- Provisioners will no longer look at Org Identity data, ev=
en as exceptions. Old configurations will (probably) not be migrated.
Benefits=
- There is a significant amount of complex logic for handling Organizatio=
nal Identities, particularly in Enrollment Flows. This reorganization will =
simplify that logic.
- The distinction between Organizational Identities and CO Person records=
will become clearer.
- Removing this option will simplify deployment for new adopters.
Drawbac=
ks
- This will require some form of migration for almost every existing depl=
oyment, especially older ones.
Conclu=
sion
TBD.
- CO-421 Add New Org ID Should Become Enroll
- CO-635 Default Enrollment Without Email Confirmati=
on
- CO-753 Refactor CoInvites
- CO-757 Verify Petition Email Addresses
- CO-870 CO Person Without Org Identity
- CO-1545 Remove CMP Enrollment Attributes and Old =
Style REMOTE_USER Enrollment
CO-1624 EnvSource with Self Signup Cannot Veri=
fy Email
- CO-1635 Shadow Organizational Identities
- CO-1636 EnvSource based account link does not work w=
hen the new login method is from the same source
- CO-1671 Re-enrolling does not allow creating=
a new OrgIdentitySource record
- CO-1997 Identity linking flow using EnvSource cre=
ates additional CoPerson record
- Various tickets become invalid:
- CO-460 Authenticated Identifier Type Forced to ePPN
- CO-862 Copy To CO Person Should Support Types
- CO-1380 Pip=
elines Attached To Enrollment Flows
- CO-1381 Exe=
cute Pipeline For Default Enrollment
- CO-1578 Enrollment Source Invitation Single Org Iden=
tity
- CO-1647 Petition verifies OrgIdentity email, even=
if already confirmed
- CO-1761 For Self-Signup, OrgIdentity attributes are =
not copied to COPerson
------=_Part_7520_1907633433.1711692169136--