At the time of writing this document, IdentityNow’s identity attributes do not support storing multivalued attributes or strings with over 450 characters in an identity attribute. Due to this, account attributes with these types attributes are unable to be attribute synced through the normal process.
Configuring Multivalued Attribute Sync
This document covers the process to attribute sync a multivalued account attribute from one source to another source.
1. Identify Attributes to Sync
First, identify the multivalued attribute on the source that will be attribute synced from, and the attribute on the source system that will be attributed synced.
The following will be used in this document:
agent_codes-auth: The multivalued account attribute to attribute sync from.
agent_codes: The multivalued account attribute on the end system to attribute sync to.
2. Identify Additional Attribute Already Synced
Find a string attribute that is currently being attribute synced to the end system. Most typically used for this would be the firstName attribute.
Create a new identity attribute on the identity profile called firstNameAttributeSync.
3. Create Cloud Rule for firstNameAttributeSync
For the firstNameAttributeSync attribute, change the identity profile attribute from a direct reference to a Cloud Identity Attribute rule.
This rule should do the following:
· Get the value of the firstName attribute from the authoritative source account
· Get the list value of agent_codes-auth from the authoritative source account
· Get the list value of agent_codes from the end system account
· Compare the list values of agent_codes-auth and agent_codes
· If the values are the same, return the value of the firstName attribute from the authoritative source
· If the values are not the same, append the string “#SAILPOINT_ATTRIBUTE_SYNC#” followed by the string date and time to the end of the firstName and return that.
If users name is John, will look something like: John#SAILPOINT_ATTRIBUTE_SYNC#Mon Aug 14 2023 15:13:02
This rule will now serve as the multivalued attribute sync detection, as it will only set #SAILPOINT_ATTRIBUTE_SYNC# and the date and time at the end of the first name if the multivalued list on the authoritative source and end system do not match.
NOTE: The date with the time is required to add to the end of the string.** The reason is because IdentityNow will not attribute sync a value that has not changed. If the date is not added, there runs the potential that the multivalued attribute on the auth source could change before an aggregation is ran, resulting in the cloud rule returning the same first name with the attr sync flag string appended to the end and attribute sync wouldn’t occur until the identity were to change. Adding date insures the value is always different even if an aggregation is not ran in between.
If the lists do match, then return the firstName attribute from the authoritative source as there is nothing to sync.
Example of Identity Attribute rule that does this found here. This rule was made generic from a customer’s rule so there could be syntax errors.
firstNameAttrSync Rule.xml (3.1 KB)
4. Create Before Provisioning Rule for End System
If a before provisioning rule has not yet been created for the end system source to sync the values to, then create one. Otherwise, update the existing rule to include the following logic:
- Check each attribute request value in the provisioning plan to see if any values contain the substring “#SAILPOINT_ATTRIBUTE_SYNC#”
- If the value of an attribute request contains “#SAILPOINT_ATTRIBUTE_SYNC#”, then pull the value of agent_codes-auth from the user’s authoritative source account and pull the value of agent_codes from the end system account. Additionally also remove the substring #SAILPOINT_ATTRIBUTE_SYNC# and anything after it and set that value back on the attribute request. (This sets the first name attribute value back to the user’s first name so it doesn’t get updated with the flag)
- Compare agent_codes-auth with agent_codes and if they do not match, then create a new AttributeRequest as follows:
AttributeRequest Name: agent_codes (name of the end system attribute)
AttributeRequest Operation: set
AttributeRequest Value: List object value of the agent_codes_auth
This insures that first name stays as the first name, since the flag will be removed if it is set, and additionally will add the multivalued list attribute requests to the provisioning plan as well as part of the attribute sync.
An example before provisioning rule can be found below:
Multivalued Attribute Sync Before Provisioning Rule.xml (3.9 KB)
5. Multivalued Attribute Sync Configuration
Once the identity attribute and cloud rules have been created, on the create provisioning policy of the end system source, set the agent_code attribute to be mapped to the firstNameAttrSync identity attribute. Enable the check in the attribute sync checkbox as well to start syncing that attribute to the end system.
Additionally, set the before provisioning rule on the end system source, and set the cloud rule on the firstNameAttrSync identity attribute as well.
6. Extending for Additional Multivalued Attributes
If more than 1 multivalued attribute needs to be synced, a new attribute for each is not needed. Even if the they span across different sources. All that needs to be done is update the same firstNameAttrSync cloud rule, so that the multivalued attribute in the auth source is compared to what it is on the end system. If any of the multivalued list attribute lists do not match, then add the flag with the date on the end and be sure to update the before provisioning rules to add all multivalued attributes to the plan if the flag is detected on any identity attribute value.
Pros/Cons
The pros to this approach is that it will allow any number of multivalued attributes to be synced to the end systems.
The cons are as follows:
- Requires rules to update and maintain, more code intensive than other IDN features.
- There is some abstraction to knowing how IDN is attribute syncing multivalued attributes. Since firstNameAttrSync is controlling all the multivalued attribute sync, its not clear that they are being synced from the attribute sync page.
- If extending for multiple multivalued attributes to sync, all the multivalued attributes must be synced together or not at all
- Since the above example is basically utilizing firstNameAttrSync to synchronize all the multivalued attributes they are only synced when firstNameAttrSync is synced. So if multiple multivalued attributes are using this approach, they all must be turned off or on together.
- Additional attributes could be spun to handle the multivalued separately, instead of adding them all in one rule. But this adds additional identity attributes to maintain and causes more overhead of rules to run during identity attribute promotion.
- Unknown of the scalability of this approach. Assumption is clients wouldn’t have a lot of multivalued attribute syncing. This approach does some account searching which could bog down performance if there are a lot of these types of cloud rules running.
Conclusion
With the addition of two cloud rules and an identity attribute, multivalued attribute sync is possible in IDN.