We currently have a Web Services connector setup that is running into a case sensitivity issue during IDN account aggregations.
When accounts are created on the source through the API (doesn’t matter if it is through IDN or locally) a unique accountId is generated by the source and returned in the response. This is fine 99% of the time but the source accountId generator only uses letters, for example abCdE. This generator is case sensitive so it can also create an accountId of abCDE, and they are two unique accounts.
In IDN, we have noticed that if there are two accounts with the same letters, but different casings, it will only end up having one of the accounts in the Accounts list after an aggregation. It seems to be case insensitive and just considers the second one a duplicate.
Is there any way to enforce case sensitivity for this attribute in IDN so it can see both accounts as two separate accounts?
Hi Zach,
I think this is the way IdentityNow process. Can you make a change in the target generator where it appends a number as well while generating the accountId?
If for generating the unique userName you are using a format like $firstname.$lastName, then believe you can also update these attribute in the create provisioning and make them uppercase always using transform. That will make sure the new userNames which will be generated are all in same case and should resolve your issue.
Add a new attribute userIdInt and set this as Account ID (Leave current userID attribute as is)
In AfterOperation rule convert each character of original userID into an integer and concatenate (with a separator) these integers to form userIdInt and add it to the map. userIdInt for abCdE will look like 97.98.67.100.69
In all Provisioning operations convert this back to alphabets and append the value wherever original userId is required
I cannot change the target generator as this is a SaaS application and the company will not update their generator. If it is helpful, this is a connector for Udemy we are working on.
We are not generating the accountId, it is being generated by the source system when an account is created. It is not based on any of the attributes used in our account create provisioning policy.
This is an interesting idea that might be able to work, but I’d have to think about it some more. For this connector, we are also using the Reverse Entitlement Aggregation rule to correlate groups and users. The groups endpoint returns the accountIds for each member of the group and that is being compared to the user accountIds to do the entitlement association. With this setup, we can’t really change the accountId in the schema because this correlation rule won’t work as expected. We previously had a second child aggregation that ran that would do individual user membership operations, but there were performance issues with the Udemy API that led us to the Reverse Entitlement Aggregation rule.
This is a good idea though and I’ll do some testing to see if something along these lines can work in conjunction with our existing After Operation rule.
I haven’t stopped with this, but I did want to share some noteworthy information.
I opened a ticket with support to confirm the expect behavior of IDN. Should it treat accountIds with different casing as unique or not (is it case sensitive)? The response I got is that IDN should be case-sensitive with how it handles accountIds and should be treating these as separate accounts. However, the caveat is, “case sensitivity is not uniform across the product so inconsistencies are somewhat expected. The recommendation that I was given was to leverage an accountId that is completely unique, rather than relying on case sensitivity to separate two accounts”.
This kind of feels like a bug from my perspective since it is not behaving as expected, but I didn’t want to press the issue. At least knowing how it is behaving is helpful to try and figure out a workaround. I am working on a solution I have in mind for this and I’ll share if/when I figure it out.