Clarification on ACL rules for Inbound Rest api

[User687957]

Dear all,

I need to build an Inbound Rest API in order to be able to update the short description of an incident.
For that I need to be sure at 100% that only a particular user will be able to hot that endpoint and beeing able to update the incident. I will need some clarification on the different place where ACL is mention as explain below . Thanks for your clarification on each question.
Please no need to send me the link of the documention because I go throuh it already and it is simply not clear to me

For that I have created first a kind of user account dedicated for Rest call with setting below :

Then I have added that user to a new rôle named "incident_api_update"

Then for the next step I have created my inbound REST APi as bellow :

As you can see from above , the base endpoint is set to "/api/iter/incident_update"
Then automtically the default ACLS as been set to "Scripted REST External Default"

Q1 : What is exaclty the purpose of the default ACL at this level and what it is protecting ?

The define resource for the endpoint has been done as below in the case of an Update
Ressource path : "/api/iter/incident_update/incident/{sys_id}"

Then from the REST endpoint resssource configuration there is 2 aspects which has been set as seen below, relative to security


Q2 : What is the effect of the ACL at this configuration stage vs the default we have seen at the Base path definition and do we need to place something ? For my case I did not place any ACL here but instead I have define the ACL at the role level show next

From the ACL configuration I have setup the following :


So the ACL is apply the the specify role where , the only define user is a member

Q3 : So compare to other place related to question 1 and 3 where there is a potential ACL to be define, what is then the difference of applying the ACL at the role level

Thanks for the clarification on this.
I understand it so that you can define the ACL at the root of the endpoint first and then having an other ACL at the ressource level for better granularity. I do not know if I made it and understand it correctly.

The goal is to be sure at 100% that no one except the autorise user can call the endpoint and make incident update through the PUT ressource

Thnaks for all
regards

[Ankur Bawiskar]

@User687957 

you can setup OAuth 2.0 with grant type as Client credentials and use API user of type Machine

Then you just need to share the API endpoint, client ID and client secret and no need to share userid and password

check below links for steps

Up Your OAuth2.0 Game: Inbound Client Credentials ... - ServiceNow Community

How to configure Client Credentials grant type for inbound OAuth - Support and Troubleshooting

💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏

[User687957]

hello @Ankur Bawiskar thanks for your reply but you are totaly out of the context of my questions . Read it carefuly . I simply ask 3 questions . I did not ask how to configure OAUth

[Hemanth M · Accepted solution]

Hi @User687957 ,

PFB answers:

Q1: Scripted REST External Default: By default this requires "snc_internal" accounts with the snc_internal role can access this endpoint.

Authorization and ACL settings details:

Q2: You need to set up a "REST_Endpoint" type ACL with the operation execute so that you can select this ACL under the Scripted REST API and its resources

Q3: You can define the ACL at the service level if you need it to apply to all resources. If you need specific ACLs for an individual resource, please apply them at the resource level.

Hope it helps!