If your server is accessible over the Internet (ie. not behind a firewall or VPN), you don't need to do much: Unito will be able to connect to your server out of the box, just follow the instructions directly in our app. We also suggest that you read up on our HTTPS and custom port requirements or run our troubleshooting checklist.
If your server is locked down and inaccessible from the Internet, don't despair! You can still use Unito, but you'll need some extra configuration in your IT infrastructure. We've worked with many on-premise customers, large and small, to securely connect to their servers. Here is an overview of the most common approaches.
Open Firewall Ports
In this approach, you configure your firewall and/or routers to open a specific port and forward traffic to your internal JIRA or GitHub Enterprise server (often called port-forwarding). You can use any port number as long as it forwards to an HTTPS enabled port on your server; simply specify the port when you type in your server's address in the Unito app.
For maximum security, you can also specify which IP addresses can access your open port. Limit access to Unito's fixed IP addresses, as well as your own office IP address (so you can login to your server from the same address and port as Unito). If you cannot specify your own office IP address (because, for example, you have a dynamic IP), contact us and we'll setup a custom configuration for you.
Pros: This approach has the easiest setup for organizations with simple network infrastructures (e.g. with a single router). Also, administration is simple once the service is provisioned.
Cons: Opening ports in larger organizations can be a complex process involving multiple departments. Since this approach works at the network level (layer 3), there's no control over traffic contents (e.g. which API endpoints are called).
Reverse Proxy / API Gateway
Instead of exposing the application server itself, this approach uses another server/service that is reachable over the Internet (e.g. in the DMZ) and acts as a proxy or frontend to the JIRA or GitHub server. These are called reverse proxies, API Gateways or Application Gateways (we'll call them proxies here for short). Some examples solutions from Strong Loop, IBM, F5, Oracle, and good old NGINX.
Because this proxy sits both on the Internet and the internal network, it has full control over which API endpoints are available, as well as the contents of the message. These proxies are designed for public exposure on the Internet, and keep your internal server completely hidden away.
You can further secure access to the proxy by allowing access to only our IP addresses, by requesting our SSL client certificates, or by requiring custom HTTP headers. For these advanced configurations, we suggest you contact us, and we'll get you all setup in no time.
Pros: Very secure, very flexible with full control over communications.
Cons: Introduces a new software component (the proxy), which needs to be configured and managed.
On-Premise Agent (Tunneling)
A light weight "agent" software sits in you infrastructure behind the firewall and initiates communication with the Unito infrastructure, thereby avoiding firewall issues. The agent then maintains a bi-directional connection (or tunnel) using the HTTPS protocol. In this scenario, none of your services are exposed to the Internet.
As an agent, we recommend the use of the popular ngrok link. It supports end-to-end encryption and IP whitelisting, which provides a fully secured solution when limited to Unito's IP addresses (and your own office IPs). Here's a step-by-step guide to setup ngrok. Contact us if you'd rather avoid a third-party solution.
Pros: No need to open ports, expose an API, or touch the network infrastructure. Simple setup: light weight agent software can run directly on the JIRA or GitHub server, or in dedicated VM.
Cons: Separate software download, third-party solution.
The patterns above are some of the most commonly encountered ones for cloud to on-premise integration. Selecting the right pattern for your project involves looking at your internal processes, IT and network infrastructure and security restrictions. In some cases, simply opening a firewall port will do, whereas in others, an extensive API Gateway configuration may be well justified.
There are multiple other possible network configurations in use by on-premise customers. We're happy to discuss the right solution for you, just reach out. :)