Alternative to granting 'snc_patform_rest_api' role to user when using OOB sn-record-picker directive as a reference field

[cynlink1]

We are currently working with a partner to configure a store app to work in our instance. The scoped app's portal uses the OOTB sn-record-picker directive as a reference field for custom forms. This directive uses the TABLE API to retrieve the information and display the values to the user, in general the Table API uses the ACL's for authorization. My organization has limited the Table API "Execute" ACL to the snc_platform_rest_api_access role. In additional to activating the OOTB ACL, a previous developer created a custom Table API 'Execute' ACL to allow integration account(s) access to execute on specific tables. Basically, we have set up least privileged access to the tables used by each integration user. The solution the previous developer created is specific to 'integration' users and isn't one that we want to implement for users (customers) or groups of users (customers). 

The partner wants us to add the snc_platform_rest_api_access role, which is associated to the Table API 'Execute' ACL to multiple end-users (customers) so the OOTB sn-record-picker directive reference fields will work as expected. They state that right now even if the table level acl's are met, the users still require the snc_platform_rest_api_access role to execute the Table API's. This is currently impacting the snRecordPicker directive that is using table api's to retrieve data. Is there a workaround for this scenario that does not involve granting the snc_platform_rest_api_access role to the users? If the role MUST be assigned to the users, how do I limit those user's API access to ONLY the tables in the scoped app?

If it isn't obvious, I do not have much experience in this area. Any guidance would be appreciated.  

Thanks,

Cyn

[Tony Chatfield1 · Accepted solution]

Hi, without clear details of the custom configuration or specific reasons as to why it was implemented,
I don't think that the forum can provide a clear response to your question.

'snc_platform_rest_api_access' is an OOB role and a table API is a commonly utilized API,
if your organization has chosen to restrict functionality\access then they may have to either accept that they have limited options when it comes to utilizing externally developed functionality,
or that they need to review update\revert local customizations so that you can utilize external apps with development based on OOB structure\configuration.

[cynlink1]

Tony,

Thank you for responding to my post despite it lacking all of the details. I am working with Now Support to gain a better understanding of exactly how the Table API ACL (and 'snc_platform_rest_api_access' role) is configured to work in our unique instance. 

Cyn

[John Dewhurst]

I am working with a client that has this OOTB ACL turned on and as encountered here has also broken snRecordPicker.

I am going to find out the arguments for why they believe this needs to be turned on (and apparently ServiceNow advised there would be no impact which seems an odd claim)

Did they come back to you with a response to your query?

[cynlink1]

Q&As from my case:

1) What does the snc_platform_rest_api_access role empower a user to use APIs for any tables that they have access to via ACL?
Inbound REST API role snc_platform_rest_api_access Controls the ability to access the following services if the corresponding REST API ACL is activated for that
- Table API
- Attachment API
- Import Set API
- Aggregate API

Each platform REST API has an associated REST_Endpoint access control list (ACL) that is deactivated by default, but can be activated on a per API basis. If the REST_Endpoint ACL is activated for a platform REST API, the snc_platform_rest_api_access role is required to call the API.

- Table API is used to make inbound calls to the instance to fetch data from the instance
- The user who makes the API calls must have "snc_platform_rest_api_access" role. If user Noah Hager doesn't have this role, he can't make an API call (the server in this case replies with {"error":{"message":"User Not Authorized","detail":"Failed API level ACL Validation"},"status":"failure"})

Here is the list of ACLs for the APIs mentioned above:
/nav_to.do?uri=%2Fsys_security_acl_list.do%3Fsysparm_query%3DnameLIKETable%2520API%255EORnameLIKEAttachment%2520API%255EORnameLIKEImport%2520Set%2520API%255EORnameLIKEAggregate%2520API%26sysparm_first_row%3D1%26sysparm_view%3D


2) Does the sn-record-picker require the snc_platform_rest_api_access role to work properly? If no, what are our alternatives?
In general, snc_platform_rest_api_access is not required for sn-record-picker to work. In our scenario, however, the choice list is empty because the user is not authorized to execute API on the server side and server returned "User Not Authorized" error message". To grant user access to the table on the server, we need to give the user snc_platform_rest_api_access role.

In a separate case, I clarified the following: "If the user is SSO user, then the user cannot be used for sending inbound api call."

I hope this information helps in your scenario!