PUT /v3/accounts Requires ORG_ADMIN token... is this new?

Identity Security Cloud (ISC) ISC Discussion and Questions
, ,
1

I had previously been able to update accounts using the put-account API endpoint with application creds and the idn:accounts:manage scope, but it seems I’m no longer able to do so. I have previously asked the DEVREL team is there is some sort of changelog with these API endpoints to confirm or correct whether or not this is the case or if I’m mistaken.

I’d like to avoid if possible setting another identity as ORG_ADMIN, even if it’s just a service account.

Sample request
PUT /v3/accounts/fbcb9917d63e4216b9c91ea5129197e3

{
  "attributes": {
            "sourceId": "6e0341d6d14945c09d62efdb3153465e",
            "e-mail": "[email protected]",
            "groups": [
                "Chesapeake Operating/System Administration/Member",
                "Chesapeake Operating/Historical Invoices/Member"
            ]
        }
}

Sample response

{
    "detailCode": "400.1 Bad request content",
    "trackingId": "8191af444ecb4904a6b74c280b77685b",
    "messages": [
        {
            "locale": "und",
            "localeOrigin": "REQUEST",
            "text": "Action cannot be performed on fbcb9917d63e4216b9c91ea5129197e3."
        },
        {
            "locale": "en-US",
            "localeOrigin": "DEFAULT",
            "text": "Action cannot be performed on fbcb9917d63e4216b9c91ea5129197e3."
        }
    ],
    "causes": []
}
2 Likes
2

Hi @mcheek, did you find anything more on this issue.

3

No, I ended up having a PAT generated for that account and granting it ORG_ADMIN

4

I am running into the same issue. I’m trying to have a service account use an API Management token (NOT a PAT) to read only certain endpoints (like GET /beta/connector-rules) and it does not work, even when the scope is correct, because it does not have ORG_ADMIN perms. We don’t want every read-only service account to have ORG_ADMIN perms… is there any workaround? @colin_mckibben

5

If an endpoint specifies in the description that it needs “a token with XXXXX”, then you must use a PAT or OAuth token from an org admin. However, the PAT or OAuth token you generate for that org admin can be scoped to only allow certain endpoints as opposed to all endpoints. This is discussed in-depth in Authorization | SailPoint Developer Community.

For example, to create a PAT from an org admin that can only get information about connector rules, you would only assign the scope idn:rule-management-connector:read to the token. That token will only be able to read connector rules; it will not be able to perform any other action, like create sources or reset passwords.

6

Yes, one can certainly scope the permissions of API credentials to follow least privilege, but you cannot descope an account’s access when logging in interactively, and I think that’s the crux of our issue here.

In my observations, there is a lack of (meaningful) API endpoints in IdN that allow for ApplicationOnlyAuth. There are many use cases we have where a single team or account might need to perform a single operation, but in order to do that, we have to grant their account ORG_ADMIN to perform that operation. There are other vendors/platforms that are more permissive with their application-only API authorization, Microsoft being one of them.

Just look at the permissions required for the Entra ID connector. All but one of them are application API permissions.

Our auditors are not IT people, and they do not understand the intricacies of an authorization system, so we get questioned a lot whenever we provision all these accounts such broad access within IdN.

1 Like
7

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