Issues Deleting Accounts from Oracle IDCS SaaS Source

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

We are currently working through the configuration of a Web Services SaaS source connecting to an Oracle IDCS tenant. Most things are working as expected but the only hitch is an HTTP Operation to delete the account. Using Oracle’s documentation I’ve been able to use Postman to delete an account without issue using the forceDelete query parameter, getting the expected 204 response. However, when we configure an HTTP Operation with the same endpoint information and attempt the process a delete, we see the following error returned:

Error: Incomplete items. Please contact your administrator.

Attempting to use the SDK to tail the logs, the only thing we see returned, even with debugging enabled, is a 400 error and the fact that it doesn’t match the 2** expected response.

In a perfect world, someone would know of a solution to the deletion issue, but at this point I’d be more than happy with some additional methods to get more information on what is actually causing the error.

2

Welcome back, Scott.

I would first verify that the Delete operation is using Oracle’s actual user id:

DELETE /admin/v1/Users/$plan.nativeIdentity$?forceDelete=true

with no body. $plan.nativeIdentity$ represents the source Account ID, so make sure your Account ID is mapped to Oracle id, not userName.

If that already matches your configuration, could you share the Delete Account HTTP Operation and confirm which account schema attribute is configured as the Account ID?

3

Hi Harish,

Thanks for the response. To answer you questions, in the response mapping we do have id being mapped to id and userName being mapped to userName in both the individual and full aggregations.

Below is the HTTP Operation for Delete Account:

{
    "httpMethodType": "DELETE",
    "pagingInitialOffset": 0,
    "requestType": "API",
    "sequenceNumberForEndpoint": "9",
    "uniqueNameForEndPoint": "Delete Account",
    "rootPath": "$",
    "body": {
        "bodyFormData": null,
        "bodyFormat": "formData"
    },
    "paginationSteps": null,
    "responseCode": [
        "2**"
    ],
    "resMappingObj": null,
    "contextUrl": "/Users/$plan.nativeIdentity$?forceDelete=true",
    "pagingSize": 50,
    "header": {
        "Authorization": "$application.accesstoken$",
        "Accept": "application/json"
    },
    "operationType": "Delete Account",
    "xpathNamespaces": null,
    "parentEndpointName": null
},

And the id attribute is configured as the Account ID in the account schema with the userName being configured as the Account Name.

4

Hi @skliemann_af ,

Instead of $plan.nativeIdentity$, can you try $getObject.nativeIdentity$? Also is it mandatory to pass forceDelete=true? try it once removing this query param.

5

I can certainly give that a shot and report back. Unfortunately, the query parameter is a necessity as it prevents the need to remove the identity from any group memberships prior to attempting to delete.

Later edit: Did try using $getObject.nativeIdentity$ and that unfortunately returns the exact same error. 400 doesn't match to allowed success codes from the resulting email and an Error: Incomplete items error from the UI.

6

Hi @scotth77

Can you try hardcoding the url instead of using $plan.nativeIdentity$ , does it work then ? That will give you little bit of an idea whether the issue is with native Identity or some other details are missing.

You will not see any logs as it is SAAS connector so not sure if you are checking with SailPoint for the logs but atleast on VA they wont be visible.

I would suggest you try first hardcoding the user id in the context URL and then see if that helps.

If that does not help, may be you need to also pass RESOURCE_TYPE header in configuration in case the DELETE method is using older version.

I hope this helps.

Regards

Vikas.

7

Hi @vguleria ,

I gave the hardcoded method a try and I’m afraid I still see the same errors. This hardcoded approach is the same one that I use when testing the endpoint with Postman, where it does work. Additionally, within Postman, I am not sending the RESOURCE_TYPE_SCHEMA_VERSION header and it does work. I can certainly try sending that header though via SailPoint using some of the variations listed in the entry.

I appreciate all the responses from everyone but I think I might have to go the SailPoint Support route as this feels like an issue on the SailPoint methodology side of things. The fact that this works without issue in Postman using the same credentials bolsters that argument. If I get a resolution going that route, I’ll report back here.

8

Hello Scott. Since the same hardcoded URL still returns 400 from the connector, $plan.nativeIdentity$ and the URL are unlikely to be the issue. 2** is also correct because it includes Oracle’s successful 204 response.

I would next set the Delete operation to cURL Command and reproduce the working Postman request: DELETE, full URL, Authorization header, and no body (documentation).

If you need to match Postman without a Content-Type header, SailPoint adds Content-Type: application/json by default and documents removeDefaultHeaderFromRequest:true to suppress it (documentation). I would treat this as a test, not the root cause, since Oracle supports that Content-Type for Delete User.

If cURL still returns 400, the next useful item is Oracle’s raw SCIM error response. It can contain detail, messageId, or additionalData explaining the rejection (Oracle documentation). Since your debug logs are not exposing it, I would open a SailPoint Support case and ask for the outbound request and raw Oracle response.