REST API: Restrict table access

Christopher17 · ‎02-23-2021

I am trying to restrict an account (sn.ebond.dev) to REST API access to custom staging table called u_ebond_incident_staging. The table (u_ebond_incident_staging) created the necessary roles and I toggled the "Allow access to this table via web service" to ON and the tables are accessible to all application scopes. When records are added to the staging table, the rows transformed into an incident record on the incident table. The transform also reads and writes to the u_ebond_data_mapping and u_ebond_relationship tables as needed.

I have granted the account the following roles as the transform on the u_ebond_incident_staging table touches these tables:

sn_incident_read

sn_incident_write

u_ebond_incident_staging

u_ebond_data_mapping

u_ebond_relationship

Now as a security precaution I had to turn on (activate) the ACL "Table API" to restrict any access to the Table API unless explicitly granted. With this step all REST calls return with 403 and the reason is ACL restricted access. To get around this 403 error I have to grant the user account the role snc_platform_rest_api_access. BUT, once this role is granted the account, the account then has access to all tables. So I am not sure how to restrict an account to only the table it's allowed to write too.

Christopher17 · ‎02-23-2021

I'll have to look at this more carefully. I think my issue is not understanding the ACL "Table API" ("Table API" is the name of the actual ACL in ServiceNow, I'm not refering to it in the generic sense) and activating it. As soon as I do, all REST API access is removed even though the account has explicit rights to the table in question. It appears that "Table API" ACL is a blanket ACL over all tables. If set the role associated with "Table API" see this KB that mentions it directly. It's not a well documented ACL. https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0813159

It's not 100% clear.

View solution in original post

cynlink1 · ‎08-23-2022

Hi Christopher, I've encountered a similar situation. Our organization also turned on (activated) the ACL "Table API" to restrict any access to the Table API unless explicitly granted to web only integration user accounts. We've only granted a hand full of users the role 'snc_platform_rest_api_access' as needed. We are now working with a partner to configure a store app that uses the snReaderPicker in Widgets in their portal. The Reference fields are not working correctly for users without the snc_platform_rest_api_access role because of the Table API. They asked us to assign the snc_platform_rest_api_access to a large population of users which would defeat the intent behind activating the ACL on the Table API. Your post indicated that you may have misunderstood the Table API. I believe I am too. Did you end up having to deactivate the ACL on the Table API? Is it true that deactivating the Table API allows API access to all tables? Thanks!

Daniel Peel · ‎11-30-2023

We have this ACL turned off for that exact reason... it breaks access to portal widgets, like checkout, when it's on and users don't have the role... we've struggled with how we can let users have access to the TABLE API OOB... but not give them the keys to the kingdom... and we have yet to find a workable solution to solve for that. Been trying for years... We created our own APIs for this reason... replicating basic functionality in our own separate APIs for things like Incident so we can grant users access to submit those but not REQs etc. I would love a configurable way to let the OOB roles and api's work while being able to limit or adjust the scope of each account created.

I thought the REST API Access Policies, part/extension of Adaptive Auth, might work... but we can't do those per table... only on the REST resources/methods