Scripted REST API Permissions

AmolJ · 3 weeks ago

I am on Zurich.

I have instance "A" and on this instance I have a user account marked as both "machine" and Internal Integration User. This user account is linked to a role which is linked to a REST API's "execute" ACL.

This ACL is linked to a scripted REST API with 2 resources. One of the resources is a POST resource used by another ServiceNow instance (instance B) to create incidents into this instance.

Neither this user through a directly assigned role, nor through a role contained by the ACL role can this user create incidents.

Yet when from instance B I post, it creates incident on instance A.

I have used GlideRecordSecure on instance A in the POST resource.

Any hints?

AmolJ · 2 weeks ago

The only way I could stop it is by creating another custom role and scripting it in the POST resource script to check if the user has this role or not. This role is not associated with Incident table through ACL. It's just sitting there on its own and this machine account is associated with this role. That's the whole setup now.

The default Deny-Unless ACL and Allow-If (can open your own incidents) ACL allowed this account to have write permissions even though I didn't specifically give it this permission.

Hence GlideRecordSecure() wasn't really helpful as these two ACLs were passing in the Access Analyzer.

ServiceNow needs to give us some other solid way to handle this.

View solution in original post

Tanushree Maiti · 3 weeks ago

Hi @AmolJ

Probable troubleshooting steps:

1. For Instance A, Calling setWorkflow(false) before inserting an record skips all Business Rules, including logic that enforces table-level and field-level ACL.

When queries are run from scripts, GlideRecordSecure applies ACL checks to control access to records.

Ref: https://www.servicenow.com/community/developer-forum/run-glide-query-as-different-user/m-p/1676335

2. Scripted REST APIs execute in the context of the user authenticated in the header. Ensure that the integration user's credentials used by Instance B are actually the ones being authenticated on Instance A.

Use serviceNow System Logs to verify exactly which user account is triggering the incident creation.

3. Check if the specific Incident Table ACLs have the Admin overrides box checked

Please Accept the solution if it assisted you with your question & Mark this response as Helpful.
Regards
Tanushree Maiti
ServiceNow Technical Architect
LinkedIn: https://www.linkedin.com/in/tanushreemaiti

AmolJ · 3 weeks ago

Hi @Tanushree Maiti ,

These are quite good points. I will look at them one by one and accept your response as solution once I finalise the analysis.
Thanks !

AmolJ · 3 weeks ago

Could you explain this part as I don't know where to add the user credentials on instance B:

2. Scripted REST APIs execute in the context of the user authenticated in the header. Ensure that the integration user's credentials used by Instance B are actually the ones being authenticated on Instance A.

Ankith Sharma · 3 weeks ago

Hi @AmolJ

One thing I'm curious about: does the POST resource perform a direct insert() on the Incident table?

While GlideRecordSecure enforces ACLs for queries and record access, it's worth understanding whether the record creation is happening through a direct server-side insert in the Scripted REST API. That could help explain why incidents are being created even though the integration user does not appear to have Incident create permissions.

Could you share a simplified version of the resource script ?

Regards,
Ankit