SSOGEN Gateway, an authenticating reverse proxy

The SSOGEN Gateway is an authenticating reverse proxy that you install inside your own network. Before it passes a request to an internal website, it checks that the person is signed in to SSOGEN and that SSOGEN allows them in, so the application needs no change. The same program also reaches servers you administer and your corporate directory, which SSOGEN cannot reach by itself. It has four features, and the Gateway can also sit in front of AI agent traffic (see the MCP Gateway). You turn on only the ones you need.

This guide explains each feature in plain terms, what is available today, and where to go next. The examples use the fictional company Acme Corp (domain acme.example).

The four features of the gateway

Feature	What it does	Typical example at Acme	Guide
App Proxy	Puts SSOGEN sign-in in front of a web application that cannot host a Web Agent. The application stays where it is and does not change.	The finance application at `https://finance.internal.acme.example`	Publish an internal app through the App Proxy
Remote Access	Opens a terminal (SSH) or a desktop (RDP, VNC) on a server in the person’s browser, with approvals, file transfer rules and an audit trail. It runs inside the App Proxy feature.	An administrator opens `build01.acme.example` from the browser	Remote Access
Outbound Connector	Reaches web applications and SSH, RDP or VNC hosts in a private network that the Gateway cannot reach, through a small program in that network that dials out. No inbound port is opened.	A factory network at `plant.internal.acme.example`	Outbound Connector for private networks
Directory Connector	Lets SSOGEN ask your Active Directory or LDAP server questions from inside your network.	The Acme domain controller `dc1.acme.example`	Directory Connector

App Proxy

A person asks for an internal address such as https://finance.internal.acme.example. The App Proxy checks that they are signed in to SSOGEN and that SSOGEN allows them in. If not, it sends them to the SSOGEN sign-in page and brings them back. When the decision is “yes” it passes the request to the application’s back-end servers and tells the application who the person is, in a way the browser cannot forge. The App Proxy can also sign the person in to the application itself: with a shared account on a login form, or with Kerberos for Windows applications (Sign people in to the back-end application). It can spread requests over several back-end servers, check their health, keep a person on the same server, and serve several host names with their own certificates, internal and external, optionally behind your load balancer.

Remote Access

Remote Access gives people a terminal or desktop in the browser, without a VPN or client software. SSOGEN can keep the account for a host and sign people in with it, and an administrator decides which host to trust. SSOGEN does not give people access to your network. It gives them access to individual servers that you list, with the rules you set: who may connect, whether an approval is needed, which clipboard and file-transfer abilities are on, and how long a session may last. Sessions are recorded as events in the audit log. See Remote Access.

Outbound Connector

Some applications and servers sit in a network the Gateway cannot connect to. You install an Outbound Connector inside that network. It dials out to your Gateway and keeps the connection open, so you open no inbound port. An App Proxy route or a Remote Access resource then chooses Reach through the connector. See Outbound Connector for private networks. A Gateway can also be reached from the internet through a relay it dials out to, with its certificates ordered automatically: Reach a Gateway through a relay.

Directory Connector

When your directory is inside your network, the gateway asks it fixed, typed questions on SSOGEN’s behalf: find a user, read their groups, check whether the account is enabled, and (only if you allow it) check a password. It always uses an encrypted connection (LDAPS) and checks the directory’s certificate. The Directory Connector screen can test a connection before you save it. Sign-in does not use the Directory Connector yet, so people in a directory only the gateway can reach cannot sign in with its password. See Directory Connector for what is available today.

What SSOGEN Gateway is not

It is not a VPN, an open web proxy or a way to forward any network port. It only delivers what the signed configuration from SSOGEN lists: the exact host names, back-end servers, remote hosts and directory connections you configured in the Admin Console. When the gateway cannot make a sign-in decision, it refuses the request instead of letting it through.

How the gateway is installed, configured and trusted

You install it on a server in your network (Install and enroll an SSOGEN Gateway) and enroll it once with a token you create in the Admin Console. Enrollment gives the gateway its own identity certificate from SSOGEN.
You configure it in the Admin Console, under Secure access: App Proxy routes, App Proxy certificates, Remote Access, Outbound Connector, Directory Connector and Gateways. Your settings are published to the gateway group as signed configuration. The gateway checks the signature before it uses anything, and keeps the previous configuration so it can go back.
The gateway calls SSOGEN to fetch configuration, to report its health and events, and to ask for the sign-in decision. SSOGEN does not need to reach into your network for these, with one exception: the Directory Connector listens for SSOGEN’s directory questions. Remote sessions also reach the gateway from the person’s browser, at the Remote access origin you set. An Outbound Connector in a private network also dials out to the Gateway’s tunnel port; it opens no inbound port.
A feature runs only when three things agree: the local file on the server allows it, the gateway’s identity certificate carries it, and the signed configuration turns it on. So a mistake in one place cannot silently turn on something you did not intend.

An SSOGEN Gateway declares where it lives with networkZone: dmz, internal or identity. An SSOGEN Gateway in the dmz may run the App Proxy only. Run the Directory Connector on an internal SSOGEN Gateway.

Several gateways that share a configuration form a gateway group. The Gateways screen shows every group, every server in it, its health, the configuration revision it runs, and anything it could not apply.

Requirements and limits before you install

Keep gateways current. Upgrade SSOGEN first, then the gateways. Several App Proxy features (listeners, certificates per host name, sticky sessions) and the Test of the Directory Connector need an up-to-date gateway on every server of the group. The console tells you when one is too old.
Who can do what. Issuing enrollment tokens and saving routes, certificates, listeners and host names needs a super administrator.
Where it runs. Enterprise Linux 9 or newer on x86-64 with systemd, installed from the Edge archive with its installer.
Ports. The SSOGEN Gateway cannot listen on a port below 1024 (it listens on 9943 by default). Present port 443 to people with your firewall or load balancer.

Which guide next

I want to…	Read
Install my first SSOGEN Gateway	Install and enroll an SSOGEN Gateway
Publish an internal website, with certificates, internal and external names, and a load balancer	Publish an internal app through the App Proxy
Make an application sign people in with a login form or Kerberos	Sign people in to the back-end application
Give people SSH, RDP or VNC in the browser	Remote Access
Reach an application or host in a network the Gateway cannot reach	Outbound Connector for private networks
Put a Gateway that has no inbound access behind a relay, with automatic certificates	Reach a Gateway through a relay
Use my Active Directory through SSOGEN	Directory Connector
Find out why something is not working	Troubleshooting the gateway