Looking for alternative to Attribute Sync - Need just provisioning

Identity Security Cloud (ISC) ISC Discussion and Questions
1

Excuse if this has already been answered before (new to IDN):
I am seeking alternative to attribute sync as customer’s requirement is just for provisioning and they don’t want aggregation to happen. Requirement is to update sources (like AD etc) only when Identity gets updated due to authorised source changes but not keep on syncing continuously. If any direct updates are made to the source (like AD), that needs to be updated only if there is an Identity update otherwise not. So, looking for what’s the recommended path here - Before provisioning rule / provisioning policy / anything else?

2

Hi @sachinaggarwal ,

Welcome to Sailpoint Developer Community,

As you said it already, the requirement can be obtained via

  1. Update Provisioning Policy → but when using this, you will seek help from attribute sync.
  2. Before Provisioning Rule Modify Operation → Before and After Operations on Source Account Rule | SailPoint Developer Community
1 Like
3

I’m not sure I understand the use case. Aggregations would be needed in order to know what accounts need to be provisioned and whether they’ve been provisioned successfully, and whether attributes in the downstream source need to be updated when they’re changed in the authoritative source/on the identity. If ISC isn’t aggregating, how would it know who to provision and what accounts need to be updated?

4

Mark, the requirement is changes need to flow to target sources (AD) ONLY when there is a change in the authoritative source (HR). If someone manually updates the source (AD) directly, then customer doesn’t want that to be overwritten by Attribute Sync in absence of authoritative source change.
Let me put the scenario like this in below sequential order of timestamp:
Step A: Update in authoritative source (HR) for attribute “base location city” from NYC to Seattle. This needs to be updated in source (non-authoritative) AD for city to Seattle.
Step B: Someone directly updates in AD city to Chicago. Customer doesn’t want this to be updated back to Seattle by Attribute sync.
Step C: Update in Authoritative source (HR) new base location to Dallas. This needs to be updated in AD to Dallas.

Problem Statement is how to meet the step B requirements of the customer assuming if aggregation runs frequently (i.e. after every above step and more). Customer wants only the report for step B rather than SailPoint overwriting the value.

6

I can’t think of a straightforward, simple way to achieve this, but by golly can I think of a convoluted, overly-complicated way! :stuck_out_tongue:

  1. Have a Flat File source configured and set that as the authoritative source.
  2. Set up a Workflow with a trigger of Source Account Created looking for new accounts in the HR source, and another with a trigger of Source Account Updated looking for updates made in AD, and another with a trigger of Source Account Updated looking for updates made in the HR source. Subsequent steps should be the same, as outlined below.
  3. Configure all three of the Workflows with subsequent HTTP Request actions.
  4. Configure the HTTP Request actions to make PUT calls to the Update Account endpoint, updating the corresponding account in the Flat File source.
  5. Configure Attribute Sync from the Flat File source to AD.

I can’t stress enough how much I don’t suggest doing this, btw. The HR source should be the definitive source of truth for attributes, and changes that need to be made should be made upstream in the HR source. But if you really insist, there’s your workaround :slight_smile:

7

Hi Sachin

As we are already thinking about the workaround solutions, there is something that came to my mind, but you can try it and then let us know if this meets your requirement.

Note: I am assuming here the target application is AD and you already have a source configured in identityNow.

You could try here to use the workflow and have a trigger identity attribute changes where using a variable (this shall store the identity attributes based on which you would like to trigger an attribute sync once they are updated ), you may compare if the attribute which was updated is there in your variable, if it is not present then you can make the workflow successful.
If the attribute change should trigger the sync, then you can call a powershell script from workflow by passing the updated attribute and its values.
Note that I am again not aware of it is possible to call the powershell script via workflow but I found here a solution provided by our fellow ambassador so I guess it is possible and hence worth trying.

Please let me know if the solution meets your requirements. But again as Mark already mentioned it is a workaround solution and likewise I would also recommend to have the provisioning enabled with attribute sync configuration.

But atleast with this approach I believe you can even run agggregation (plus no need to enable attribute sync) and then have a custom dashboard created to see the differences if powershell script fails and then manually or automatically process the differences periodically.

I hope this help. Please keep us posted.

Regards
Vikas