Single Account Aggregation for WebServices Connector

Identity Security Cloud (ISC) ISC Discussion and Questions
,
1

Hello Everyone,

We have a requirement to do single account aggregation for a webservices connected source, but the API does not support filtering, so just wanted to know if it is possible to use $getObject.nativeIdentity$ in Root Path / Response Mapping to filter out? If yes, please provide inputs on how to use it,

Thanks,
Supreeth D

2

Hi Supreeth,
Were you able to achieve it ? You can also use $response.id(what you need)

3

Hi Rakesh,

We can use $response only when we have a parent endpoint right?
I was trying to add a filter as such in Root Path as below, but it did not work

$.Report [?(@.ID == “$getobject.nativeIdentity$”)] , i need nativeIdentity without which i wont be able to filter out the response for single account aggregation.

Thanks,
Supreeth D

4

Hi Supreeth,
Have you looked at the following article ?

5

I have seen this document, this is not helpful for single account aggregation.
Using filters i cannot dynamically populate value via the filter to do single account aggregation.
The feature which i want to use is Loading Account Data - SailPoint Identity Services

6

Hello @supi890
Do you mind sharing more info like:

  • Name of the WSC Source
  • Context of your requirement

If the WSC Source does not support fetching single account details, then there is nothing much you can do. However, based on your specific requirement, you might be able to combine multiple options available in IDN to achieve what you want to

7

Hi Nithesh,

Requirement: The API response contains all records (there is no filtering option) so i wanted to know if there is any way to use $getobject.nativeIdentity$ in the response root path/ response mapping so i can provide single account aggregation feature. The reason i am looking for this option is client wants to handle immediate termination via Support team but is only providing helpdesk access to support team, this way they cannot change lifecycle state manually. So only alternative is to allow single account aggregation, support team can initiate “Single Account Aggregation” to fetch latest details, based on the details lcs can be recalculated.

Thanks,
Supreeth D

8

Okay… so you are planning to use $getObject.nativeIdentity$ as a filter parameter in response root path (Something like $.[?(@userId=\"$getObject.nativeIdentity$\")]). This might be a possibility, but again you are going to fetch all the records to filter out one single record? Does not seem like a good design approach to me. And, even if you wish to go this route, your approach will depend on certain factors like

  • does your source return all records in single call?
  • Or are you using pagination?

If you share the name of your WSC source, may be you will find someone who had a similar situation in the past and can help you better

9

Thanks Nithesh, will give it a try.

The API returns all records in a single call and there is no pagination.
The reason i am not sharing WSC source name is because the application is home grown (client developed), they have exposed API recently.

10

If it’s a custom developed system, then there is no point sharing the name :slight_smile: . On the same note, if it is custom developed, then they can easily create an end point to GET a single record :smiley: (It is a part of REST API Guidelines after all)

Not having to paginate eliminates some complexity of your situation… Let me know if you were able to resolve the issue using the filter in root path

Thanks

11

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.