Hi Chris,
There are at least few reasons why correlation might not work as you expect - first of all would be great if you can add into this thread your correlation configs.
Second - you need to verify if attribute on identity you use for correlation is unique because in IIQ when correlation logic returns more than one identity the outcome is that nothing happens. Correlation config needs to always return unique object to correlate the account.
@chriskk - Please follow the below approach to onboard any DB Application to SailPoint IIQ.
I’ll first divide the whole integration into two parts - Aggregation and Provisioning. Let’s start with Aggregation -
Let say before application onboarding the Application has got 100+ users. In order to manage these existing accounts, we need to bring the account footprint to SailPoint. For this we generally run the Account Aggregation Job. When you run the account aggregation job, the below configuration comes into the picture -
This will iterate all the records from the database. During the iteration it look out for the Correlation stuff, in layman terms this DB account belongs to which SailPoint user. To do this it makes use of Account correlation i.e. through which attribute of Database you can identify a user in SailPoint. In my case, I was checking if my dbID of database matches with name attribute of SailPoint, then account linking will happen.
This is how entire Aggregation works.
Moving to the provisioning part -
As usual we have the Provisioning rule to handle the account creation/modification/deletion in the Database. One Important parameter to look is GetObjectSQL under the configuration
This parameter is used when you performed the provisioning and then running the perform Identity Request Maintenance task it will trigger this query to check if the provisioning was successful or not. If this is not configured, you will see Access Requests Stucks in verifying state.
Hope this clarified your doubts. Mark it as solved, If it helps.
As we can see, the IIQ attribute “DB_KENNUNG” is defined for the correlation. But the problem occurs when this IIQ attribute is empty. Then IIQ ignores the correlation configuration and uses a completely different IIQ attribute ‘name’.
Why does IIQ ignore the correlation configuration and fallback on another IIQ attribute “name” (not specified in this correlation)?
@chriskk - Thanks for sharing the details.
Please find my response below -
the Correlation rule supersedes the correlation config and correlation config supersedes the default correlation. The general behavior of IIQ is to find returned map first from rule; if it does not return anything it falls back on Correlation configuration. If correlation configuration too does not return anything, it falls back on default correlation. If default correlation fails, it creates an orphan account.
Refer the file attached for better clarification.
Mark it as solved, if it helps you. Correlation Rule or Configuration Rule or Default Configuration.pdf (596.3 KB)
This behavior is not documented and there is an explizit configuration given, why is this a normal/hidden/implizit behavior? (Based on delivered PDFs.)
Depending on your own example:
Your correlation config is using explizit IIQ attribute “id”.
Clear your own/additional defined IIQ attribute “id”, and be sure the IIQ attribute “name” is filled with same value.
Is your expectation, that IIQ is using a different IIQ attribute “name” wich is explizit not definied in your correlation config?
If this behavior is truly “normal,” how can we disable it?
Where can i found a official documentation for this hidden fallback implementation?
In general, we should do the aggregation based on some unique not null attribute on Sailpoint side rather than doing it using some attribute whose data is null.
We never faced such kind of behavior when we are doing the correlation based on some unique not null attributes. If the criteria don’t match then it will create an uncorrelated account, else if you want that this should not happen then we mark the below option to restrict SailPoint to create uncorrelated account.
This behaviour is actualy quite logical in the end. When IIQ cannot correlate an Identity - what it does by default is to create orphan identity to handle link object which cannot be correlated. As in that stage IIQ has very limited amount of data it needs to create somehow the name of the identity - by default it is the Native Identifier of the link which resulted in orphan identity creation.
This is what happens by default - trick starts when in the system you have already identity with the same name - it’s not possible to create second identity because name needs to be unique due to data model. So in this case the only thing that IIQ can do is to correlate this link to the existing identity that matches native identifier.
Regarding - how to disable it - I agree with @officialamitguptaa with one ‘but’ - you need to be aware that if you use this checkbox - it will just skip all accounts from your application which cannot be correlated.
What I suggest here as a slightly different solution is to overide the default behaviour of setting identity name to native identifier. This is a simple creation rule which you have to configure in your application to use eg. random identity name when account cannot be correlated - this will at least solve problem of correlation and still allow you to see all accounts in the system.
Thanks for your answers, but the task is already defined to use only existing identities (IIQ must not create unknown identities).
My question is: Why is IIQ using another attribute, which is not defined in correlation config. And if this is an expected beheavior, where is it documented.
Would your suggestion of a custom correlation rule, solve the issue of using undefined attributes? (Not the behavior of creating unknown identities, i looking fo the behavior of unconfiged correlation attributes in case of existing identities with empty correlation attribute.)
)