POST /api/v2/access-profiles

Identity Security Cloud (ISC) Non-Public API Deprecations
1

Replaced by

2

Hi Colin,

The v2 endpoint allows for us to update the source on an access profile, whereas the v3 API explicitly does not allow this.

This will break many of our workflows.

Regards,
Ramiro

3

Hi Ramiro,

Are you referring to the v3 PATCH access profile endpoint not allowing the source to be updated?

4

Hi Colin,

That’s correct:
The following fields are patchable: name , description , enabled , owner , requestable , accessRequestConfig , revokeRequestConfig , segments , entitlements , provisioningCriteria

We haven’t moved from v2 to v3 API yet because some of our workflows rely on being able to update the source of an access profile.

Regards,
Ramiro

5

I have opened this issue with the product team. To help keep track, I’ll drop the ticket number here: IDNLANAI-8369.

6

@Ramiro can you please describe your use case for updating the source for access profiles, as opposed to creating a new profile with the new source? It is by design that the v3 access profiles don’t allow updating the source due to side effects like having entitlements from multiple sources.

7

Hi Colin,

Two main use cases:

  1. Reworking access which is allocated to user’s everyday accounts to instead use privileged accounts - in our environment they are managed as different sources on the same identity.
  2. Implementation of temporary privilege escalation (TPE) process and replacing “standing permissions” with “requester groups” on our TPE source which allow for access to be escalated.

The reason creating a new access profile doesn’t work in this instance is because there are many things referencing the old access profile - roles, apps, or downstream systems (e.g., our ServiceNow request forms). Anything which references those existing access profiles needs to be updated across a number of different systems to ensure we don’t end up with orphan objects all over the place and access profiles disappearing from roles (or worse, roles keeping the access which is only ever supposed to be temporarily assigned). This turns a 2 minute automated job into a multi-hour manual slog.

8

@Ramiro , You can now update the entitlements of an access profile ONLY IF you update both the source and the entitlements in the same PATCH API call. If you attempt to update the source or the entitlements in separate PATCH calls, it will fail.

PATCH /v3/access-profiles/:id

[
    {
        "op": "replace",
        "path": "/source",
        "value": {
            "id": "2c9180887671ff8c01767b4671fb7d5e",
            "type": "SOURCE",
            "name": "Employees"
        }
    },
    {
        "op": "replace",
        "path": "/entitlements",
        "value": [
            {
                "id": "2c9180877677453d01767b4b08f63386",
                "type": "ENTITLEMENT",
                "name": "DevRel"
            }
        ]
    }
]
1 Like
9

Awesome Colin! We’ll give this a try ASAP and let you know if we have any issues.

10

We sometimes have to create 100’s of accessprofiles, and so we use the Sailpoint bulk role importer ( IdentityNow Bulk AccessProfile and Role Importer - Compass (sailpoint.com)).

Another usecase, Sometimes we might have fewer access profiles, but the accessprofiles have many entitlements (with some amount of overlap).

Long story short, that tool is very useful, and uses /v2/ apis including /v2/access-profiles.

please advise.

1 Like
12

This is an old thread. The Bulk tool was recently Significantly updated (late Feb 2024)

it no longer uses v2 apis, and now does more than it did before!!