Email Correlation Rule

[Alyson_Trad]

Which IIQ version are you inquiring about?

Version 8.2

Share all details related to your problem, including any error messages you may have received.

Within our environment, one identity can have two Active Directory accounts, one common and one privileged. This has caused some identities to show their admin email on their identity which causes issues with hierarchy in other systems we are integrated with. I am looking to develop a correlation rule that pulls the common account email address and applies that to the identity instead of the admin account’s email. I am struggling on how to pull the email attribute from AD without pulling the admin email as well.
Has anyone does something similar?

[kjakubiak (Kamil Jakubiak)]

Hi Alyson,
Just for me to understand -
You have situation when 1 identity can have 2 AD accounts, one admin and one regular. What you want to do is to read mail attribute from regular one and store it as email on the identity cube, is this understanding correct?
If so - then it’s simple as long as you are able to distinguish which account is admin and which not. You can write a simple attribute source mapping rule in which you check if the link is regular (or non admin) and then you can return value you need.

[Alyson_Trad]

You are understanding correctly.
I dont believe my syntax is correct, but below is the correlation rule I created for this.

Code:

Map returnMap = new HashMap();
String email = account.getStringAttribute(“email”);
if ( email != null && email.contains(“admin”)) {
returnMap.replace(/“admin.”/, “”)
}
return returnMap;

[HemantSingh]

you need to write global identity attribute source and check the whether account is admin account or common account…below is sample code and you need to update the logic to find whether its admin account or not there should be some indication on account for the same.

String returnValue = null;
IdentityService idSc = new IdentityService(context);
Application adapplicationobj = context.getObjectByName(Application.class, "name of ad application");

if(null!=identity) {
	if(null!=adapplicationobj){
		returnValue = identity.getAttribute("email");
		List adLinks = idSc.getLinks(identity,adapplicationobj);
		if(null!=adLinks && adLinks.size()>1 ) {
			for(Link adLink : adLinks) {
				String ademail = adLink.getAttribute("mail");	
				//update below code to find where the Link is admin account or not if its not admin account then update the returnValue with email from this Link
				String isadminAttr = adLink.getAttribute("adminAttr");				
				if("false".equalsIgnoreCase(isadminAttr)){
					returnValue = ademail;
					break;
				}
			}
		}
	}
}
return returnValue;

[kjakubiak (Kamil Jakubiak)]

I believe it will be far more efficient to use application rule instead of global rule

then the rule can be very simple

if(!"admin".equals(link.getAttribute("accountType"))){
return link.getAttribute("mail");
}

@HemantSingh - you have to be very carefull with source mapping rules and their performance as it will impact identity refresh significantly. I believe iterating over all links of identity is far from optimal (you can imagine situation when you have similar rule for 50 attributes and the user would have 500 different accounts - this would give you over 2500 unneccessary loop iterations for each identity).

With application rule you already get link object which contains link of the application for which the rule is defined so you limit ammount of executions significantly. Furthermore once you return first value it will not analyze other links anymore.

[HemantSingh]

Thanks! agree with the points, it all on the implementation team to evaluate the current and future implementation as well to decide on which solution to use. particularly in this case , yes Application Rule would be more efficient than Global Rule.
I believe in case of the Application Rule we need to get the current attribute also and return that when link is Admin and return the value from link if it not admin account.
Thanks!

[kjakubiak (Kamil Jakubiak)]

Depends on usecase but yes - the code can be adjusted with

if(!"admin".equals(link.getAttribute("accountType"))){
return link.getAttribute("mail");
}
return oldValue;

This variable is available in the rule out of the box - this however must be already conscious decision as depending on architecture it will have different consequencies.

In the end remember that order of links how IIQ processes them can be random. That means my first code - will work actualy always as long as you have non admin link present.

Second code (from this post) may lead to unpredictable behaviour because if the email attribute is already set and first link in the loop would be admin link - then it will return oldValue and nothing more will be processed. That means the real non admin link won’t be analyzed in this case.

Just to summarize - everything depends on the overall architecture of the solution - technically both rules will work but with potentialy different behaviour.

[Alyson_Trad]

If there is no way to decipher the accounts, how would I pull the correct email.
Example, we don’t have an ‘AccountType’ attribute. The difference in them is how they are named, they all start with ‘admin’ for cn=. They are also all within a certain OU.
I’m thinking targeting that in some way would be my best option.

[kjakubiak (Kamil Jakubiak)]

String dn = link.getAttribute("distinguishedName");
/// Or if you use it as native identity
/// String dn = link.getNativeIdentity();

if(dn!= null && dn.startsWith("cn=admin")) {
return link.getAttribute("mail");
}