Version compatibility and SSO requirements

SSOGEN is delivered as four parts with their own version numbers: SSOGEN itself (the server), the Gateway, the Web Agent and the SSOGEN Authenticator app. The current versions below are released together. A newer SSOGEN keeps working with the Gateways and Web Agents you already run, so you upgrade SSOGEN first and the other parts afterwards.

1. The current versions

Part	Current version	Delivered as
SSOGEN server	4.4	The server archive
Gateway, with the Outbound Connector and Directory Connector roles	4.4	The Gateway archive for Linux
Web Agent modules for Apache 2.2 and Apache 2.4	4.1.7	Inside the integration packages
Integration packages (`apache`, `ohs`, `ebs121`, `ebs122`, `peoplesoft`, `jde`)	4.1.7.1	One package per product
SSOGEN Authenticator for iPhone and Android	1.1.8	The app

Each archive comes with a .sha256 file. Check it before you unpack, as Install and first run shows.

How the numbers relate

SSOGEN and the Gateway share the release number. Run a 4.4 Gateway with SSOGEN 4.4.
The Web Agent modules and the integration packages share their first three numbers. A fourth number, as in 4.1.7.1, is a change to the package’s install script only: the modules inside are still 4.1.7.
The Authenticator has its own numbering and is updated through the phone’s app store.
Two different builds never carry the same version number.

Which version is running

Part	Where to look
SSOGEN	The bottom of the console’s Overview, for example `SSOGEN 4.4 · build … · build ID …`. On the server: `/opt/ssogen/bin/ssogen-platform --version`, or the first line of the log after a start.
Gateway	The Gateways page in the console shows Version under each instance. On the server: `ssogen-edge-diagnostics --version`.
Web Agent	The line the module writes to the Apache error log at start. It also names the versions of its built-in libraries.

Quote the version and the build ID when you contact support.

2. What SSOGEN needs

Requirement	Supported
Operating system	Red Hat Enterprise Linux, Oracle Linux, Rocky Linux, AlmaLinux and CentOS Stream, versions 8, 9 and 10, on x86_64
Java	Java 21. No other version is supported.
Database	PostgreSQL 15 or later
Also	systemd, root access for the installation, and a clock kept by NTP

The installer refuses Fedora, Amazon Linux, Debian and Ubuntu. It installs Java 21 from the operating system’s repositories when it is missing. For the database, it installs the newest PostgreSQL the operating system offers out of versions 17, 16 and 15, or uses an empty database you give it. It never upgrades a PostgreSQL server that already exists.

3. What the Gateway needs

Requirement	Supported
Operating system	Enterprise Linux 9 or newer (Red Hat Enterprise Linux, Rocky Linux, AlmaLinux, Oracle Linux) on x86_64
Not supported	Enterprise Linux 8, other Linux distributions, ARM. The installer refuses them and says so.
Kerberos sign-in to applications	The host’s `krb5-libs` 1.21 or later, which Enterprise Linux 9 provides

SSOGEN runs on Enterprise Linux 8, the Gateway does not. A server that holds both must therefore be Enterprise Linux 9 or newer. The same requirements apply to the Outbound Connector and the Directory Connector, which are roles of the same Gateway software. See Install and enrol a Gateway.

4. What the Web Agent needs

The Web Agent is one module for all Apache 2.2 servers and one for all Apache 2.4 servers, Oracle HTTP Server included. The supported web servers and operating systems are listed in Protect an on-premise app with the Web Agent, and the packages for Oracle E-Business Suite, PeopleSoft, JD Edwards, Oracle HTTP Server and Apache in Oracle and Apache integration packages.

Web Agent 4.1.7 carries its own copies of the libraries it needs, so it does not depend on the versions your operating system has:

Built-in library	Version in 4.1.7
libcurl	8.23.0
libxml2	2.15.4
xmlsec	1.3.12
OpenSSL	3.5.9
jansson	2.15.1
zlib	1.3.2

5. How mixed versions behave

SSOGEN knows the version of every Gateway and Web Agent that connects to it, and sends each one only the settings that version understands.

Situation	What happens
SSOGEN is newer than a Gateway	The Gateway keeps working. A setting that needs a newer Gateway is held back from that Gateway group; everything else is served.
Gateways of one group on different versions	Supported for the time the upgrade takes, not longer. SSOGEN sends a group only what every live instance of it understands, so the oldest instance decides what the group gets. Upgrade the instances of a group one at a time, so the group keeps serving.
SSOGEN is newer than a Web Agent	The Web Agent keeps working with the configuration it understands.
A Gateway or Web Agent is newer than SSOGEN	Install the new SSOGEN before the new Gateways and Web Agents.

A 4.4 Gateway supports every Gateway feature of SSOGEN 4.4: Outbound Connectors, stored accounts for SSH, RDP and VNC, host pairing and Test, the Host header choice of a route, uplink, certificates added in the console, and RDP without Network Level Authentication.

6. The order to upgrade in

SSOGEN first.
Then every Gateway of each group, one group at a time.
Then the Outbound Connectors.
Web Agents at any time afterwards. A Web Agent upgrade is independent of the others.

The steps of each upgrade, the backup the installer takes and what to check afterwards are in Backup and upgrade. What changed in each version is in the Release notes.

7. Upgrade paths

From	To	Notes
SSOGEN 4.3	4.4	Supported in one step. The upgrade applies every database change added since your version. Every Gateway enrolled before the upgrade stays enrolled.
Web Agent 4.1.x	4.1.7	Install the new module file by copy-then-rename, run `apachectl configtest`, then restart gracefully; sessions survive a graceful restart. Keep the previous module file next to the new one so you can put it back. Read the release notes for the versions you pass, in particular the change of the logout default in 4.1.4.