How to restrict an API user to read one table only?

[boston019]

Hi,

I have a user who needs to send Get requests to one table. They don't need access to any other tables, and I don't want them to have access to any other tables. I still need other users to have their access to that table as normal.

I have:

Elevated to Security Admin
Created the user

Created a role

Joined the user to that role

I don't where to go from here. Haven't had much luck with Google on this matter because it's an unusual question with common words.

[Allen Andreas · Accepted solution]

Hi,

ServiceNow operates in a default deny permission. This means that if the user didn't have access elsewhere, they wouldn't see 'x' data. So if they can see data, then it means they have access given to them by another ACL. Keep in mind that there's table level ACLs and then table.* ACLs (field level). You'd have to evaluate all other ACLs elsewhere to ensure they can't see other data and then evaluate your "read" ACLs for the given table to ensure they can not only see the table...but then the fields.

For your example of the sys_user, you'd check your "read" ACLs there, most likely you'll see that they qualify to access and if you removed that, on the sc_task records for assigned_to, etc., they wouldn't see any data referenced there (you may be ok with this).

For the sc_task GET 200 but with an empty data set, as mentioned above, review your "read" ACLs for table.field as well as those could be behind additional ACL layers that you need to then give access to such as. Another thing to mention is that sc_task is the parent table, but if Incident (extended from task) has it's own ACLs, those will override the parent table level. So you may need to assess this at the individual task extended ACL level instead.

[Allen Andreas · Accepted solution]

Hi,

Additionally, I see you're providing more information in your reply chain below, but I think it's still missing the target. Please review my reply above and to answer what you just said...you said you create a "read" ACL on sc_task for sc_task.* ...the .* is for the fields, not the table itself.

But again, keep in mind that tables that extend from sc_task...have their own ACLs. Those ACLs override any parent level ACLs, but you can try initially with a table and table.* "read" ACL for sc_task and see where it goes.

[Allen Andreas]

Hello,

You would then add a "read" ACL to the table in question and add that role to the ACL config settings.

[boston019]

Hi Allen,

Thanks for your reply.

I just did that. I'm seeing the opposite effect of what would be desired.

The table in question is sc_task . So I created a role called "sc_task_readonly", and joined the user to that role. The user has no other roles/groups.

The user is able to perform GET requests to the sys_user table for other users (which I don't want them having access to any other tables besides sc_task),. When they send a GET to sc_task, they get a 200 but it's an empty data set. When I run the same query with my creds, I get data back, so there's definitely data to be had.

[Allen Andreas · Accepted solution]

Hi,

ServiceNow operates in a default deny permission. This means that if the user didn't have access elsewhere, they wouldn't see 'x' data. So if they can see data, then it means they have access given to them by another ACL. Keep in mind that there's table level ACLs and then table.* ACLs (field level). You'd have to evaluate all other ACLs elsewhere to ensure they can't see other data and then evaluate your "read" ACLs for the given table to ensure they can not only see the table...but then the fields.

For your example of the sys_user, you'd check your "read" ACLs there, most likely you'll see that they qualify to access and if you removed that, on the sc_task records for assigned_to, etc., they wouldn't see any data referenced there (you may be ok with this).

For the sc_task GET 200 but with an empty data set, as mentioned above, review your "read" ACLs for table.field as well as those could be behind additional ACL layers that you need to then give access to such as. Another thing to mention is that sc_task is the parent table, but if Incident (extended from task) has it's own ACLs, those will override the parent table level. So you may need to assess this at the individual task extended ACL level instead.

[Allen Andreas · Accepted solution]

Hi,

Additionally, I see you're providing more information in your reply chain below, but I think it's still missing the target. Please review my reply above and to answer what you just said...you said you create a "read" ACL on sc_task for sc_task.* ...the .* is for the fields, not the table itself.

But again, keep in mind that tables that extend from sc_task...have their own ACLs. Those ACLs override any parent level ACLs, but you can try initially with a table and table.* "read" ACL for sc_task and see where it goes.