Unable to add Access Profiles to newly created applications

Feedback Bugs
1

What problem are you observing?

When calling the v2024/source-apps/:id endpoint I am unable to add the Access Profiles to my newly created app. The response returns:

{
    "detailCode": "404 Not found",
    "trackingId": "64d06cf1602644ad9f592f227b1d0282",
    "messages": [
        {
            "locale": "und",
            "localeOrigin": "REQUEST",
            "text": "The server did not find a current representation for the target resource."
        },
        {
            "locale": "en-US",
            "localeOrigin": "DEFAULT",
            "text": "The server did not find a current representation for the target resource."
        }
    ],
    "causes": []
}

What is the correct behavior?

This endpoint should allow me to add Access Profiles to my Application.

What product feature is this related to?

This is related to the v2024 version of the source-apps/:id endpoint.

What are the steps to reproduce the issue?

The steps are executed in the following way:

  • Create an Application
  • Create Access Profiles
  • Add Access Profiles to the Application using the v2024/source-apps/:id endpoint with the PATCH method while constructing your json request body in the following way:
[
  {
    "op": "replace",
    "path": "/accessProfiles",
    "value": [
      "287f439b657f4db8878553208c45dd24",
      "1343a9bb51064f6cb04d6d15a0d9d6ab"
    ]
  }
]
2

Although it would be sweet if this was possible, it seems that the documentation patch-source-app | SailPoint Developer Community is wrong and that accessProfiles is not a patchable field. You will also not see that field when calling GET v2024/source-apps/:id or GET v2024/source-apps.

There is an endpoint to remove access profiles by specifying the ones you want to remove: delete-access-profiles-from-source-app-by-bulk | SailPoint Developer Community

There is no endpoint to add access profiles by specifying the ones you want to add.

In this post you specifically mention newly created applications, but I think you have the same issue with the already defined applications right?

There is a hidden undocumented endpoint where you can specify the access profiles you want to add to the application, but it will then remove the access profiles that were already assigned to the application. So it would be a replace operation instead of an add operation. This is impractical in many cases as you would need to first fetch the current access profiles, then add the new ones and then use this replace API. Usually you don’t want to replace, but only add or remove. But this hidden undocumented endpoint is POST /v2024/source-apps/:id/access-profiles, with as JSON body an array of id’s.

So I think that this is very strictly speaking not a bug, with the added notes that

  1. The existing documentation is incorrect
  2. There is documentation missing
  3. The current APIs are not satisfying the best practices.
  4. The truly useful APIs for application management are not available (and SailPoint would likely ask you to raise an enhancement request instead)

Hope this helps,

kind regards,
Angelo

1 Like
3

I see, thank you for your reply. Would you be able to provide me with a request body example for that hidden endpoint?

Kind regards,
Dorijan

4

You can use this: [“foo”,“bar”]

1 Like
5

Just one last thing. How likely is it for this api to be changed, removed or modified in the near future? We need this feature in prod, and I am just wondering how safe would it be to use it?

Thank you for your help.

Kind regards,
Dorijan

6

Good questions, I am not from SailPoint, so I think I am not the right person to answer those questions. Could you perhaps help here @colin_mckibben?

7

To modify the access profiles of an app, please use this endpoint:

You can patch the accessProfiles attribute by either adding, removing, or replacing the values.

In your scenario, you are trying to use replace with a list of access profile IDs. You would do it like so.

PATCH https://tenant.api.identitynow.com/v2024/source-apps/e041dabac8314d7daa68c099d330aae4

[
  {
    "op": "replace",
    "path": "/accessProfiles",
    "value": ["2c91808a7643763f01767b59d9d907cf"]
  }
]

If you still see a 404 Not Found, please be sure you are using the correct ID of the app in the URL. The source Apps endpoint returns a cloudAppId and an id. You will need to use id.

2 Likes
8

accessProfiles is a patchable attribute (we’re using this method currently), it’s just not returned when getting a SourceApp by ID. To get the list of access profiles, you need to use the sub-resource (i.e. /source-apps/:id/access-profiles)

1 Like
9

@DorijanKomEvolt this might be related to a bug we’ve been seeing where there is an apparent timing issue when adding Access Profiles to applications → Cannot consistently add new Access Profiles to Application

1 Like
10

Unfortunately, I am still getting the same error. I double checked if all of the id’s were correct, and they were. For our use case we are using the replace operation to add access profiles to an application, is it possible that there is a step that I skipped here?

URL: PATCH https://tenant.api.identitynow.com/v2024/source-apps/e041dabac8314d7daa68c099d330aae4

Headers:

  • X-SailPoint-Experimental: True,

  • Content-Type: application/json-patch+json

  • Auth token is included

Request body:

[
  {
    "op": "replace",
    "path": "/accessProfiles",
    "value": [
      "2c9180857725c14301772a93bb77242d",
      "c9575abb5e3a4e3db82b2f989a738aa2"
    ]
  }
]

Response body:

{
    "detailCode": "404 Not found",
    "trackingId": "2c8fa9b79a1b4e12aba9386e74e8c219",
    "messages": [
        {
            "locale": "und",
            "localeOrigin": "REQUEST",
            "text": "The server did not find a current representation for the target resource."
        },
        {
            "locale": "en-US",
            "localeOrigin": "DEFAULT",
            "text": "The server did not find a current representation for the target resource."
        }
    ],
    "causes": []
}

There was also a reply in the thread that mentioned that this may possibly be a bug that causes a timing issue when adding Access Profiles to an application. However, I am still unable to add Access Profiles that were created a few days ago, so I am not sure if that is definitely the issue.

Kind regards,
Dorijan

11

At this point, I recommend you open a support ticket and reference this post in your ticket. I am unable to reproduce, but support can investigate your tenant more closely.

1 Like
12

Thank you for your response @colin_mckibben! It is really nice that it is possible! I did not expect that is was possible to patch this field because it is not a visible field on the object. Interestingly the PATCH API does show the list in the response. See screenshot

image
image1449Ă—388 29.6 KB

But then my follow up question will be. Why is this not a visible field in GET /v2024/source-apps/ and in GET /v2024/source-apps/:id

In general objects should be visible full (unless there is functionality to specify which fields to include/exclude). Some visible fields (Like created) should not be patchable, but all patchable values should be visible.

Right now if we want to get all access profiles in all applications, we can’t just list the applications and get them. We have to call a single API per application to get all of them, which means an explosion of API calls.

I think by REST API design, a response body of PATCH /objects/:id should be exactly the same as the response body of GET /objects/:id, when calling it slightly later. If I only patch the description, it will also show me the access profiles in the PATCH response. Perhaps it was forgotten to make this field visible in the GET single object and GET objects API?

Kind regards,
Angelo

1 Like