I am looking for the available options to tranform the attributes “onUpdate”(attribute sync). I know that On account create it is very straight forward transormation functions or rules will do this job for us.
What are the different options available to transform attribures values?
One suggestion i see in some docs or forums is to tranform required account attributes and store it in identity attributes that will sync to the target source. But, This approach i dont think it is the best practice, why would account attributes has to be stored on identity, those account attributes might not even be used except sync to one specific source on update.
The way attribute sync works is tries to ensure that the value of an “Identity” attribute matches that of an “Account” attribute. If they do not match, then IdentityNow will trigger an attribute sync.
While I understand that sometimes you may need to sync something in different format (e.g. sync HR Manager reference to AD manager attribute), but if you do some transformation on the attribute value going out then the account and identity attributes will never truly be in “sync”. This means IdentityNow will infinitely keep on “syncing” that attribute.
This is why the current solution is to store the “required” account attribute on the identity level in a new identity attribute. You can apply any transforms you want there and choose to synchronize the already transformed “identity” attribute.
Hi @anneragh I have had a similar kind of a requirement which I implemented a year back to one of the customer. I used the approach of storing it to an identity attribute and sync.
As mentioned by @mostafa_helmy we will face some continuous sync triggering for the source
As I mentioned, I know this solution. But I have 100+ attributes that require transformation for multiple sources, so I have to create 100+ attributes on identity.
My concerns are, I already have 75+ attributes on my identity. In different target sources, we have 100+ attributes that require transformation.
Is it best practice to store an attribute that does not even belong to an identity but belongs to an account?
Does creating a more number of attributes on identity impact our ABAC model performance, How does the ABAC model is designed on INow?
Does creating a more number of attributes on identity impact data load or storage or visibility on UI screens?
Some of these transformed attributes are sensitive in nature, apart from admin no one should have visibility in UI and don’t want to store it on the cloud/INow, we want to transform and store it only on account.
Currently the only way attribute sync works is, having the identity attribute defined with the applicable transforms and then use it to sync the account. Also, if its not an exact match(case-sensitive) the sync keeps triggering until data on both ends match.
The solutions that may help your usecase are Ideas under Future Consideration from Sailpoint. Check out these on the Ideas portal.
I understand that this rule will be activated by IDN when it detects a change. However, it may not be able to detect a change if there is no value stored for identity. Additionally, it will be triggered every time there is an update on identity.
Performance wise, I think using beforeModify rule will not be optimal for the reasons you mention (would trigger too often and would try to sync each attr each time). It would be challenging to control the invoke/trigger of the rule itself.
The benefit you get is attributes won’t show in UI and you don’t need to define them in Identity profile. The biggest drawback though, is lot of development effort and maintenance would be needed for keeping the rule up to date with all attributes and their transform.
As a workaround, maybe you can use both options-
For the attributes that don’t need to show on UI, you can do them programmatically
For other, use built in Identity Attribute sync functionality