Introduction

Extending your ITSM processes outside the boundaries of your organization requires integrating with the service provider's ITSM system, for instance by using Service-Flow. In the case of many ITSM tools, bi-directional connectivity can be achieved using existing functionalities of the tools. However, establishing a secure bi-directional network connection that enables the connectivity typically requires changes to the network infrastructure in which the ITSM tool has been deployed.

This document aims to ease the process of securely connecting ITSM tool bi-directionally with Service-Flow. It describes how to securely setup a reverse proxy on customer network so that Service-Flow can access the customer ITSM tool through it. It also describes different authentication methods that are supported.

Network connectivity

Connection through a reverse proxy

A reverse proxy acts as a controlled gateway between internal and external network resources by publishing internal services (here your ITSM tool) to external users (here Service-Flow). By placing the reverse proxy in a DMZ, access to it can controlled and fine-tuned to match your requirements. Typically, access from the public internet is limited to HTTPS from Service-Flow while the service published is the HTTP API of the ITSM tool.

By using a reverse proxy, you retain full control of your network and security while gaining the additional benefit of using external services.

As setting up and maintaining a reverse proxy involves professionals in many parts of your organization, the target audience of this document is both administrators of the ITSM system to be connected as well as network administrators and security experts responsible of maintaining a secure network infrastructure.

Note that the documented configuration works only with ITSM tools that have an HTTP API that can be used by Service-Flow for insert and update operations and also a way to send changes to tickets to a predefined URL in Service-Flow HTTP API.

Network overview

The following network diagram illustrates the main components involved as well as the relevant configuration points. The ones that require changes within your network (reverse proxy and firewall rules) are described in below.

Outbound connections from ITSM tool to Service Flow (firewall rule 1)

The ITSM tool connects with the Service-Flow web service API using HTTPS. The connection is encrypted using a publicly signed certificate and usually authenticated with per-system logins (HTTP Basic). All inbound traffic to Service-Flow happens using one of the Service-Flow static IP addresses.

Inbound connections from Service Flow to the Reverse Proxy (firewall rule 2)

Service-Flow connects to the ITSM tool via the publicly available address published by the reverse proxy. For enhanced security, access to the published reverse proxy service can be limited to the static IP addresses of Service-Flow outbound connections.

Configuring your Reverse proxy

• Publish the ITSM tool web API as an external HTTPS service, publicly accessible from the Service-Flow outbound address.
  • The public address of the service must be publicly resolvable.
• If the ITSM tool API uses HTTP Basic authentication, ensure that HTTP basic header data is passed through from Service-Flow to the ITSM tool.
• Service-Flow can be configured to accept self-signed certificates, but using certificates signed by a well-known CA is recommended.
• The connection from the reverse proxy to the ITSM tool can usually be either HTTP or HTTPS, depending on the capabilities of the tool.
  • If using HTTPS, ensure that the reverse proxy accepts the ITSM tool certificate.

Inbound connections from Reverse Proxy to ITSM tool (firewall rule 3)

From the reverse proxy, the connection to the ITSM tool can be made using either HTTP or HTTPS, depending on the capabilities of the tool. Here, using plain-text HTTP allows data and protocol inspection for additional security.

Note that if the ITSM tool web API uses HTTP Basic authentication, the related header data needs to be passed through from Service-Flow to the ITSM tool.

A brief Tasklist

1. Firewall rule 1: Allow HTTPS from ITSM tool to Service-Flow inbound static IPs (contact experience@service-flow.com for details) where X marks the name of the adapter for the specific ITSM tool (for example: servicenow)

2. Publish the ITSM tool using a reverse proxy

3. Firewall rule 2: Allow HTTPS from all Service-Flow outbound static IP:s (contact experience@service-flow.com for details) to published reverse proxy service
4. Firewall rule 3: Allow HTTP(S) from reverse proxy to the ITSM tool
5. Test!

What about using a VPN?

How about using a site-to-site VPN connection between Service-Flow and your organization networks for secure connectivity? VPN is very useful for connecting your employees to the services in your internal network and also for connecting separate sites that you control, over the public internet. But for sending and receiving integration messages over HTTP protocol between fixed endpoints, VPN wouldn't offer additional security over the reverse proxy solution. Instead, it would make things much more complicated. There are several issues with VPNs:

• they are complicated to setup correctly and securely
• there are interoperability issues on the hardware and software implementing the needed protocols
• there are chances that the VPN tunnel problems cause downtime to integrations. These are also difficult to debug.

As the integrations predominantly use HTTP protocol, it's also much simpler to understand and limit the allowed traffic and ports with the reverse proxy solution than with the VPN, which usually allows all protocols. It's also more straightforward to handle certificates for the non-VPN solution as they can be generated for publicly resolvable DNS names. In the VPN scenario, as you would also want to use HTTPS, you end up having just internal network IP addresses for the servers and generating and signing certificates for those will need your own Certificate Authority and all the hassle of trusting these CAs on both ends.

Authentication options

Inbound to Service-Flow

HTTP-based integrations

Service-Flow supports the following authentication methods for messages towards Service-Flow:

• HTTP Basic over TLS encrypted HTTPS connections
• WS-Security message signing (only for SOAP messages)

Other integration types

Please contact our Experience team at experience@service-flow.com for more information.

Outbound to customer

HTTP-based integrations

Service-Flow supports the following authentication methods towards customers

• HTTP Basic
• OAuth2
• SSL certificate
• form-based login
• custom authentication endpoints
• SOAP Username token (only for SOAP messages)
• WS-Security message signing (only for SOAP messages)

Other integration types

Please contact our Experience team at experience@service-flow.com for more information.