Access Profile and Entitlement APIs Can't Handle Plus Symbol

Feedback Bugs
,
1

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.

2 Likes
2

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:/.*+.*/
1 Like
3

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

1 Like
4

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.

1 Like
5

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?)

6

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

2 Likes
7

Hi Colin. Seeing if there is an update to this case as yet (SAASTRIAGE-2891)

8

Engineering has opted to document this limitation in the API spec for the time being. The issue is in the underlying service that handles these filters, and this service is due to be upgraded at the end of the year. This may fix the issue, but for the time being engineering is not going to prioritize this.