Protecting ServiceNow with SGNL

Introduction

Protected Systems are applications, services, or infrastructure that you want to protect with SGNL. In this guide, we’ll describe how SGNL can add continuous and contextual access management to compliment the existing policies you have within ServiceNow.

With this integration, ServiceNow need not know about the policies, systems of record, or any of the data in SGNL - it simply needs to pass to SGNL:

  • Who/What is requesting the access (The Principal)
  • (Optional) What is attempting to be accessed (The Asset)
  • (Optional) What operation is being attempted on the asset (The Action)
  • An access token that ensures the Protected System is a legitimate caller into SGNL

Prerequisites

  • An existing ServiceNow instance
  • A SGNL Client
  • A SGNL User Account with Admin privileges
  • At least 1 system of record integrated to SGNL, containing principals and (optionally) assets that will be evaluated in access evaluations
  • (Optional) 1 or more policies that you want assigned to the integration

Creating a Protected System in SGNL

  1. Log-In to your SGNL Client with an Admin Account
  2. From the left navigation pane, select Protected Systems and Add, or simply click Add from the SGNL Dashboard
  3. Select ‘ServiceNow’ from the SaaS category in the list of integrations
  4. Give your integration a descriptive display name and description
  5. Specify the Default Policy to be applied to ServiceNow
    • Allow: If no policies provide a decision for an access request, SGNL will respond to the access request with an Allow decision
    • Deny: If no policies provide a decision for an access request, SGNL will respond to the access request with a Deny decision
  6. Next, you’ll need to configure which identifier ServiceNow is using to describe your user/principal
    • This may be an email address or Username that can be found in your IdP, or an EmployeeID in your HRIS system. This should be in the format of the Principal ID of the user that will request access to the Protected System.
    • e.g. If an Okta user will be requesting access to this Protected System, ServiceNow, the principal identifier should be the Okta email address.
  7. You’ll also need to define the types of Assets that you want protected inside of ServiceNow
    • This might be customer account data, cases, or field-level controls on these or other entities
  8. Once configured, click Continue to save your ServiceNow configuration and move on to other configuration steps

Configuring Authentication

  1. Authentication ensures that only authorized systems can make requests into SGNL, as well as verifying the identity of an integration in order to effectively evaluate Policies - to access Authentication settings, open your ServiceNow protected system and select the Authentication tab

    SGNL - Authentication

  2. Click Generate Token

  3. Give your token a descriptive name so that you know how it’s being used in the future and click to Generate Token

    SGNL - Generate Token

  4. On the next screen, copy the token - this will be used by ServiceNow to make access requests to SGNL using the SGNL Access Service API

    Note: The value of this token is not available again after this screen, so ensure you securely store it for steps later in this guide

    SGNL - Token

Integrating ServiceNow with SGNL

ServiceNow is the backbone of internal and customer support for many enterprise companies. As such, in the modern enterprise ServiceNow is frequently heavily customized, has unique workflows, and is tailored to support very specific parts of the organization.

SGNL provides out-of-box experiences to enrich ServiceNow access control with continuous and contextual decision making during login, attempts to view objects, as well as in update and delete operations.

To fully understand how SGNL can help with providing continuous access management in your ServiceNow environment, we recommend getting in touch with us.

As a particularly straightforward example, you can integrate SGNL directly with Business Rules inside of ServiceNow, to trigger whenever a principal performs any operation on a particular object type/category. In the example below, we’ll add SGNL’s continuous access evaluation when users attempt to update a Customer Account Object.

  1. ServiceNow supports the creation of reusable REST Message endpoints, which makes integrating with SGNL a breeze, create a new REST Message for the SGNL Access Service, specifying the default endpoint for your environment.
  2. Configure a single HTTP Method to make a POST request to the endpoint, and configure the content of the message to match the access service request schema SNOW - REST Message
  3. (Optional) ServiceNow provides terrific testing capabilities, so you can easily check your work by using the Variable Substitutions capability on the HTTP Method to start making test requests to SGNL, with the paramterized fields filled in with values you set.
  4. Once you’re happy with the REST Message configuration, move over to ServiceNow Business Rules and create a new rule
  5. We’re going to create a new rule for ServiceNow Accounts, that triggers before an Update operation occurs. SNOW - BR
  6. You’ll note we have a Filter condition to ensure that the Account Number isn’t null - we’re doing this as it’s the value that’s configured as the AssetID in SGNL, so it must have a value
  7. The brains of this integration come in the Business Rule Script, this gets the pertinent data from ServiceNow, packages the request to SGNL, and determines whether the principal should be able to perform the operation. We also set a simple condition to provide pre-validation, prior to running the script Condition: current.isValidRecord() && current.canWrite()
(function executeRule(current, previous /*null when async*/) {

	try { 
		// Retrieve the necessary details for the Access Request
        var email = gs.getUser().getEmail();
		var action = 'update';
		var assetId = current.number;
        // Select the appropriate REST Message and Method to call the Access Service
		var r = new sn_ws.RESTMessageV2('SGNL Access Service', 'Send Access Evaluation');
		r.setStringParameterNoEscape('principalId', email);
		r.setStringParameterNoEscape('assetId', assetId);
		r.setStringParameterNoEscape('action', action);
		var response = r.execute();
		// Evaluate the response to determine whether to allow the principal access
        var responseBody = response.getBody();
		var httpStatus = response.getStatusCode();
		var result = JSON.parse(responseBody);
		var resultString = JSON.stringify(result.decisions[0].decision);
		gs.info(resultString);
		if(resultString=='"Deny"') {
			current.setAbortAction(true);
		}
	}
	catch(ex) {
		var message = ex.message;
	}

})(current, previous);
  1. Save your script, and that’s it.

Once you’ve successfully associated the Business Rule, you’ll be able to see requests coming from ServiceNow into SGNL through the SGNL Logs. It’s likely that all decisions will either be Allow or Deny, based on the Default Decision you’ve selected for the ServiceNow Integration - if that’s the case, you’re ready to start assigning policies to be applied to Saleforce

Assigning Policies

  1. Once the Integration is created, you can start assigning versions of Policies to the integration - to get started, select Policies from the tabs in your newly created integration

    SGNL - Policies

  2. Select ‘Assign Policies’

  3. Select:

    • The Policies you want to apply to the integration with the check box
    • The version of the Policy you want applied

    SGNL - Select Policies

  4. Click Next once you have the Policies and Versions configured as is appropriate

  5. Select the Enforcement mode for the Policies you chose in the previous step

    • Simulated: Policy Versions that are being simulated will only log their access decision in the SGNL logs and will not impact the access decision that SGNL hands back to an integration. Simulated policies are useful for performing what-if analysis of new policy versions as well as debugging policy changes.

      Note: It’s considered best practice to start with policies in Simulated mode, to verify that policies have been created an applied as expected

    • Enforced: Policy Versions that are being enforced will impact the access decisions that SGNL hands back to an integration. Enforced Policies will determine access for an integration

    SGNL - Set Enforcement

  6. Select your desired Enforcement mode and select Assign

  7. Versions of Policies will now be Assigned to your integration

    SGNL - Policy Assignments