Workflow passing array to Json Body

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

Hi,
I have some issues in workflow where I try to pass an Array to a body in HTTP Request Action.
It is basically exactly the same issue as in another thread I found which got closed without solution: Workflow - Passing array to "Enter Value" field

In my case it is that I am creating a certification with the HTTP request (instead of the OOTB Certification action due to that is more limited to what it can filter on). In my case I want to certify only Access profiles for a specific Identity and I need to use a certification of type search.
This is the overview of my workflow:

image
image667Ă—790 28.1 KB

To do this I need to pass in all access profiles ids which the user has which I get from using Get Access. I can see that they are all collected into my variable: {{$.getAccess.accessItems[*].id}} and they are comma separated. But when I use this variable in the enter field value it is entered without the commas, meaning:
[“123”, “152”, “166”] instead becomes [“123” “152” “166”] which is incorrect json. I wouldn’t say it is a bug but it causes issues… Anyone got any suggestion on what to do?

Regards
Jesper

2

Maybe it’s possible that the commas won’t be excluded if you replace the “Get Access” action with another HTTP Request where you search for the access-profiles via v3/search API.

HTTP search body:

{
    "indices": [
        "accessprofiles"
    ],
    "query": {
        "query": "source.name:*"
    }
}

Maybe it will format the list in the same way in the 2nd request but could be worth a try.

Seb

3

Hi, thanks for the suggestion, sadly it was same thing using search as well, commas disappeared when using the variable inside the jsonbody :frowning:

4

Do you even need the “Get Access” action then?

In the HTTP request where you create the certification just use the same query.

Then if you need to exclude or include certain access profiles you can tag those and use the tag in the query:

{
    "indices": [
        "accessprofiles"
    ],
    "query": {
        "query": "NOT tags:blablabla"
    }
}
5

Well this is for a mover event, and I want to include all accessProfiles which this specific user has, for starters this search will return every single AP that exists in the tenant (bit over kill but works ofc). But not sure anyway that I can use that specific case, or atleast I am uncertain what the query would look like.
This is what I do right now fyi:

{
            "filter": null,
            "sunsetCommentsRequired": true,
            "mandatoryCommentRequirement": "REVOKE_ONLY_DECISIONS",
            "sourceOwnerCampaignInfo": null,
            "searchCampaignInfo": {
                "type": "IDENTITY",
                "description": "testing",
                "reviewerId": null,
                "reviewer": null,
                "query": null,
                "identityIds": [
                    "1616nj316bbdd33351"
                ],
                "accessConstraints": [
				{
					"type": "ACCESS_PROFILE",
					"ids": [
					"1251521512516",
                                        "1262136236261"
                    ],
					"operator":"SELECTED"
				}
				]
            },
            "roleCompositionCampaignInfo": null,
            "alerts": null,
            "sourcesWithOrphanEntitlements": null,
            "id": null,
            "name": "test movers",
            "description": "testing",
            "deadline": null,
            "type": "SEARCH",
            "status": null,
            "correlatedStatus": "CORRELATED",
            "emailNotificationEnabled": false,
            "autoRevokeAllowed": false,
            "recommendationsEnabled": true
}

If there is another way to do what I am after I am all ears, perhaps I can put your query into the query field where I currently have null and just remove the accessConstraints(?). I simply did what I was after in a search caompaign and then reversed engineered to do the same from the workflow.

6

This is what we use for department movers.

The “tags” query is simply so that we can exclude certain birthright access. Even if the query itself returns all APs in the tenant, only the ones that the identity actually has will be included in the certification campaign.

{
    "autoRevokeAllowed": false,
    "description": "Certifcation Campaign Created",
    "emailNotificationEnabled": true,
    "name": "New Department: {{$.getIdentity.attributes.displayName}}",
    "recommendationsEnabled": true,
    "searchCampaignInfo": {
        "identityIds": [
            "{{$.trigger.identity.id}}"
        ],
        "indices": [
            "accessprofiles"
        ],
        "query": "NOT tags:blablabla",
        "reviewer": {
            "id": "{{$.getIdentity2.id}}",
            "type": "IDENTITY"
        },
        "type": "ACCESS"
    },
    "type": "SEARCH"
}
7

Tried your suggestion but this also includes entitlements in the certification I am afraid :frowning:

8

This is a known limitation with inline variables. Objects and arrays do not serialize to proper JSON. Instead, they are serialized as Golang maps/arrays. This is why you see arrays being presented without commas and objects that have the map[] keyword in them when referencing them with inline variables. As of now, only single values, like string, integer, and boolean can be referenced with inline variables. There is a feature request open (PLTWRKFLW-1352) to support objects and arrays.

1 Like
9

Hi Colin!
I see, thank you for the information both regarding the limitation and request ticket :slight_smile:

11

Hi Jesper,

We have a similar requirement and SailPoint support suggested inline variables. I adapted the sample and we are able to use the string array resulted from Get Access in the HTTP request that successfully creates a certification campaign.

In the HTTP body for accessConstraints use:

  "searchCampaignInfo": {
    "accessConstraints": [
      {
        "ids.$": "$.getAccess.accessItems[*].id",
        "operator": "SELECTED",
        "type": "ACCESS_PROFILE"
      }
    ],
    "identityIds": [
      "{{$.getIdentity.id}}"
    ],
    "reviewer": {
      "id": "{{$.getListOfIdentities.identities[0].id}}",
      "type": "IDENTITY"
    },

As you can see, the rest of the HTTP body can use regular workflow variables syntax.
Consider that in this example, Get Access only retrieves access profiles. If you would retrieve ALL items then this path $.getAccess.accessItems[*].id needs to be refined.

Regards,
Jazmin

1 Like
13

Hi! Thanks for the tip, I will try this out, the project at the time is over but could be useful for the future :slight_smile:

14

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