Which IIQ version are you inquiring about?
8.4p2
Share all details about your problem, including any error messages you may have received.
We have configured a sybase system with a OOTB connector. The native identifier of this attribute is native_identity. PFB the screenshot for the same.
We have 2 accounts in the target data base named - syb_pr_mdm and SYB_PR_MDM.
While aggregation runs only one account is aggregated into SailPoint, this is to maintain the case insensitive uniqueness in names of native identifiers.
When we set the identity Attribute field to server_user_id which is unique field the provisioning process breaks.
So we opened a ticket with SailPoint and following is the response : -
**- Starting at the highest level, the information previously shared is true that IdentityIQ’s database is case insensitive; therefore, the best practice for native identifiers is for them to be truly unique and not just case sensitive. I state it in terms of the native identifier because that’s what corresponds to a primary key in the database, which for the spt_identity table must be unique. Achieving that as not unique would be a customization we wouldn’t support.
- On the other hand, other tables like the ones that hold account links or entitlements, for example, might just use the id as the native identifier. So, in that way, you could have case sensitive display names on account links that apply to either the same identity cube or different cubes though you may need to take a few extra steps to achieve this kind of use case. Now, I won’t have an exact walk through example of how to achieve this because there is not a single, correct answer to this question. Instead, there are many ways to configure or customize the product, so I’ll try to provide some additional resources to help.**
- For example, to start, an authoritative source application is going to try to create one cube per account. I see your example Sybase database application is not listed as authoritative, but it is given permission to create accounts from the account link info, so it’s capable of creating cubes. However, you appear to be normalizing case on the display_name, so I’m not sure how it would ever create separate accounts when the only difference is case.
- Starting at line 120 in your application definition:
**
return identity.getAttribute(“userId”).toLowerCase();**
- If you undo that and don’t specifically normalize the case in the application, then the application does have the potential to create case sensitive accounts if it can find different identity cubes to place them on. If the only difference is case, then aggregation most likely will not be able to achieve this alone. To follow-up with that thought, here’s one resource about aggregation and the different options of bringing in authoritative vs non-authoritative sources.
- On the other hand, you could use options such as correlation to help create difference in the process and tell IIQ what to do with accounts that might appear the same from the aggregation perspective. Here’s a link to our online documentation about correlation and how that process differs: https://documentation.sailpoint.com/identityiq/help/appmgmt/correlation.html?tocpath=Application%20Management%7C_____2
So, to sum up, you may be able to achieve your use case by configuring differently to include correlation logic and avoid normalizing case when creating accounts. If you allow some (or all) applications to create in this way, you’ll want to keep this in mind when onboarding future applications that might behave differently if you don’t carry the same configuration through to all. Also, keep in mind that account correlation can be a more resource-intensive process during refresh or account creation compared to simple attribute matching in large datasets.
I hope this information at least helps confirm on possibilities. If you were needing more direct hands-on assistance configuring your environment, we do offer Expert and Professional Services that can help with all sorts of implementations. You’re always welcome to reach
We looked for combination of attributes to correlate but none of the above works.
So, can i get any suggestions for aggregating these accounts?
And if the account is not aggregated, can we somehow do a reporting of these kinds of accounts?
Thanks,
Adrish