Try OpenEdge Now
skip to main content
OpenEdge Authentication Gateway Guide
Configuring the OpenEdge Authentication Gateway : Configuration overview

Configuration overview

OpenEdge Authentication Gateway Server Configuration

Configuring an Authentication Gateway server includes making site-specific changes in three distinct subsystems in the underlying PAS for OpenEdge instance:
1. The server's ports, admin accounts, client connections, and client request execution
2. ABL session management and the Session Manager’s Agent process
3. ABL application event procedures, PROPATH, and any database connections
You can expect to configure these site-specific items:
*HTTPS network port
*HTTPS server private key and digital certificate
*Any optional IP address groups that are allowed to connect
*Any optional automated daemon startup scripts
*Any optional site-specific startup scripts for setting the server’s process environment
To harden the Authentication Gateway, the following changes to the underlying PAS were made:
*Both Tomcat and OpenEdge remote administration web applications are removed. This reduces the Authentication Gateway’s port footprint to just what is needed to service clients and leaves all administration to command line tools. The remote administration web applications may be re-installed at a test-site at an administrator's discretion. (See the PAS for OpenEdge Administration Guide.) However, it is not recommended.
*Standard PAS for OpenEdge administrator user accounts have been hardened by inserting digested passwords into the conf/tomcat-users.xml file.
*The ROOT web application and default ABL application have been removed to prevent the injection of other ABL applications. While inserting another ABL application into an Authentication Gateway can be done, it is not recommended.
See the PAS for OpenEdge documentation for more information on all of these sub-systems.

OpenEdge Security Token Service Configuration

The OpenEdge Security Token Service (STS) is the component that performs user-direct login and OS login SSO processes for the OpenEdge database. The STS is deployed into an Authentication Gateway as an ABL application, which means that it has its own configuration for PROPATH, startup parameters, and event handlers. The STS is distinct from any other ABL application that may be deployed into the same server.
You can expect to configure the service’s OpenEdge domains that provide the user-direct login and OS login SSO services, including individual domain settings for:
*The type of external user authentication system to integrate with
*Unique Domain Access Code
*Optional ABL policy module
*Optional ABL policy run-time options
*The type of actions the OpenEdge domain is allowed to execute
*Optional STS Key feature, that provides per OpenEdge installation access to the Authentication Gateway