Identity is not correlated when is created though Create Identity form

Hi experts,

I would like to understand correlation configuration in Sailpoint IIQ.
I’ve noted that account is marked as correlated when account is created though Authoritative source but not when identity is created using CreateIdentity Form.

In this case, we are using Rapid Setup Joiner to create accounts, despite this, identity is not correlated. Is it correct? It would be neccesary implement a custom rule for that?

Thanks in advance

Hi @ismaelmoreno1

  1. When you create an Identity using the CreateIdentity Form it will just create an identity in SailPoint without any application.
  2. In case of RapidSetup are you configuring the Account Correlation logic ?

Basic flow in SailPointIIQ:

  1. Identities are first created from an Application which is marked as Authoritative Source
  2. When we are onboarding the remaining non-authoritative applications we need to mention the correlation logic so that the accounts get correlated to the identities created from Authoritative source
  3. Correlation in this application can be configured either via Account correlation config or via correlation rule

Hi @rajeshs

Thanks for your quick reply.
In our case, IdentityCreate Form is the authoritative source , and joiner process creates the application accounts, so for this case, It should be necessary to configure correlation rule in the applications to set identity as correlated during aggregation process?

Yes you need to set it as correlated explicitly in the LCM create and update workflow for identities created by the Create Identity Form.

Yes you are right we need to create correlation rule in your case so that the account is attached to the identity created via form

It’s a bit “old-school”, but for this kind of use-case, I’d generally prefer to create a custom table in the IIQ DB (or plugins DB) to store the identity data, and then onboard that DB table as a JDBC application in IIQ. The process would essentially work like this:

Preconditions:

  1. A DB table to store the identity data (can encrypt sensitive data if desired and decrypt in your customization rule if needed)

  2. The Create Identity workflow would be modified to insert a record/row into the custom table

  3. A JDBC app is configured to read from that table and is flagged as authoritative

  4. Identity Mappings are configured to utilize this source (likely a lower priority than the main HR source)

  5. When a new record is entered, you can execute a getObject single-account aggregation to aggregate the new record immediately.

Note: You can also update the Edit Identity workflow to modify records in the DB table as well

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.