API Scopes Not Working Broken Feature

[mcheek (Mark Cheek)]

Just FYI, you’re likely going to get pushback from SailPoint calling it broken. The response would likely be that it’s “working as designed”

The requirements are that you have to use a PAT from a user with ORG_ADMIN rights, but I agree with you. I’ve mentioned it in multiple places that there needs to be more availability for application based API creds, because the current landscape requires we grant ORG_ADMIN to identities that only perform a single task.

I’ve run into an issue in this topic where I can’t update an account because the account is linked to the identity that’s being updated. This identity performs only create/update of accounts in a single delimited source, yet I have to assign it ORG_ADMIN

PUT /v3/accounts - 400 - Action cannot be performed

We have an RPA process that updates a CSV source using the create-account and put-account API endpoints. The user making an enhancement process is having an issue when calling the PUT endpoint, specifically when the identity PAT being used is the same identity that the account is linked to Notable that I can do it with my own PAT and the identity being used for this process is able to update other accounts, just not its “own” We’ve not seen this before… is there some documentation saying this …

I’ve mentioned in another topic why permissions for application api keys need to be expanded

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

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 per…

I’ve also mentioned how much of a pain it is to generate a PAT for a non human account

Generating a PAT through the API for another Identity

I assumed that was the case… please allow me to provide a bit of feedback on the steps I must go through for this process. Note that we create identities for (AD) Service Accounts because we utilize ServiceNow and the IDN API to request and provision access for these accounts. How I generate PATs for these accounts depends on whether or not I want to bypass SSO. If I am logging in using SSO If we are to log in using SSO for these accounts, we have to set up 2FA for that user in Okta. This …