Bypass default correlation

IdentityIQ (IIQ) IIQ Discussion and Questions
1

Is there a supported way to completely bypass default correlation for specific accounts (e.g., ServiceAccount identities)?

In our use case, if the identity type or attribute indicates a ServiceAccount, we want the account to be created but remain uncorrelated. However, even when the correlation rule returns null, IdentityIQ still performs default correlation and links the account to an identity.

2

Hi @malarvanan12,

you can use a correlationRule instead of a correlationConfig. In the rule you can check the type and dont correlate service accounts

3

i am using correlation rule only, it is going back to fallback correlator even if i make the service account correlation don’t need to happen

THis is the rule :

import sailpoint.object.;
import sailpoint.api.SailPointContext;
import sailpoint.tools.GeneralException;
import java.util.;

String login = account.getAttribute(“UserName”);
Object serverObj = account.getAttribute(“ServerName”);
String sourceOwner = account.getAttribute(“SourceOwner”);

List serverNames = new ArrayList();
if (serverObj instanceof List) {
serverNames.addAll((List) serverObj);
} else if (serverObj != null) {
serverNames.add(serverObj.toString());
}

log.error("Original userName: " + login);
log.error("ServerNames: " + serverNames + ", SourceOwner: " + sourceOwner);

// =======================================
// Step 1: Check if identity is ServiceAccount (before cleaning)
// =======================================
if (login != null) {
Identity checkIdentity = (Identity) context.getObjectByName(Identity.class, login);
if (checkIdentity != null && !checkIdentity.isInactive()) {
String userType = (String) checkIdentity.getAttribute(“type”);
log.error("Initial identity lookup: userType = " + userType + ", Identity = " + checkIdentity.getName());

    if (userType != null && userType.equalsIgnoreCase("service")) {
        log.error("Skipping correlation for ServiceAccount identity (pre-clean): " + login);
        // Return an empty map to prevent any default correlation
        return Collections.emptyMap();
    }
}

}

// =======================================
// Step 3: Fallback correlation (clean login)
// =======================================
if (identity == null) {
    if (login.contains("\\")) {
        login = login.substring(login.indexOf("\\") + 1);
    }
    if (login.contains("@")) {
        login = login.substring(0, login.indexOf("@"));
    }
    if (login.toLowerCase().endsWith("-admin")) {
        login = login.substring(0, login.length() - 6);
    }

    log.error("Cleaned login: " + login);
    identity = (Identity) context.getObjectByName(Identity.class, login);

    // =======================================
    // Step 3a: Check again for ServiceAccount (after cleaning)
    // =======================================
    if (identity != null && !identity.isInactive()) {
        String userType = (String) identity.getAttribute("type");
        log.error("Post-clean identity lookup: userType = " + userType + ", Identity = " + identity.getName());

        if (userType != null && userType.equalsIgnoreCase("service")) {
            log.error("Skipping correlation for ServiceAccount identity (post-clean): " + login);
            // Return empty map to stop any further correlation
            return Collections.emptyMap();
        }
    }
}

}

// =======================================
// Step 4: Return final correlation
// =======================================
if (identity != null && identity.isCorrelated()) {
log.error("Successfully correlated to identity: " + identity.getName());
return Collections.singletonMap(“identity”, identity);
}

log.error(“No identity correlated. Exiting with null.”);
return Collections.emptyMap();
4

Hi @malarvanan12 ,

did you already check this thread on Compass:

It’s really helpful.
As per my current understanding of your issue the last sentence may contain the explanation:

Yes, the 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.

Let us know if that helped.

Best regards,
Daniel

5

When account correlation runs, it is always going to want to correlate the account (link) to an identity, always. You cannot have orphaned link object sitting around, they can cause significant issues in your system. I’ve seen populations return zero results due to orphaned link objects. I’ve actually written a task that scans daily for orphaned links and deletes them.

The correlation rule you wrote will either correlate to an “correlated” identity, or will create a net-new “uncorrelated” identity, with the name being the native identity of the uncorrelated account, and then correlate the service account to that uncorrelated identity. So although your service accounts are associated to an identity, I have to believe that they are associated to an “uncorrelated” identity. One suggestion, although your desire is to have the accounts uncorrelated, is to create a single service account identity and attach them to it. Be careful, however, as if you have a large number of accounts linked to the uncorrelated identity, and you are running a partitioned aggregation, you may run into locking issues.

6

I would be suprised if Sailpoint support this. Because, for authoritative source aggregation, the identity is created and then an account is correlated. Without this, in future aggregations how would the updates flow.

May be you need to think about different approach like create the service account identities manually in UI or thru API. In this way, it will just be an identity without accounts correlations

7

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