Hi Felipe,
My understanding that is not possible to switch off the 'back end ‘default correlation’ in IDN (or IIQ) . It looks it’s a hard coded heritage of old initial model of IIQ reused in IDN since 2017.
Nevertheless the individual identity mapping could be amended under a tenant request in IDN in a back end XML.
Role, certification and other internal object links to the amended identity cude might disappear after that. We found that case sometimes is protected by using aliasname as an additional identity attribute to the user ID, but only for some objects and settings.
Sample of the identity assigned to a Role.
{
"id": "1122334456",
"name": "AAAABBBBCCC",
**"aliasName"**: "52017855",
"email": "[email protected]",
"roleAssignmentSource": "ACCESS_REQUEST"
}
So it is a complex way with an extra job to do a lot of child object link corrections after the identity cube initial mapping change for individual identities with a Sailpoint premium support help, but it does not look like “a mission is impossible”.
- If IdentityNow is unable to correlate an account to an identity using your configuration, it will attempt to use a default correlation configuration by matching the account attribute marked as
name
to the identity’sAccount Name
. You can find theAccount Name
by clicking the Identity in the Identity List and viewing theAccount Name
in the attributes section.- If you don’t have a custom correlation configuration, or if your configuration doesn’t find an Identity for an account, IdentityNow automatically attempts to correlate the accounts to Identities by matching the
Account Name
with the Identity’sAccount ID
.
Second way as we interpret the answer above, is to make a complex custom correlation rule that will prevent a back end default correlation to be fired. That is what I would like to see a working sample.
Perhaps the idea would be to define inside the rule own default correlation for all uncorrelared accounts to link them to the same one special ‘helper’ identity we could create.