Verj.io Gateway Server Overview

 

Documentation home

 

Introduction to the Gateway Server 1

Gateway Server Components and Facilities 1

Gateway Portal 1

Single Sign On to Intranet Active Directory. 2

Access to Intranet Databases 2

Gateway API 3

Gateway Server Configuration. 3

 

 

See Also: Gateway Server Configuration, Gateway Server RESTful Services, Gateway Portal, Gateway Programming API

 

Introduction to the Gateway Server

The purpose of the Gateway Server is to enable secure access to resources within a private intranet from a server running outside the intranet (a Remote Server) e.g. a Service Plan running in the Verj.io cloud. The Gateway Server provides:

 

 

The Gateway Server is a separately licensed Verj.io Server component. You can check whether your installation includes this component using the Server Administration Application.

 

Gateway Server Components and Facilities

Gateway Portal

The Gateway Portal is a Verj.io app (a form) that runs on the Gateway Server. It provides links to applications running on one or more Remote Servers – See Figure 1 below. The list of applications is configurable.

 

When the user first connects to the Gateway Portal they are authenticated locally using whatever authentication mechanism has been configured e.g. using Active Directory. The user is then presented with a configurable list of target applications (forms) available on the Remote Server(s). When they click on one of these links they are redirected to the Remote Server and their security credentials are passed in a secure authentication token.

 

See Gateway Portal

 

Single Sign On to Intranet Active Directory

 

The term Single Sign On (SSO) means that the user does not need to separately login to the Verj.io Server instance running on the Remote Server. Their security credentials on the local Gateway System are passed securely to the Remote Server thereby providing a silent authentication mechanism.

 

Users within the domain can connect initially to the Gateway Portal. When the user first connects they are authenticated locally. The user is then presented with a list of target applications (forms) available on the Remote Server(s). When they click on one of these links they are redirected to the Remote Server and their security credentials are passed in a secure authentication token.

 

There is a mutual trust relationship between the Gateway Server and the Remote Server based on a Gateway Server API key. This trust relationship can be further secured by specifying an IP Whitelist.

 

(Note that Single Sign On can also be configured using OpenID Connect to connect to Active Server Directory Services (ADFS) running within a private domain. This is an alternative option to The Gateway Server solution described here.)

 

Access to Intranet Databases

The Remote Server can access a local database within a private domain by calling a REST service running on the Gateway Server within the target domain. To achieve this, the Remote Server app uses the Gateway REST Javascript API which adds an authorization header to the request. This technique can also be used to access any other resources within the domain. These REST calls are secured using the Gateway Server API key in the same way as is used for SSO.

 

 

 

See Gateway REST Services

 

Gateway API

The Gateway Programming API is used by both of the previous sections (SSO and Database Access) and provides a secure mechanism for a Gateway Server to link to a Remote Server and vice versa. It’s divided into two sections:

 

 

 

See Gateway Programming_API.

Gateway Server Configuration

See Gateway Server Configuration for step by step instructions on configuring both Gateway Servers and Remote Servers.