-JsonPatchOperation throwing error "The request was syntactically correct but its content is semantically invalid."

I am using the PowerShell SDK to attempt to remove an access profile from a role. I feed the role name through a .csv file. All values are correct on analysis, but I’m pretty sure my PSCustomObject is incorrect.

param(
    #[Parameter(Mandatory)]
    [string]
    $CsvFilePath = 'RolesToRemoveAccessProfilesFrom.csv'
)

$Roles = Import-Csv $CsvFilePath

$PatchOperationRemoveAP = [PSCustomObject]@{
    op = 'remove'
    path = '/accessProfiles/-'
    value = @( @{
      id = $AccessProfileIDToRemove
      type = 'ACCESS_PROFILE'})
}

foreach ($Role in $Roles) {
    Write-Host "Processing Access Profile " $Role.name
    $filterString = 'name sw "{0}"' -f $Role.name
    $SailPointRole = Get-BetaRoles -Filters $filterString
    $SailPointAccessProfiles = $SailPointRole.accessProfiles
    foreach ($AP in $SailPointAccessProfiles) {
        if ($AP.name -like "*AzAD*") {
            $AccessProfileIDToRemove = $AP.id
        }
    }
    Write-Host 'AP ID:' $AccessProfileIDToRemove
    Write-Host 'Role ID:' $SailPointRole.id
    Update-BetaRole -Id $SailPointRole.id -JsonPatchOperation $PatchOperationRemoveAP
    Write-Host `n"Removing Access Profile" $AccessProfile.name -f Green
}

Any help would be appreciated.

are you getting null? and is it removing right AP in each role?

Am I getting null on what? It errors out with “The request was syntactically correct but its content is semantically invalid.” and then the script stops. It does not remove the access profile.

I noticed if I remove the “/-” on the path of the pscustomobject, it works, but it removes all access profiles.

Hey @aaronknoph the behavior you see is because of the “/-” that you said you removed. This because that dash means append to the end of an array and is relevant in “add” operations. I don’t have the ability to test right now but I would try to put the AP’s id that you want to remove at the end of the path instead of the “-” and see what happens

Actually you may only be able to put the array index of the access profile at the end of the path. So you may need to try to hit the “get” api first and loop through the array of APs on the role to find the index of the one you want to remove.

A cleaner approach might be to use “replace” instead of “remove” and just replace whole list of APs on the role with the current list minus the one that you want to remove.

Thanks Kyle. Very counterintuitive, but there you go. I’ll give that a try.

1 Like

I’m trying to add the access profile back that I actually want the role to have with this:

$PatchOperationAddAP = [PSCustomObject]@{
    op = 'add'
    path = '/accessProfiles/-'
    value = @( @{
      id = $AccessProfileIDToAddBackToRole
      type = 'ACCESS_PROFILE'})
}

but I am getting this error

Invoke-WebRequest: C:\Program Files\WindowsPowerShell\Modules\PSSailpoint\1.3.0\beta\src\PSSailpointBeta\Private\BetaApiClient.ps1:188
Line |
 188 |              $Response = Invoke-WebRequest -Uri $UriBuilder.Uri `
     |                          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     |  {   "messages": [     {       "localeOrigin": "DEFAULT",       "text": "The request was syntactically correct but its content is semantically invalid.",       "locale": "en-US"     },     {       "localeOrigin": "REQUEST",       "text": "The
     | request was syntactically correct but its content is semantically invalid.",       "locale": "en-US"     }   ],   "detailCode": "400.1 Bad request content",   "trackingId": "29e8b8a70ae84db89030034a9a58a7c1" }

Any help with that one? This is very confusing because it’s the same format I am using to remove the access profiles and that works fine.

Can anyone give me some insight on this?

Hey @aaronknoph! Sorry I’ve been out a few days. I think you might have an issue with the extra array “@()” for the value parameter. Try it like this:

$PatchOperationAddAP = [PSCustomObject]@{
    op = 'add'
    path = '/accessProfiles/-'
    value = @{
      id = $AccessProfileIDToAddBackToRole
      type = 'ACCESS_PROFILE'}
}

That worked!!! Thank you Kyle!

1 Like

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