Application correlation issue

[Gutte_Shubham (Shubham Gutte)]

Hi All,
I’m currently working on onboarding a JDBC application in SailPoint IdentityIQ. During the aggregation process, I’ve noticed that the accounts are not correlating with the actual identities as expected. Instead of linking to the correct identities, orphan accounts are being created. Could you please advise on how to troubleshoot or configure the correlation logic so that accounts properly match with existing identities?

Below is the simple code which i have.
import Sailpoint.object.Identity;
import java.util.HashMap;
import java.util.Map;

Map map= new HashMap();

String email = account.getAttribute(“email”);

if(email !=null&& !email.isEmpty()){
map.put(“identityAttributeName”, “email”);
map.put(“idenityAttributeValue”, email);
}

return map;

[punna0001 (harish Punna)]

Hello Shubham, spotted a typo, you have got "idenityAttributeValue" but it should be "identityAttributeValue" (missing the ‘t’). IIQ expects those exact key names to match the account to an identity, so the misspelling causes the correlation to fail silently and you end up with orphan accounts.

Fix that, redeploy the rule, and run aggregation again. Should work after that.

Just make sure the email values match exactly in your identity attributes (case-sensitive, no extra spaces) and that email is a searchable identity attribute.

Plz let me know if it correlates properly after the fix

[Puja_IAM (Puja Kumari)]

@Gutte_Shubham Yes @punna0001 is correct.

Looks like your code is fine , its just a misspelling of “identityAttributeValue”

import Sailpoint.object.Identity;
import java.util.HashMap;
import java.util.Map;

Map map= new HashMap();

String email = account.getAttribute(“email”);

if(email !=null&& !email.isEmpty()){
map.put(“identityAttributeName”, “email”);
map.put(“identityAttributeValue”, email);
}

return map;

[neel193 (Neelmadhav Panda)]

@Gutte_Shubham In case you already ran the aggregation and accounts are in IIQ as orphan, you need to rerun the aggregation ask with option checked: “Disable optimization of unchanged accounts” . This’ll force IIQ to re-aggregate accounts and apply your rules even if there is no change in account data.

[kallajayaram (Jaya Ram Kalla)]

Hi @Gutte_Shubham

the issue is with the correlation rule. The map key should be identityAttributeValue, but it’s currently defined as identityAttributevalue (lowercase v). Since IdentityIQ expects the exact key name, it won’t perform the correlation correctly, which results in orphan accounts. After updating the key, redeploy the rule and rerun account aggregation and make sure the attribute used for correlation (email) matches the Identity attribute exactly, including case and any extra spaces. That should resolve the correlation issue.

[Gutte_Shubham (Shubham Gutte)]

Hi All,
Thank you for your earlier guidance. The issue with the identityAttributeValue (missing the ‘t’) has been resolved, and accounts are now correlating correctly.

Now I’m facing a new challenge with the Azure AD application. I’ve implemented the same approach and the aggregation runs successfully, but the accounts are not being read or correlated. Could this be related to the rule itself, or might it be due to another configuration issue?.

import Sailpoint.object.Identity;
import java.util.HashMap;
import java.util.Map;

Map returnMap = new HashMap();

// Get UPN from Azure AD account
String upn = account.getStringAttribute(“userPrincipalName”);

if (upn != null&&!upn.isEmpty()) {
returnMap.put(“identityAttributeName”, “userName”);
returnMap.put(“identityAttributeValue”, upn);

}
return returnMap;

Note: UPN value/attribute directly not created in the iiq.

Thank you

[punna0001 (harish Punna)]

Hello Shubham, glad the first issue got sorted!

On the Azure AD side, can you clarify what you mean by “accounts are not being read or correlated”? Those are two separate things:

• Not being read means the aggregation itself isn’t pulling accounts from Azure AD. That’s a connector or source configuration issue, not a rule issue.
• Not correlating means accounts are coming through but not matching to identities. That’s a rule or data mismatch issue.

If you check the aggregation task result, does it show accounts being aggregated (even as uncorrelated)? That will tell us which side the problem is on.

From the rule itself, the syntax looks correct. But your note that “UPN value/attribute directly not created in the iiq” means If userName doesn’t have UPN values populated on the identity side, the correlation will fail silently because there’s nothing to match against. You would either need to populate that attribute or switch to one that already exists with matching values on both sides (like email).

Let us know what the aggregation task result shows and we can narrow it down from there

[Gutte_Shubham (Shubham Gutte)]

Hi @punna0001 ,

I was able to successfully read accounts from Azure AD, and they correlated correctly even without a custom correlation rule. This happened because I selected the option “Only create links if they can be correlated to an existing identity” during aggregation, which allowed IIQ’s default correlation logic to match accounts to identities.

However, when I run aggregation with my custom correlation rule, I encounter the following error:
Exception during aggregation… Reason: Unable to correlate using filter [userName == “rahul.patil@xxxx.onmicrosoft.com”]: could not resolve property: userName of: sailpoint.object.Identity.

I realized that userPrincipalName (UPN) is not directly an Identity attribute in IIQ. Instead, I need to map it to an existing attribute in the Identity. below is the code which i have updated.

import Sailpoint.object.Identity;
import java.util.HashMap;
import java.util.Map;
Map returnMap = new HashMap();

// Get UPN from Azure AD account
String upn = account.getStringAttribute(“userPrincipalName”);

if (upn != null) {
upn = upn.toLowerCase();
} else {
// If UPN is not present, construct it from Identity attributes
String firstName = identity.getAttribute(“firstname”);
String lastName = identity.getAttribute(“lastname”);
String domain = “domain.com”; // declare your domain here

if (firstName != null && lastName != null) {
    upn = firstName.toLowerCase() + "." + lastName.toLowerCase() + "@" + domain;
}

}

// Map the constructed UPN to the Identity attribute
returnMap.put(“identityAttributeName”, “userName”); // or a custom attribute like “upn”
returnMap.put(“identityAttributeValue”, upn);

return returnMap;

[punna0001 (harish Punna)]

Yes, the error says it all: could not resolve property: userName of: sailpoint.object.Identity. That means userName is not a valid searchable identity attribute in your IIQ, so the correlation filter breaks.

Two things I would fix in your updated code:

1. Change the identity attribute. You’re still using userName in identityAttributeName. Switch it to an attribute that actually exists and is searchable on your identities. If UPN matches identity email, just use email.
2. Remove the identity.getAttribute() fallback. The identity object is not available as an input in a correlation rule. The rule’s job is to find the identity, so you don’t have access to it yet. The available inputs are environment, application, account, and link. That fallback block will throw an error.

I would keep it simple:

Map returnMap = new HashMap();
String upn = account.getStringAttribute("userPrincipalName");
if (upn != null && !upn.isEmpty()) {
    returnMap.put("identityAttributeName", "email");
    returnMap.put("identityAttributeValue", upn.toLowerCase());
}
return returnMap;

This should work as long as the UPN and identity email values match. Since your default correlation already worked, you know the data lines up. Just make sure you’re pointing to the right identity attribute and you should be good.

[neel193 (Neelmadhav Panda)]

@Gutte_Shubham Please replace userName with “name” attribute. “User Name” is the display name, while column is “name”.

returnMap.put(“identityAttributeName”, “name”);

This’ll only work if your “name” contains email.. otherwise change it to “email”.

[IAMKhalid (Khalid Hussain)]

@Gutte_Shubham , Try this correlation rule. Also, you can add logs temporarily during testing to confirm what value is coming from the account.

import java.util.HashMap;
import java.util.Map;

Map map = new HashMap();

String email = account.getStringAttribute("email");

log.error("Correlation rule started for account: " + account.getIdentity());
log.error("Account email value: " + email);

if (email != null && email.trim().length() > 0) {
    email = email.trim().toLowerCase();

    log.error("Normalized email value used for correlation: " + email);

    map.put("identityAttributeName", "email");
    map.put("identityAttributeValue", email);
}

log.error("Correlation return map: " + map);

return map;

Make sure the Identity Cube also has the same email value and that there are no duplicate identities with the same email.

[Gutte_Shubham (Shubham Gutte)]

Hi All,

I understand that if I configure the correlation rule to use the email attribute, it will work correctly, and the default correlation also succeeds in linking identities.

My concern, however, is that the Azure AD userPrincipalName (UPN) is completely different from the user’s actual corporate email address. For example, the UPN look like rahul.patil@xxxx.onmicrosoft.com, while the user’s real email is rahul.patil@company.com. This difference makes me unsure whether using email as the correlation attribute is the right approach, since the values don’t truly match.

These both attributes looks different in how that was correlated to the identity?

[punna0001 (harish Punna)]

Hello Shubham, you are right that UPN (rahul.patil@xxxx.onmicrosoft.com) and corporate email (rahul.patil@company.com) are different values. So if your rule pulls userPrincipalName and tries to match it against identity email, that will not correlate because the values simply don’t match.

Since you mentioned that default correlation and using the email attribute both work correctly, can you share what exactly the problem is you are trying to solve? Are you specifically looking to correlate using UPN instead of email, or is there a different requirement here?

[Gutte_Shubham (Shubham Gutte)]

Hi @punna0001 ,

i want to correlated the accounts with the identity. that was happen through the default correlation rule when i was selected the this option (Only create links if they can be correlated to an existing identity.) i don’t know how that was correlated with the identities. If that tried with email in the Azure with iiq email but i can see the email attribute in the Azure is blank. Can someone explain how that was happen? . as per the rule that will try to correlate UPN with email that is false condition. and if need to correlated the UPN with the email what logic i need to implement.

Thanks

[punna0001 (harish Punna)]

Hello Shubham, I think you have two separate points here.

1) How did default correlation work when email is blank?

If the Azure Email field is blank, then the successful correlation was most likely not based on that field. IIQ correlation uses the attributes available on the aggregated account/link object and the configured correlation logic. So I would check the linked Azure account in IIQ and confirm which account attribute actually matched the identity.

It could be userPrincipalName, displayName, mail, proxyAddresses, otherMails, or another schema attribute depending on your application configuration.

2) On correlating UPN to email when domains are different:

The identityAttributeName/identityAttributeValue map does an exact match. So comparing rahul.patil@xxxx.onmicrosoft.com to rahul.patil@company.com will always fail because the full strings are different. Since your Azure AD Email attribute is blank (from your screenshot), using mail for correlation won’t work in your case either.

You could technically transform the UPN domain before matching, but I wouldn’t recommend that approach. It’s fragile and this only works if the username portion (before @) is guaranteed to be the same in both UPN and corporate email for all your accounts. Make sure that holds across the board before relying on it.

Instead, I would suggest finding an attribute value that already matches on both sides and use that for correlation. Or if your default correlation already works, you could replicate that same logic in a correlation configuration on the Correlation tab without needing a custom rule at all.

[neel193 (Neelmadhav Panda)]

@Gutte_Shubham please share your app XML to understand how did you configure your application attributes?

[Gutte_Shubham (Shubham Gutte)]

Hi @neel193 ,

Please find the Application XML file.
AAD_XML.txt (59.1 KB)

[punna0001 (harish Punna)]

In application XML file, I can see a custom CorrelationRule (AAD_Correlation_Rule) attached to the application, with no AccountCorrelationConfig defined.

Two quick things:

1. Was AAD_Correlation_Rule already attached when you ran the successful aggregation with “Only create links if they can be correlated to an existing identity”? Or did you add it after?
2. Could you share the contents of AAD_Correlation_Rule?

[Gutte_Shubham (Shubham Gutte)]

Hi @punna0001 ,

1. Aggregation was with the option Only create links if they can be correlated to an existing identity” the identity’s are already correlated as per my undrstanding later on the rule was added.

2.Bleow is the rule.
import Sailpoint.object.Identity;
import java.util.HashMap;
import java.util.Map;

Map returnMap = new HashMap();

// Get UPN from Azure AD account
String upn = account.getStringAttribute(“userPrincipalName”);

if (upn != null&&!upn.isEmpty()) {
returnMap.put(“identityAttributeName”, “email”);
returnMap.put(“identityAttributeValue”, upn);

}

return returnMap;

[punna0001 (harish Punna)]

To find out what actually matched, check the Link object for one of the correlated Azure AD accounts in IIQ and compare the account attribute values against the identity it’s linked to. That should tell you which attribute values lined up.

As for the rule itself, it maps userPrincipalName to identity email using an exact match. So rahul.patil@xxxx.onmicrosoft.com compared to rahul.patil@company.com will never match because the values are different. We covered this earlier.

I would suggest checking the Link object first, finding which attribute actually matched during the successful correlation, and then using that same attribute in your rule. That gives you a reliable correlation path instead of trying to force UPN to match email.