- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-10-2017 05:41 AM
I've been reading the documentation around Web Services (both SOAP and REST) to get a better understanding of what permissions are required.
If I've understood the REST documentation, there is no ability to set permissions per-user when it comes to web services. i.e.
- Per user you can only say whether or not that account can use the REST services
- You can limit access to certain operations on certain tables; but this limitation applies to ALL users who have REST access.
This means that I can't have an account for a monitoring system which can raise incidents, and a different account for a reporting system which can read incidents, without also giving that reporting system permissions to raise incidents.
The SOAP documentation mentions something called Contextual Security, which seems to offer a per-user security model; though it's not so clear whether the roles apply to access for all tables, or if this is definable per-table, per-user.
I'm also a bit surprised that REST and SOAP would have different security models when essentially they're the same thing (i.e. web service access to SN data); just using different protocols...so think I may have misunderstood something here.
Ref: http://wiki.servicenow.com/index.php?title=Inbound_SOAP_Web_Service_Security#Web_Service_User_Roles
Question: Is it possible to define permissions per-user to specific operations on specific tables, so that I can have (as an example):
- one user/account who can read from incidents, users, groups, CIs, & incident comments.
- another account that can have the above read permissions, but can also write to the incidents table.
- a third account that can read from the users, groups, and CIs tables, and can write to the CIs table.
All of the above being with the context of either the SOAP or REST services (or both) rather than UI; and ensuring that those accounts have no more permissions that those specified (i.e. so the first account's requirement isn't considered met if it also gains write access to the incidents table in satisfying the requirements for the second account).
Suggestions:
- If the above's not possible, it would be good to implement it; i'm sure many companies have this requirement; especially as automation of processes & integrations are on the rise.
- If the above is possible, it would be good to improve the documentation to make this a lot clearer; as I've struggled to find the relevant info, and even then didn't fully comprehend what was being said.
NB: I'm not a service now administrator, but a developer hoping to gain access to these APIs. I've gained access to them in a test system, but the account I was given had full admin access; which is unacceptable in a production environment. I want to fully understand the security model so that I can present a solution to our ServiceNow administrators which shows how our various IT teams can satisfy business requirements around integration without compromising ServiceNow's security/integrity.
Solved! Go to Solution.
- Labels:
-
Integrations
-
Scripting and Coding
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-10-2017 05:54 AM
John,
ACLs are applied to web service queries as well. So you can restrict which data each of your "service" accounts. This is done by the roles assigned to that user. So for example, I have an application in my demo instance and I created a test user and gave that user the user role for that application and no other roles. When I used PostMan I could query the table for that application, however when I queried the incident table, I got a 403 User not authorized error.
So the documentation is not clear to your specific question. All tables by default are web services enabled, but that doesn't mean that a web services ID had access to every table. This just means you don't need to do anything to setup web services to your tables, you just need to create teh user accounts with the proper access to the tables.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-10-2017 05:54 AM
John,
ACLs are applied to web service queries as well. So you can restrict which data each of your "service" accounts. This is done by the roles assigned to that user. So for example, I have an application in my demo instance and I created a test user and gave that user the user role for that application and no other roles. When I used PostMan I could query the table for that application, however when I queried the incident table, I got a 403 User not authorized error.
So the documentation is not clear to your specific question. All tables by default are web services enabled, but that doesn't mean that a web services ID had access to every table. This just means you don't need to do anything to setup web services to your tables, you just need to create teh user accounts with the proper access to the tables.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-20-2020 05:38 AM
Check out this video, it will clear all your doubts and help you to understand Web Service Integration (REST Bi-Directional) queries in details.
Link: https://www.youtube.com/watch?v=RcUxIT4pooY&t=32s&ab_channel=ServiceNowHelpdesk
It help you to understand below points.
- Understand Web Service. Like when and how we will use it.
- Understand in details about Inbound and Outbound web service.
- Understand in details about Inbound Import set and Scripted Rest APIs.
- Outbound Rest Message.
- Set up Inbound and Outbound in ServiceNow Instance to see live data exchange. We will use Salesforce tool to consume the data.
- Troubleshooting
- Best way to Learn Web Services integration like (REST, SOAP)
- Integration: Rest API
- Scripted Web Services to Create/Update INC/CHG/REQ
- Automate a rest or soap integration
Please mark reply as Helpful/Correct, if applicable. Thanks!!