User account or service account? What to use for web service tasks

[Dawn Jurek]

Sometimes, in the heat of our daily work battles, we defer to the easiest solution at our own peril. Take, for example, managing integrations, and other web service-centric tasks. It's quick and easy to just log in as an admin and get the job done. In this case, however, there's a better way and many reasons why you shouldn't use a personal user account for these activities. In this tenth installment of our best practices series, we take a closer look at using service accounts versus user accounts for web service administration.

What are service accounts and why should you use them?

Service accounts are user accounts set up specifically to provide credentials for integrations and other jobs. Here's why you should use service accounts instead of personal user accounts for web service activities:

• Restrict the account activities to application program interface (API) connections, such as JavaScript Object Notation (JSON), Simple Object Access Protocol (SOAP), and Web Service Definition Language (WSDL). Accounts flagged as Web service access only cannot log into the ServiceNow user interface to perform other actions.
• Increase security by conforming to the principle of least privilege.
• Facilitate management, troubleshooting, and debugging of your integration. If a personal user account is used for integrations, you can't easily distinguish the integration transactions of that user from other activities the user performs in the system. On the other hand, if a service account is used for each integration, you can easily tell which integration did what in the system. The service account name is identified under Created by or Updated by in the transaction log and also appears on the records that the integration touches.
  
• Ensure that everything done by a particular integration service account was related to that specific integration.
• Improve auditability. All transactions can easily be traced to specific service accounts in the system, which facilitates examination and verification of records related to each integration.

Web service administration best practices

Use service accounts instead of personal user accounts for web services.

When an external system makes a web service call to your ServiceNow instance, it must provide login credentials. Rather than using a normal user account to log in, it's best to use a service account specifically set up for that particular integration.

Setting up a service account

Follow these tips when setting up service accounts:

• Create a separate service account in the User table for each integration, and possibly one for each integration application.
• Make sure the User ID clearly indicates which integration the account is to be used for.
• Select the Web service access only check box, outlined here:

• Give the service account user any roles necessary to perform the actions that will be carried out by the integration. For example, in addition to the various SOAP- and REST-related roles, it may be necessary to grant process-oriented roles, such as itil, depending on the nature of the integration.
• Be aware of the glide.soap.strict_security property, which—when enabled—requires incoming SOAP requests to go through the security manager for table and field access, and checks SOAP users for the correct roles for using the web service. This is enabled by default. For more information, see High Security Settings properties and Strict security for web services.

--

Behind the scenes here at ServiceNow, the Knowledge Management and Multimedia teams work closely with subject matter experts to disseminate critical information to our customers. We've found that certain topics come up frequently, in the form of best practices that can help you keep your ServiceNow instances running smoothly. This series aims to target those topics so that you and your organization can benefit from our collective expertise. If you have a best practices topic you'd like us to cover in this series, please let us know in the comments below.

See Outsmart fickle networks, firewall changes, and down servers in your web services integration for the eighth installment on web services integrations.

To access all of the blog posts in this series, search for "nowsupport best practices series."