We’re having some internal debate on how to provision attributes to end points when they change. I’d like to see what others think, are doing.
When an attribute is on the identity cube we set a mapped target in identity mappings. When it changes it automatically gets pushed to the specific end point.
Not all our attributes are on the identity cube. Some of them are sourced from links. The attributes sourced from a link can be pushed using a fieldvalue rule and pushed when the identity is refreshed. It can also be pushed using a life cycle rule and a workflow.
We’ve tried asking support how many attributes can we put on an identity cube before we see a performance loss but were not able to get an answer, because of course it depends on what you’re doing.
I am really just hoping to hear how others get identity attributes and linked attributes provisioned out to end points. Are there any pros / cons from a fieldValue refresh approach or a lifecycle workflow approach?
The fieldvalue rule should not be used unless there is no other mechanism as the rule will be triggered for every Identity refresh operation. Ideally if these values can be stored using a custom attribute would be more beneficial. The impact on performance will be dependent on the number of identities and the number of attributes coupled with the logic and code written in the rules. Hence predicting the performance impact is a challenge. however as a best practice would recommend reducing the usage of field value rules to a minimum and only when required.
Can you please explain a bit more. I’ll explain our situation a bit more here.
If we have a link/application ABC App for example. And that app aggregates in an attribute abc attribute. And we have another app XYZ App for example that needs abc attribute and no other links/attributes need that attribute what approach should we take to get that attribute from ABC app onto XYZ App and have it change when it is changed in ABC App?
you can add as many identity attributes as you want, there is only limit for searchable fields in SailPoint, even searchable fields as well we can extend from DB updated scripts.
I would suggest using identity attribute target mapping is the best way to push the updated values from SailPoint to target systems.
even source mapping is from the target, you can also map to many target sources as you want.