Implementing Colin's Reassignment workflows - getting an error message

[WyssAJ01 (Adam Wyss)]

Hey all, has anyone implemented @colin_mckibben’s workflows shown in this post:

Reassign Object Owners Using IdentityNow Workflows

[header-image] Introduction Object ownership in IdentityNow refers to identities that own sources, roles, access profiles, workflows, and more. Object ownership is an important concept in IdentityNow as it identifies the person who is responsible for managing the object, which may involve tasks like manually provisioning entitlements and accounts or certifying access on a source. When an identity changes roles within a company or leaves the company, this creates a scenario where they may n…

I’m trying to set them up and the actual “sub-workflows” that do the reassignment are failing when trying to test them.

I can make the JSON patch call in postman just fine but when I take that and put it into IDN to test the workflow, it fails. Even when putting newOnwerId directly into the workflow request body.

[colin_mckibben]

Can you share the JSON of the workflow that is failing? It would also help if you can share the execution log. Please be sure to redact any sensitive information first.

[WyssAJ01 (Adam Wyss)]

Here’s the step input from the workflow test. Specifically, reassign roles HTTP Request 1 step. Inside jsonPatchRequestBody, I specified the ID of the new identity for testing purposes but normally it would use {{$.trigger.newOwnerId}}

  "authenticationType": "OAuth",
  "basicAuthPassword": null,
  "basicAuthUserName": null,
  "csvRequestBody": null,
  "formRequestBody": null,
  "headerAuthName": null,
  "headerAuthValue": null,
  "jsonPatchRequestBody": [
    {
      "op": "replace",
      "path": "/owner",
      "value": {
        "id": "2c9180867c27d5bd017c2d8762616ed2",
        "type": "IDENTITY"
      }
    }
  ],
  "jsonRequestBody": null,
  "method": "patch",
  "oAuthClientId": "redacted",
  "oAuthClientSecret": "$.secrets.0a344184-173a-4473-922a-906a06eb7c85",
  "oAuthCredentialLocation": null,
  "oAuthScope": null,
  "oAuthTokenUrl": "https://tenant.api.identitynow.com/oauth/token",
  "requestContentType": "json-patch+json",
  "requestHeaders": null,
  "suppliedInlineExpression": {
    "url": "https://wabtec-sb.api.identitynow.com/v3/roles/{{$.hTTPRequest.body[0].id}}"
  },
  "textRequestBody": null,
  "url": "https:/tenant.api.identitynow.com/v3/roles/roleID",
  "urlParams": null
}

[colin_mckibben]

What’s the error message? Is it a 400?

[WyssAJ01 (Adam Wyss)]

I found the results CSV file with @edmarks help. I’m getting a 403. That fixed the original issue so apparently the API wants to be run in user context.

The last question I have then is how do we address the use case of multiple items of the same type? I can see you repeated the patch request but the original HTTP request only gets 1 role, AP, etc. But what if someone has 2 or more? Do we need to modify it to loop the steps?

[colin_mckibben]

That’s where the recursion comes in . The child workflow will process one access item at a time. For example, if an identity has three roles, then the child workflow will execute three times. The flow will look like this.

1. Get roles owned by the identity. Use limit=1 so we only get the first role in the list.
2. Change the owner of the role to the new owner.
3. Invoke this workflow’s external trigger so it executes again.
4. Repeat steps 1-3 until step 1 returns an empty response. This means the original identity has no more roles to reassign. Terminate the child workflow.

[WyssAJ01 (Adam Wyss)]

so that’s what the HTTP Request 2 is supposed to be is the external trigger to re-run the child workflow again?

Edit: Yep. I see it now. Thanks a lot for the assistance, Colin!

[colin_mckibben]

No problem. Recursion is a tricky concept, so I’m happy to explain the nuances of this workflow to help others understand it.