Six Correlation Attribute Limit Workarounds

Identity Security Cloud (ISC) ISC Discussion and Questions
1

Hi all,

We are encountering a major blocker with an implementation and would appreciate any advice:

SailPoint has a hard limit that only 6 custom identity attributes can be promoted to “searchable” and thus present as options in correlation mapping. We have a business/technical use case to correlate downstream sources on more than just 6 different identifiers across the organization. This leaves us with the following workarounds:

  1. Re-purpose one of SailPoint’s many out-of-the-box searchable attributes to be used as a correlating identifier (e.g. Treat “country” as the identity attribute that stores worker ID).
    Pros: OOTB functionality
    Cons:
  • The esoteric naming convention will complicate design and ease of use. All admins will have to recall which attributes don’t align with their names and avoid them in roles, transforms, and provisioning.
  • There are a limited number of OOTB attributes that we can repurpose, as many of them are needed for their intended use (e.g. Work Email, Department, etc.)
  • These attributes are not consistent across all of our environments (e.g., PreferredLanguage is only present in our Dev tenant)
  1. Using the API to mark the OOTB searchable attributes as “non-standard” and “non-searchable” so that we can replace them with our own.
    Pros: Scalable and simple
    Cons: Requires backend workarounds and modifications to OOTB attributes. Our customer would need validation from SailPoint that this will not have unforeseen impacts, and that this customization is not misuse of tenant configuration.

Has anyone else ran into this limit, and if so, were any other workarounds discovered that we are missing? Any help is appreciated, thanks.

2

As an amendment to this post - We have tested option 2 and found that it is not viable. Although we can mark a custom attribute as “standard” and “searchable” these would appear to only be superficial changes. Mapping the attribute in a correlation mapping causes aggregation to miss net-new accounts. It would seem that the system recognizes that this 7th attribute isn’t legitmate.

3

@chris-hogan

Can you use a correlation rule to convert the data you have into one of your six searchable attributes?

Correlation Rule | SailPoint Developer Community

2 Likes
4

Hi Alicia,

Thank you for the suggestion, but unfortunately, we cannot. Each attribute represents a unique correlation id sequence.

5

Let me expand,

In the correlation rule, you should be able to use Identity commands like:

attrSearchGetIdentityName()
findAccountsByAttribute()

(Java Docs | SailPoint Developer Community)

to search for your “correlation” attribute with the value that was collected in the aggregation. It doesn’t have to be a calculation like the example had.

Once you have identified the unique identity/authoritative account, you should be able to lookup one of the six searchable attributes (example, ID, email, etc.). Some Relevant calls might be:

getAccountAttribute()

or from the Identity Interface

getAttributes()

and add the searchable value to your payload.

1 Like
6

I’ve taken another look at the correlation rule example in the documentation:

String calculatedEmail = account.getStringAttribute( "username" ) + "@example.com";

returnMap.put( "identityAttributeName", "email");
returnMap.put( "identityAttributeValue", calculatedEmail );

To me it would seem that despite the name “identityAttributeValue” the “calculatedEmail” is now used as the final account attribute which is then checked against the identity attribute “email”.

For the sake of the discussion, say we have 7 different formats so our identity would be present as follows:

“UserID_1”: “Value1”
“UserID_2”: “Value 2”
etc.

No matter how we manipulate the account attribute, the returnMap would still require an identity attribute and this attribute will have to be one of the searchable attributes to my knowledge, is that correct?. Therefore, when it comes time to check “UserID_7” it would fail to correlate as this attribute is unable to be promoted to searchable.

7

You could try to do this outside of IDN via a PowerShell script that would do all the calculation then make an API call to update the correlation of the account with the correct identity. This script then could be called in an After Provisioning Rule to trigger it for and Identity. Granted this would require a complete micro service outside of ISC to complete. This would all depend on how much time and $$$ that you client would want to spend on something like this. The only other way I know of doing something like is to down load the uncorrelated accounts file and populate the Identity ID to it. And then upload it.

From my experience there is no good solution outside of the 6 searchable attributes.

8

Yes, you would return one on the six searchable attributes. Then your mapping would use the searchable attribute.

9

Putting these potential options in here in case they warrant any further discussion…

1. Use Transform Logic to Normalize Data (Reduce the Need for Extra Attributes)

  • How It Works : Use SailPoint’s transform logic to normalize inconsistent identifiers. For example, if one system uses abbreviated email addresses (e.g., j.smith@acme) and another uses full email addresses (e.g., john.smith@acme.com), transform logic can adjust these to a common format before correlation takes place.
  • Why This Helps : If the root of the issue is inconsistent naming conventions or formats, this could allow the customer to use fewer custom searchable attributes by standardizing the data before attempting correlation. This reduces the need for multiple attributes if most of the mismatches can be solved through data transformation.

2. Use a Custom Identity Mapping Table (External Correlation)

  • How It Works : Create a custom mapping table or database that stores all the unique identifiers from various systems in one place. Instead of relying solely on SailPoint’s built-in attributes for correlation, they could query this external table to find the corresponding identifier across systems.
  • Why This Helps : This allows the customer to expand beyond the 6 searchable attributes without asking SailPoint to change its limits. The table serves as a lookup reference to help match identities when SailPoint can’t do it directly.

3. Leverage an External Correlation Tool or Middleware

  • How It Works : Use a middleware tool or external identity orchestration platform that handles correlation outside of SailPoint. This tool could take in the various identifiers from all downstream systems and perform the correlation before passing the correlated identity back into SailPoint.
  • Why This Helps : It removes the burden of needing more searchable attributes in SailPoint and allows more flexibility in how identities are matched. This is especially useful for complex environments with many systems and identifiers.

4. Prioritize & Optimize Attribute Usage

  • How It Works : Do an audit of which custom attributes are being used for correlation today and assess if some can be reused or consolidated. For example, are there any attributes that are redundant or only used in rare cases? By optimizing which attributes are considered “searchable,” they may find that 6 is enough.
  • Why This Helps : Sometimes, customers use more attributes than they actually need for correlation. By reviewing and optimizing the use of existing attributes, they might find ways to make better use of the available slots without needing to ask for more.

5. Custom Connector Development

  • How It Works : Create a custom connector that pulls multiple identifiers from the downstream systems and handles the correlation on the connector side. The connector would then pass a single correlated identifier (like email or employee ID) back to SailPoint.
  • Why This Helps : It takes the load off SailPoint and allows more control over how correlation is managed. The connector can be custom-built to handle more complex correlation logic, leveraging multiple attributes without overloading SailPoint’s limits.

6. Implement Fallback Correlation Logic

  • How It Works : Implement a system of fallback rules within SailPoint. This would involve trying to match on a primary identifier (like email or employee ID) first, and if that fails, it would attempt to correlate based on secondary or tertiary identifiers.
  • Why This Helps : By creating layers of correlation logic (starting with the most reliable identifier and then falling back to less reliable ones), the customer can maximize the utility of their 6 attributes while still improving match accuracy.

7. Custom API Workflow to Augment Correlation

  • How It Works : Use the SailPoint API to create custom workflows that query additional attributes when the primary identifiers don’t match. The API could look for other matching criteria outside of the standard 6 searchable attributes and use that data for correlation.
  • Why This Helps : This provides additional flexibility without requiring SailPoint to lift the attribute limit. The API could act as an extension of SailPoint’s built-in functionality, allowing more advanced correlation logic.

8. Synchronize More Data via Identity Feeds

  • How It Works : If the downstream systems allow it, synchronize more data between systems via identity feeds. This involves setting up processes that ensure key identifiers (like email or employee ID) are propagated across all systems automatically.
  • Why This Helps : If every system has the same set of identifiers available, they could reduce their reliance on multiple searchable attributes because they’d always have a consistent identifier for matching.

9. Outsource Data Cleaning & Enrichment

  • How It Works : Hire a data management vendor to clean and enrich their identity data. These vendors specialize in making sure data is consistent across all systems, which can help reduce the need for multiple custom attributes in SailPoint.
  • Why This Helps : Clean, standardized data reduces the need for complex correlation logic, and a third-party vendor could help automate much of this work, making it easier to manage long-term.
10

Thanks so much for recommending some “options” here. We already created several custom Cloud Correlation rules for our complex correlation scenarios and that is understandable to a certain extent to not have correlation rules easily configurable in the UI (maybe/maybe not if we can combine AND/OR logic it just might reduce the need for some Cloud Correlation rules). But it is absolutely ridiculous that an Identity System will need to use a middle-ware to do correlation. This is basic functionality to which SailPoint is enforcing a limit for some arbitrary reason and using performance as the reason. We have multiple data sources, the likelihood of having the same IDs to correlate the identities with the same one is unlikely. We just need basic straight-up string comparison but can’t add any more because we hit the 6 maximum limit. Also, it there a way to know which ones SailPoint took as searchable by default vs. the 6 that we set? I see 20 on ours but looks like some OOTB attributes are already set. Do I assume, the attribute is custom AND searchable is true for it to count to the 6 limit? Thanks!

1 Like
11

Hi Rowann,

In my testing related to this issue I have found that any attribute marked “standard: true” will not count towards the limit of six. Any that are “searchable: true” but “standard: false” are counted towards the limit of six. You can check this for your own environment with the List Identity Attributes API

Also, a heads up, though you can technically update the “standard” flag through the API and it may seem like a way to change which attributes the limit applies to, this does not have the intended effect in the back end and will cause issues with aggregation and correlation. I would avoid changing anything other than promoting the custom attributes to searchable.

2 Likes
12

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