Initial load of accounts if the application has no aggregator

Which IIQ version are you inquiring about?

8.4p1

Share all details about your problem, including any error messages you may have received.

We have a custom application connector using web services. The application does not support pull of users, how do we do a initial load of the users to IDAM. New accounts will be created via IDAM, so we do not want to invest in a big customization to read the accounts. Is there a CSV or other option to do initial load of accounts.

That’s okay, if they don’t have a get call, what you can do is, ask the application take to share all the identities and their access, and run a batch against those users and access, once the application is onboarded.

Only the identities which will be there in IAM system, the batch will be run against them only, if there are any uncorrelated identities, which exists at the application and not on sailpoint end, Batch will fail.

@naveenkumar3 If access is already there at application end, API call will also be failed while doing the same assignment from IIQ/Batch.

@nvk1 How many accounts are there in the application?

Yes correct, the batch may fail, because we are trying to push duplicate account, but since there is no aggregation sailpoint will don’t know, if the account exist.

he other thing which i can think of you can try is below.

  1. Take the data export from the application team
  2. Create a Delimited File application in IIQ pointing to that CSV
  3. Run aggregation against the CSV — this will create account links in IIQ
  4. Reassign or migrate those account links from the CSV application to the actual web services application- using a custom rule(For each Link on CSV Application:
    → Find the matching Identity
    → Change the Application reference on the Link from CSV App to Web Services App).

You can try the solution, and see if it works.

Hi @nvk1 Just throwing this out there, as is, not tested, just a concept. How about you create a separate Web Service such as airtable to hold the accounts. Then you could possibly use the same connector with independent endpoints for the aggregation.

@nvk1 We ran into a similar use case in one of the projects, we wrote a rule runner and programmatically create/update the links. You can also keep this as an option. At the high level:

  • Prepare a csv of identityname, nativeidentity, , assigned entitlements.
  • write a rule runner which can read from the csv and use the identityname to figure out the identity to correlate.
  • then read rest of the attributes and build a resource object.
  • then pass it to Aggregator API, this’ll create the link in IIQ, like it does during aggregation.

Give it a try, and let us know for any further help.

Note: Found a fix?Help the community by marking the comment as solution. Feel free to react(:heart:,:+1:, etc.)with an emoji to show your appreciation or message me directly if your problem requires a deeper dive.