A user with soap role has access to all the tables. How to restrict that user to only one table? is it possible with REST?

Go to solution
pkmithun
Kilo Contributor

‎03-14-2017 12:50 AM

A user with soap role has access to all the tables. How to restrict that user to only one table? is it possible with REST? - with ACL user access can be restricted to one table. however, user may have access to other tables.

Labels:
0 Helpfuls
  • 6,028 Views
1 ACCEPTED SOLUTION

Go to solution
Alikutty A
Tera Sage
In response to pkmithun

‎03-15-2017 12:46 AM

Hi Mithun,



Yes it does, When you setup ACL's you don't have to provide the rest_service role and it guarantees that access is only provided to scripted REST API and the user cannot access other web services.



Here is a sample ACL



rest_api.jpg



You should tag the new_rest_role to a group or user and the Rest_Endpoint ACL in your REST API. This ensures that users with new_rest_role only have access to the specific API.



Thanks


Please Hit like, Helpful or Correct depending on the impact of the response


View solution in original post

Preview file
57 KB
11 REPLIES 11

Go to solution
Alikutty A
Tera Sage
In response to pkmithun

‎03-15-2017 04:58 AM

Yes that's true, Scripted Rest Services was introduced in Helsinki and the ACL's are best part of it.



Thanks


Please Hit like, Helpful or Correct depending on the impact of the response


Go to solution
chris_f
Kilo Expert

‎06-09-2017 10:22 AM

Hi,



I tested this on my personal dev instance (Istanbul) as I was concerned too.



I found that, a user with SOAP_QUERY and SOAP_CREATE is restricted in line with ACLs because the following settings are on by default:


1) High security   - So deny by default, unless ACL allows explicitly http://wiki.servicenow.com/index.php?title=High_Security_Settings#Default_Deny_Property


2) SOAP configured to respect ACLS, on by default for new instances - Inbound SOAP Web Service Security - ServiceNow Wiki  



Of course, old instances may not have the above 2 features enabled, so they should investigate such and look to activate where feasible.



one exception: incident table is open to unrolled users, by default


When inserting, to incident for example, with Out of the box default settings, it allowed the user to insert a record (since incident table allows a user, with basic authentication e.g. An unrolled account) .


The same is true regardless of any soap role. if you simple create a user, with no roles, then navigate to incident_list.do in the nav pane. You will be able to click NEW and create an incident for that user.




But for tables such as


CHANGE_REQUEST


SC_TASK


SC_REQUEST



That was not the case. SOAP UI returns:



<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">


    <SOAP-ENV:Header/>


    <SOAP-ENV:Body>


          <SOAP-ENV:Fault>


                <faultcode>SOAP-ENV:Server</faultcode>


                <faultstring>com.glide.processors.soap.SOAPProcessingException: Insufficient rights for creating new records</faultstring>


                <detail>com.glide.processors.soap.SOAPProcessingException: Insufficient rights for creating new records</detail>


          </SOAP-ENV:Fault>


    </SOAP-ENV:Body>


</SOAP-ENV:Envelope>





and a user navigating there is locked out "row removed by security" when viewing list.




So in summary, SOAP can be configured nicely to respect ACLs too.



So soap is the first door.


Then ACLs are the second door.



(don't forget the table must have Web service integration ticked too, so that's another door)


(oh and the WSDL may not be available to unauthenticated users either, so that's another door).



Overall pretty secure