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]

Hi @boston019 

I see that you marked your own reply as Accept Solution. If you don't mind, please review my replies above that I've taken time to provide. I believe they are not only helpful, but have possibly guided you with the ACL situation, from one perspective, that you mentioned in your own reply. You can mark more than one reply as Accept Solution as well, just to mention that.

I also called out the fact that the extended tables have their own ACLs and thus you'd be going into a rabbit hole trying to set all this up as you probably wanted.

Take care! 🙂

[Johns Marokky]

Hi @boston019 ,

if possible can you provide the screenshot of the roles of that user. Sometimes snc_internal must have added automatically for the user and that might have caused this problem and this snc_internal might have access to sys_user table.

Also check the sys_user table read acl, if there is any role attached to it.

Mark helpful if it helps in solving your query

Regards,

Johns

[boston019]

Sure thing!

User roles:

The sys_user table has a ton of controls on it. If I go to the ACL object I created, it says thousands of records match the condition.

[Johns Marokky]

Hi @boston019 ,

i think we are good with the user role.

So my doubt is that What is the role for the sys_user read ACL. At least in my PDI there seems to no role attached to it and it means that anyone will be having access to the user table.

sys_user and sys_user.* are the read acl's i can find in my PDI though. May be we need to change this ACL a little bit so that the sc_task_readonly roles wouldn't have access to user table.

Mark helpful if it helps in solving your query

Regards,

Johns

[boston019]

Yeah if I had to pick I'd say I'm less concerned with the user accessing other tables, and more concerned with why the user can't get to sc_tasks.

When I created the ACL I set it for sc_tasks.* , could that be why?