Start integrating with ONEiO for free!

Securely connecting ITSM tool with ONEiO


Extending your ITSM processes outside the boundaries of your organisation requires integrating with the service provider's ITSM system, for instance by using ONEiO. 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 ONEiO. It describes how to securely setup a reverse proxy on customer network so that ONEiO 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 ONEiO). 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 ONEiO 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 organisation, 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 ONEiO for insert and update operations and also a way to send changes to tickets to a predefined URL in ONEiO 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 ONEiO (firewall rule 1)

The ITSM tool connects with the ONEiO web service API using HTTPS. The connection is encrypted using a publicly signed certificate and usually authenticated with per-system logins (HTTP Basic, OAuth 2.0). All inbound traffic to ONEiO goes through one of the ONEiO static ingress IP addresses.

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

ONEiO 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 egress IP addresses of ONEiO outbound connections. It is also possible to use mutual certificate authentication by installing a client certificate to ONEiO.

Configuring your Reverse proxy

  • Publish the ITSM tool web API as an external HTTPS service, publicly accessible from the ONEiO 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 ONEiO to the ITSM tool.
  • ONEiO 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 an authentication protocol that utilizes HTTP headers (HTTP Basic, OAuth 2.0 etc.), the related header data needs to be passed through from ONEiO to the ITSM tool.

A brief Tasklist

  1. Firewall rule 1: Allow HTTPS from ITSM tool to ONEiO inbound static IPs (contact for details) where X marks the name of the adapter for the specific ITSM tool (for example: Jira)

  2. Publish the ITSM tool using a reverse proxy

  3. Firewall rule 2: Allow HTTPS from all ONEiO outbound static IP:s (contact 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 ONEiO and your organisation 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 ONEiO

HTTP-based integrations

ONEiO supports the following authentication methods for messages towards ONEiO:

  • HTTP Basic over TLS encrypted HTTPS connections
  • WS-Security message signing (only for SOAP messages)
  • OAuth 2.0 Client Credentials grant type

Other integration types

Please contact our Experience team at for more information.

Outbound to customer

HTTP-based integrations

ONEiO supports the following authentication methods towards customers

  • HTTP Basic
  • OAuth2 (several grant types supported: Resource owner, Client credentials, JWT Bearer token)
  • SSL certificate
  • form-based login
  • SOAP Username token (only for SOAP messages)
  • WS-Security message signing (only for SOAP messages)
  • LogicMonitor LMv1 API Token
  • Netvisor MAC

Other integration types

Please contact our Experience team at for more information.

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request



Please sign in to leave a comment.