Reference this closed issue that is not resolved. I would reply there but topics get auto-closed.
The API Scopes don’t work. Specifically, let’s talk about listing access requests pending approvals. API Docs list-pending-approvals | SailPoint Developer Community mention ORG_ADMIN while the API Scopes are available to issue but don’t work. It’s not desirable for obvious reasons to grant ORG_ADMIN to do basic API functions.
{
"detailCode": "403 Forbidden",
"trackingId": "162201505c0c4cf6a740860000cfd95a",
"messages": [
{
"locale": "en-US",
"localeOrigin": "DEFAULT",
"text": "The server understood the request but refuses to authorize it."
},
{
"locale": "und",
"localeOrigin": "REQUEST",
"text": "The server understood the request but refuses to authorize it."
}
],
"causes": []
}
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
I’ve mentioned in another topic why permissions for application api keys need to be expanded
I’ve also mentioned how much of a pain it is to generate a PAT for a non human account
I hear you but I am just calling out it is broken. The API scope says it gives permission and then you hit the related endpoint and it fails to work. The API scope modal window is providing scopes that don’t work so it’s a broken feature.
I am also bitter because I need to give integrations full admin to function instead of least privs or look at putting a proxy endpoint between IDN and the service to do the calls I expect on behalf of the service downstream.
Scopes are intended to scope down access on PATs to create tokens with the least privilege necessary to fulfill their functions:
The vast majority of ISC APIs require ORG_ADMIN user level, and that user level context can be provided by a PAT with the client credentials grant flow or by a user actively logging in with the authorization code grant flow when generating a token.
We understand the frustration with this requirement, and we hear the feedback loud and clear to provide application based API credentials with greater capabilities.
You have this feature already you don’t need PATs to do search endpoint and other calls. There is a concept called API Management and in there, you generate creds and issue scopes.
This thread is calling out that you have a feature in production that is broken where not all scopes deliver the access they describe.
I can see how the ability to set scopes in the API Management UI implies that that was all that was required.
API credentials can be used to generate tokens with the client credentials grant flow, and those tokens can be used to call some APIs. But without any user level context, there are many APIs that will return a 403 unauthorized response because they require a combination of the appropriate user level plus scope. Our API documentation will note if an API requires a specific user level context.
We hear the feedback that this is frustrating and there is a desire for API credentials alone without user context to work for all APIs.
@christina_gagnon is there some sort of documentation that lists the API endpoints and whether they support UserContextAuth, ApplicationOnlyAuth, or both (thinking like a table with columns and checkmarks under each auth type)? I’ve done a little clicking around and I haven’t found one yet that lists ApplicationOnlyAuth as being available.
That might help cut down on the amount of topics related to this if users have something they can quickly reference and find out what sort of auth is support on the endpoint(s) someone wants to use.
@mcheek currently you have to look at the spec for each API to see if it supports UserContextAuth, ApplicationOnlyAuth, or both. If it lists a required UserContextAuth, then it requires it. Otherwise, ApplicationOnlyAuth should work.
Admittedly, that is not the most user-friendly way to reference this information.
You’ve got a great idea for improving the docs, and I think the team should take a look at the feasibility.
This feature is broken, if the scopes can’t be used by API Management it should not be available for selection until you resolve the access constraints.
Scopes can be used within API management, they’re just not available on the API endpoints you’re wanting, and I get that’s frustrating.
If you want to see a working example, create a new API Management entry with idn:accounts:read or add that to an existing entry and make a call to the list-accounts API endpoint. You should get a successful response. If you try to make a call to search-post without sp:search:read, it won’t work.
Now, is it very easy to figure out which API endpoints support ApplicationOnlyAuth and which ones don’t? No, and Christina has acknowledged that
I think she’s also demonstrated a clear understanding of what’s being asked, and as developer advocates, it’s their job to give more visibility to something as detailed as this. It takes time for these improvements to be rolled out.
