Use Personal Access Token Failed

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

I am building my first workflow that will make an API call. I have followed the guidance provided by @kirby_fitch in hist tutorial Using Workflow’s HTTP Request Action to Work With IdentityNow APIs - Identity Security Cloud (ISC) / ISC Show and Tell - SailPoint Developer Community Forum, but when I test the workflow, the HTTP request call fails and I do not see how to get the failure code. When I search for the event it says:
Status: FAILED
Actor: System
Target:
Name: Use Personal Access Token Failed
cause: blocked
scope: [“idn:access-profile:read”,“idn:access-request-approvals:read”,“idn:access-request:read”,“idn:application:read”,“idn:entitlement:read”,“idn:requestable-objects:read”,“idn:role-unchecked:read”,“idn:tag:read”,“sp:scopes:all”,“sp:search:read”,“sp:workflow-execute:external”]

I have been adding scopes hoping that was the problem, until I finally added sp:scopes:all, but no dice.

The results shown in the workflow test is as follows:

{
  "authenticationType": "OAuth",
  "basicAuthPassword": null,
  "basicAuthUserName": null,
  "csvRequestBody": null,
  "formRequestBody": null,
  "headerAuthName": null,
  "headerAuthValue": null,
  "jsonRequestBody": null,
  "method": "get",
  "oAuthClientId": "**name changed to protect the innocent**",
  "oAuthClientSecret": "**removed**",
  "oAuthCredentialLocation": "oAuthInHeader",
  "oAuthScope": null,
  "oAuthTokenUrl": "https://sci.api.identitynow.com/oauth/token",
  "requestContentType": "json",
  "requestHeaders": null,
  "suppliedInlineExpression": {
    "url": "https://sci.api.identitynow.com/v3/tagged-objects/ENTITLEMENT/{{$.trigger.id}}"
  },
  "textRequestBody": null,
  "url": "https://sci.api.identitynow.com/v3/tagged-objects/ENTITLEMENT/a2bbefb4604847b6a694d4f41575af14",
  "urlParams": null
}

The URL appears to work in Postman, but Postman is using a different client id.
Any thoughts? Also, if I change the scope after the PAT is generated, does that alter the permissions, or will the PAT only ever have the permissions it had when it was generated?

2

Hello Briar,

Yes, if you change the scope after the PAT is generated, it will change the permissions in accordance with the new scope.

2 Likes
3

Hi @BCyr1,

A few things to confirm:

  • User level - Does the user for which the generated client ID and secret have the required admin level to execute the API call? Please confirm by referring to the User Level Matrix.
  • Client ID & Secret Pair - Could you confirm that the client ID and secret pair being used are the same in the workflow?

The scope for the token gets updated.

Let us know your results after the checklist has been verified.

4

Does the user for which the generated client ID and secret have the required admin level to execute the API call?

Yes. It is one of my PATs and I am an admin.

Could you confirm that the client ID and secret pair being used are the same in the workflow?
I am no pro at Postman, but I have two environments setup, one for production and one for sandbox. I cloned my production environment and then updated the clientId and clientSecret variables to match what I was using in the workflow. I then clicked on the “IdentityNow V3 API” collection and selected “Authorization” and got a new acess token.
So, I believe that the calls I am making in Postman are using the same credentials as the workflow is using, and they are successful.

5

Just a thought: We do have values in SystemSettings → Network Settings → Network Definition and Trusted Countries. Would those interfere with API calls or are those only used during logon?

6

Would those interfere with API calls or are those only used during logon?

I guess I answered my own question. I added the IP address that was mentioned in the failure event, and then re-tested the workflow and it worked. So when defining address blocks for your environment, we have to add in ranges for AWS I guess. I can see why you would not automatically do that, but I do not recall seeing in the documentation that said if you are going to set ranges, that you should account for the use of the API calls. Since ISC (still getting used to the new name) knows its configuration, maybe it should whitelist its own addresses if ranges are defined.

2 Likes
7

I would suggest looking into your Identity Profile settings.

You can disable Block Access From as such:

image
image864×324 2.87 KB

Hope this helps!

8

I am aware of those settings, and we have them enabled. We use SSO so they are not supposed to apply to regular users, but I am leaving them on because we have “breakglass” accounts for an emergency. Those are local so these restrictions do apply. Since these accounts are so highly privileged, I want to be sure they cannot be used from just anywhere. Nowhere in the API management page nor the Restricting IdentityNow Access - SailPoint Identity Services page does it say anything about these blocking API access. It makes sense that it would, but I really think that it should be mentioned in the documentation on the workflow/HTTP requests, API management, and restricting network access pages.
Thanks for the suggestion, though.

9

I agree, it doesn’t mention it in the documentation.

I did find some information here IP Address Allow List | SailPoint Developer Community.

10

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