Webservice Connector - Aggregation - Context Url Variable

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

i have setup a webservice connector to a legacy webservice. I setup an aggregate operation.
contextUrl: /api/emp=100
The get api returns 0 or 1 row for the given identity.

contextUrl: /api/emp=100

I setup the return values, hardcoded the native identity value, aggregation correctly got me 1 expected result.
contextUrl: /api/emp=$nativeIdentity$
Setting $nativeIdentity$ in the context url is not working. How do i set this up, so that the aggregation pulls the correct information for all the identities.

Thanks

2

Hi @rvenkataraman,

Can you elaborate more, let me know your performing single user account aggregation or full account aggregation.

Thank You.

3

my intent is a full account aggregation, but the api will return data for only one user

4

Hi @rvenkataraman ,

If I understand the requirement correctly, I would recommend you try to configure chained / parent aggregation for this.

The context URL should be the unique identifier for the next endpoint.
For example, the chained endpoint would be “/api/emp=$response.id$”.

Let me know if this helps.

5

@dylanfoggan i was relying on being able to use Sailpoint identitynow to provide me the list of employees, i have configured the base url of the source to the legacy web service, the legacy web service does not have an endpoint that gives me a list of employees. can i use the sailpoint api in the context url (which would conflict with the base url). Thanks

6

Hi @rvenkataraman ,

If you want to achieve a full aggregation, you can look at this API here to retrieve a list of users. list-identities | SailPoint Developer Community

With Regards to the Base Url:

The base URL would need to be common across the context URLs. For example, if you have this:

API 1: https://notdemo1.identitynow.com/
API 2: https://testdemo1.identitynow.com/

Base Url would then be https:// and the context URLs would be the details thereafter.

Let me know if this makes sense.

7

Hello @rvenkataraman,

Is this the Get Object operation? If so, you need to use $getObject.nativeIdentity$.

8

@dylanfoggan : what i have here is
base url - https://legacyapi.test.com/ (i cannot have just https:// here because i need to provide for auth for the legacy api)
API 1: https://notdemo1.identitynow.com/beta/identities
API 2: /api/emp=$response.id$
since the base url has to be the same for api1 and api2, this will not work. Is there an alternate way to accomplish this

thanks

9

@bcariaga : Based on your suggestion, i configured the get object operation setup to use $getObject.nativeIdentity$, but am having difficulty triggering the aggregation. i am not able to find an api that would take in the source and account both into consideration

10

I may have misunderstood what your use case is. Can you please go into detail what you are trying to accomplish?

11

@bcariaga I have a legacy endpoint that has methods for getting | creating | updating an user’s access to the legacy system. I am trying to use the WebService Connector to onboard the webservice into idnow.

  1. All the methods deal with only one user. Lets assume base url - https://legacyapi.test.com/ and contextUrl could be getUser/createUser/updateUser
  2. the legacy system already has data so i am just looking at the getUser operation. The goal is to do a full aggregation based on what is in Sailpoint
  3. the input to the getUser method is a userId which is one of the attributes which is in Sailpoint identity.
  4. the userId is a variable in the contextUrl
  5. There are suggestions for chaining the api calls, but they have different endpoints in my case (the first api would need to call a internal saipoint api to pull all the identities), the second api would need to call the legacy api to get each of the user’s access information.
  6. If i configure the getObject operation for a single account aggregation, i am not able to execute an aggregation thru api.
12

This is a difficult use case given there is no endpoint to know if someone has the account or not. I’d agree with the above statement for chaining, but there is two caveats I can think of: You will have equal number of accounts on the source as there are identities in the system even if the second call doesn’t get a user and needing two separate authentications.

I’d definitely recommend keeping your source base configuration set to the target source so other operations can leverage it. Keep the IdentityNow specific information manually added.

Here are some thoughts for steps I have:

  1. Configure the connector to use the legacy API baseURL and authentication.
  2. Configure a 2 step aggregation:
    2.1 Configure the first as the list identities with a single mapping response to the attribute you are searching. Ensure you complete pagination on this.
    2.1.1 Use a before operation rule to:
    2.1.1.1 Get the authentication token for IdentityNow using the restClient.executePost()
    2.1.1.2 Attach the authentication token to the header of the requestEndpoint.
    Note: You should be able to store the PAT Client ID and Secret on the “connectorAttributes” of the source schema to be accessed in the rule under the “application” object. Just be sure to add the secret to the encrypted values list on the source schema.
    Note: You may be able to avoid the before rule if you split this into multiple operation steps (ex. First get the token, Second get the list and pass the token) - I am not sure if this will work or not I’ve never done this.
    2.2 Setup second step of aggregation for /api/emp=$response.id$

You may need an after operation rule that prunes the returned objects to only the ones that were found in the second operation.

If the two step approach doesn’t work, you can use the first operation (list-identities) and the before rule, but also use an after operation rule to make the call to the target system (restClient.executeGet()) using the response objects and then prune the not found ones as you go. Then fill the response body with the collected attributes. Here is an example similar to doing this: Webservice Connector - Create Account Operation - Empty Response - #6 by bcariaga

I may be over complicating this, so others feel free to correct me or offer a better solution.

Let me know if you give this a shot and how it goes for you :slight_smile:

13

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