Access Profile and Entitlement APIs Can't Handle Plus Symbol

We have entitlements and access profiles that include the plus symbol (+), these are being aggregated without any issues, but when using the v3 Access Profiles or Entitlements API to list we are not able to filter on the exact name of these resources. Example query:

https://[TENANT_URL]/v3/access-profiles?filters=name%20eq%20%22Test%20Entitlement%20With+%22

Ideally there’d be a way to filter to these resources with some kind of encoding, but I haven’t been able to find any that works for me.

When reaching out to support on this I was pointed to this article discussing errors when aggregating entitlements:

This isn’t the issue that we’re facing, but does seem to point to an underlying issue if there have been problems in the past when handling entitlements with special characters.

1 Like

Hello James,

just come across the Search Query document recently. I believe in your case, it’s related to handle special characters: Building a Search Query - SailPoint Identity Services

not 100% sure if the elastic query is the same query can be used in the API query parameter. but maybe you can give it a try? Or otherwise, I believe at least you can use it with Search Post API search-post | SailPoint Developer Community to achieve sam goal.

so in your case, the search query might be

name.exact:/.*+.*/

There is an open engineering ticket to investigate this issue (SAASTRIAGE-2891).

Hi Yu,

Thanks for that information, I had tried using wildcards and regexes but hadn’t tried with the slashes they talk about there. Unfortunately it still didn’t make a difference for the filter function, I think it must just be a search feature.

We would use the search API but unfortunately the access profile owner information doesn’t come back from the search queries, and we need that for the integration we’re using. I’ve tried adding in owner as a field in search:

 "fields": [
            "name",
            "description",
            "displayName",
            "owner"
        ],

But that doesn’t work, have also tried owner.email or owner.id, but not been able to get anything back on this. The only alternative I can think of would be to use search to get the entitlement and access profile IDs, and then use the direct APIs to get the data, but that’s doubling the number of API calls we have to do so not ideal, the work we’re doing is to try and reduce the time needed for some of our automation, so this would go against the overall goal.

Thanks for the update Colin, good to know this is being looked at! When was the ticket opened? Do you have any idea on some kind of ETA for this kind of thing? (is this something that might be open for months or more like days or weeks?)

It was opened 2 days ago. ETA is hard to gauge on these items until a priority is assigned to the ticket.

2 Likes