[Custom] Account Correlation Rule - Sub-addressing & Multiple Emails

Seeking community feedback and guidance on a relative problem with correlating identities with multiple email addresses and possibly email sub-addressing.

Scenarios:

  • Employee has multiple work aliases \ emails
    • Whether it be for vanity or legitimate reasons
  • Your email services support email sub-addressing

Problem 1 - Lists

In a google workspace (formerly gsuite) shop, the account attributes consist of primaryEmail in addition to editable \ non-editble aliases. The latter is returned in a list format, but account correlation in IDN doesn’t allow for a list contains evaluations, just $IdentityAttribute eq $AccountAttribute.

It may be possible to enumerate each possible item in the aliases list, but that’s less than ideal and limits the assessment \ correlation based on email01, 02, … 10.

Problem 1 Options

  • Create x number of identity attributes and transform the list individual strings for the respective iterations
  • Create an after rule for each connector with some variable logic to find the primary email of the account email and add the new attribute to the correlation config.

Problem 2 - Sub-Addressing

In situations where, for whatever reason, sub-addressing is used for account creations, this possess a risk of no correlating such accounts to their respective owner. From a correlation \ logical perspective,

$attribute = "[email protected]"
$email = concat($attribute.split("+")[0] + $attribute.split("@")[1])
# email = [email protected]

Problem 2 Options

  • Write an afterRule for each connector to assign an arbitrary attribute if sub-addressing is used and transform the value by striping out the sub-addressing. Add the new attribute to the correlation config

Final thoughts

Unless im missing something, these options for both problem statements are less than ideal. While having a solid posture on addressing uncorrelated accounts (i.e. closely monitoring and sanitizing OR manually \ automating the correlation externally), I’m hoping that the community may have better ideas on how best to correlate these scenarios considering there may be legitimate business usecases.

One factor to keep in mind for correlation, attributes have to be searchable. Each tenant has six customizable attributes to assign. I am assuming that for your Problem 1, users have some control over the aliases that are allowed. If so, I am not sure that you could completely come up with a matching identity attribute and stay within the six customizable attributes. Your second option of finding the primary email in an after rule would work.

The other option that you have is to write a correlation rule.

Correlation Rule | SailPoint Developer Community

Correlation rules are cloud rules versus after rules are connector rules. By default, this makes them directly manageable by the customer. However, a cloud rule might be beneficial, if you had multiple sources that couldn’t use the same connector rule but have this issue. In this case, just like your after rule, you would examine the email address provided and modify them to find the primary email. Then you would use the primary email as the correlation attribute.

2 Likes

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