Group Correlation mechanism

IdentityIQ (IIQ) IIQ Discussion and Questions
, , , ,
1

Hi all,

Isn’t there a logic or mechanism in SailPoint that does the correlation for Group objects(like we have to manually write a logic to correlate accounts) while Account group aggregation?

I haven’t come across for this anywhere. So how does SailPoint know to correlate the data for the group coming in (if to correlate or to create a new entitlement)

Thanks in advance

2

@rishavghoshacc -

You’re absolutely right to raise this question — group/entitlement correlation in SailPoint IdentityIQ (IIQ) is not as explicitly configurable as account correlation, and it often leads to confusion. Let’s break this down clearly.

Quick Summary:

While account correlation requires specific rules (Correlation Rule, Identity Correlation Config, Identity Attribute Matching, etc.), entitlement (group) correlation doesn’t follow the same pattern. But yes, there is a mechanism that determines how SailPoint processes group objects — whether to correlate with existing entitlement definitions or create new ones.

How Entitlement Correlation Works in SailPoint:

In IdentityIQ:

  1. During Aggregation, when group objects are pulled in:
  • IdentityIQ compares them against existing Entitlement definitions in the Entitlement catalog.
  • The key attribute used for correlation is usually the Native Identity (i.e., the group name or ID in the source system).
  • If an entitlement with the same Native Identity already exists in the catalog:
    • It is updated if needed (description, display name, etc.).
  • If it doesn’t exist:
    • A new entitlement entry is created.
  1. This behavior is driven by:
  • The schema configuration of the group object in the application.
  • The group schema must define a unique attribute (like name, cn, sAMAccountName) as the identity attribute.

Important Notes:

  • There is no explicit correlation rule for entitlements like there is for accounts.
  • The “correlation” is based on matching values (usually on the name, ID, or similar field defined in schema).
  • If you’re seeing duplicates being created during entitlement aggregation, it usually means:
    • The identity attribute for the group schema is misconfigured.
    • The case sensitivity or whitespace in names differs.
    • Multi-valued group membership attributes might not be parsed properly.

Best Practices:

  • In IIQ, always ensure that group schema has proper unique attribute and is defined correctly in the application’s schema.

Hope this helps.

3

@officialamitguptaa I still have the question on why we need to correlate accounts explicitly and not Group objects

4

@rishavghoshacc -

Great follow-up — and it’s a subtle but important distinction in how SailPoint handles correlation for accounts vs. groups (entitlements).

Why Do We Need Explicit Account Correlation But Not Group Correlation in SailPoint?

1. Accounts require identity linkage — groups do not.

  • Accounts must be mapped to an Identity object (a person).
    • This linkage is not obvious or guaranteed just from the raw data.
    • Example: You may have 2 John Smiths — which account belongs to which identity?
    • Hence, explicit correlation logic is needed to determine the best match based on attributes like email, employee ID, etc.

That’s why we configure:

  • Correlation Config: Matching rules on account attributes vs identity attributes.
  • Correlation Rules: Custom logic using BeanShell to determine identity ownership.

2. Groups (Entitlements) are treated as metadata — not owned by identities

  • Group objects (like AD groups, DB roles, application privileges) are not directly linked to identities. They are:
    • Considered attributes or properties of accounts
    • Managed in the Entitlement Catalog
    • Used to define access within an account, not between identity and account.

So, SailPoint doesn’t need to “correlate” group objects to an identity — it simply:

  • Aggregates the list of entitlements assigned to accounts
  • Builds an Entitlement Catalog of all known values
  • When provisioning or certifying, matches entitlements to role definitions, policies, etc.

To visualize this:

Account Correlation Flow:

Aggregated Account → Match to Identity → Linked to Identity cube

Entitlement Handling Flow:

Aggregated Account → Extract groups/roles → Populate Entitlement Catalog → Show in Identity's Access

So the entitlements ride along with accounts — no correlation required, just recognition and cataloging.

Hope this clarifies your query.

5

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