Configuring ServiceNow instances
The following steps are used to configure your ServiceNow instance in order to connect to it from Quality Clouds.
1. Grant IP address access
For instances with IP restrictions, make sure you add exceptions for the following Quality Clouds IP addresses (in the IP Address Access Control in ServiceNow):
IP whitelisting
If your infrastructure implements IP whitelisting, make sure that you add these IPs to the allowed origins, so that requests from Quality Clouds are not blocked:
All servers located in: EU (Ireland)
20.82.159.225 → 20.123.120.23820.82.221.17 → 20.123.123.7020.93.80.6
Important Note - 19 October 2022.
Due to changes in our infrastructure, the IPs in our EU cluster have changed. Please replace the old IPs (grayed out) with the current ones in your whitelist.
On your network infrastructure level, make sure traffic is allowed from the IP.
2.- Decide on authentication mechanism
Quality Clouds supports two authentication mechanisms to connect to your ServiceNow instances through the REST API interface:
- Certificate-based authentication
- Basic Authentication
Quality Clouds recommends the use of Certificate-based authentication, since this is in general a more secure authentication mechanism. That being said, Basic Authentication, as implemented in Quality Clouds, mitigates some of the main disadvantages of Basic Authentication (secure password storage, poor password hygiene) and is a valid and secure way of configuring your connection. Selecting one or the other is up to your preferences and/or company policies.
If you opt to use Certificate-based authentication you will need to request the public side of the certificate from Quality Clouds support, and install it in your ServiceNow instance, as described in Defining ServiceNow instances.
Note that the considerations about connecting with an admin or non-admin user, and the requirement to configure the user identity for the connection with the snc_read_only role apply equally regardless of the authentication method chosen.
3.- Decide on admin vs non-admin access
Quality Clouds uses the REST API to connect to and scan the code and configuration of your ServiceNow instance. This means that a valid username / password must be configured in Quality Clouds in order for the scan to execute successfully.
The first decision to make is whether you will grant the admin role to the user which Quality Clouds will use to connect to your instance. Bear in mind that the snc_read_only role can (and should) also be assigned to this user, which makes all access read-only. Also, this user can be a Web-service-only user, so it will not be possible to log into the ServiceNow UI with that user.
If you are not comfortable with granting the admin role, it is also possible to use a Quality Clouds specific role. The creation of this role, and of the ACLs which grant read only access on the required tables to the role, are available as an Update Set which you can install in your instance.
In general, using a read-only admin user is the preferred option, as it allows customers to ignore the Delta Update Sets and automatically enjoy all the new functionality provided by Quality Clouds releases.
In order to help you make the decision which is right for you, the below table summarizes the key differences between each approach.
Admin user | Non-admin user | |
|---|---|---|
Configuration Frequency | One time only - Initial setup | Delta Update set needs to be applied whenever Quality Clouds includes additional tables to scan. Typically twice a year. |
Read-only visibility to | All tables | Only tables required by Quality Clouds. |
Quality Clouds rule coverage | Full | 99% - The Best Practices "Modules pointing to big tables without filters" and "Custom Tables with no records" can not be guaranteed to work unless additional roles are granted. The application field on all Roles detected by the scan will be shown as "Global". |
Application coverage | Full | ServiceNow scoped applications which are created upon plugin activation can not be identified. All their CEs will be assigned to the Global Scope. |
For admin user
If you decide to use a read-only admin user, simply enter the credentials for the user on the Instance Configuration page on the Quality Clouds scan web site, as described on the page Defining ServiceNow instances.
For non-admin user
If you decide to use a non-admin user, retrieve and apply relevant update sets, as described on Configuring for non-admin user.
For ServiceNow instances with encrypted data
Edge encryption does not affect Quality Clouds scans nor does it need any extra configuration.
For ServiceNow instances with SSO system
Make sure that the user to be launching scans in Quality Clouds uses local authentication and is able to use the REST API.
4. Configure the user
We recommend creating a dedicated user for setting up access and running scans from Quality Clouds.
Ensure that the user configured to run the scans has the following characteristics:
- is mapped to the Quality Clouds public certificate installed in your ServiceNow instance (if using certificate-based authentication)
use local authentication mode (if using Basic Authentication)
have read access to the following tables:
ServiceNow tables accessed by Quality Clouds
Following is the list of all tables accessed by Quality Clouds for each ServiceNow instance:
asmt_condition
catalog_script_client
catalog_ui_policy
catalog_ui_policy_action
item_option_new
item_option_new_set
sc_cat_item
sc_category
sc_cat_item_producer
sp_angular_provider
sp_widget
sys_app
sys_app_application
sys_app_category
sys_app_module
sys_data_policy2
sys_data_source
sys_db_object
sys_dictionary
sys_dictionary_override
sys_group_has_role
sys_package
sys_properties
sys_rest_message
sys_scope
sys_script
sys_script_client
sys_script_email
sys_script_include
sys_security_acl
sys_soap_message
sys_transform_map
sys_transform_script
sys_ui_action
sys_ui_element
sys_ui_form
sys_ui_policy
sys_ui_script
sys_ui_section
sys_ui_form_section
sys_ui_style
sys_update_set
sys_update_version
sys_update_xml
sys_upgrade_history
sys_user*
sys_user_has_role
sys_user_preference
sys_user_role
syscript_pattern
sysevent
sysevent_email_action
sysevent_in_email_action
sysevent_script_action
syslog_transaction
sysrule_escalate_am
v_index_creator
v_plugin
wf_workflow_version
wf_workflow
* The only fields accessed on sys_user table are: userid, active. No personal information is accessed.
4. (optionally) Enable collection of client-side performance data
Optionally, to enable the collection of client-side performance data, install and enable the ServiceNow Client Transaction Timings plugin.
If this plugin is not active, the client-side performance widgets in the Performance Dashboard will not be populated. For detailed instructions on how to do this, check the ServiceNow documentation article.