The OpenEdge Authentication Gateway and related OpenEdge features were designed to ensure secure access to ABL application connections to OpenEdge components. Secured access to OpenEdge components begins with, and is dependent upon, a strong user authentication process that enforces a consistent policy across all of an ABL application’s distributed components. A prime example of employing consistent user authentication is an ABL application that uses multiple databases that are accessed by combinations of ABL clients and application servers that span the enterprise’s network.
The OpenEdge Authentication Gateway is a key component of a centralized authentication and authorization service for database connections. It is an implementation of a Security Token Service (STS) and is supported by other OpenEdge components, including:
Utilities to configure OpenEdge databases to access OpenEdge Authentication Gateway services
Tools to maintain and monitor OpenEdge database activity when using the Authentication Gateway
ABL functions, handle attributes and methods, and class properties that support OpenEdge Authentication Gateway services
The previous OpenEdge authentication process model allowed for the distribution of security processes among ABL clients and did not include authentication for database connections. With the OpenEdge Authentication Gateway and related OpenEdge features, the sole authentication point is an OpenEdge implementation of an STS. The OpenEdge Authentication Gateway:
Authorizes access to an STS
Supports local OS login credentials
Validates user ID and password credentials
Creates and passes back a sealed OpenEdge client-principal object (which is an ABL security token)
The Authentication Gateway is a secured Progress Application Server for OpenEdge (PAS) instance where the OESTS web application (oests.war) is deployed. The Authentication Gateway requires domain configuration and access to an authentication provider (OS Local, LDAP, Active Directory, etc.) to be able to create and seal a client-principal token.
The architecture addresses authentication and authorization process interactions between an OpenEdge database, its clients, and an OpenEdge Authentication Gateway server. The following diagram is a simplified view of the architecture:
The diagram shows that a client transmits credentials to a database server, which then passes those credentials to an OpenEdge Authentication Gateway. The Authentication Gateway is a centralized authentication point for all clients that request a connection to a particular database. If the credentials are valid, the Authentication Gateway creates a client-principal object, which is validated again before a client connection to the database is allowed.
In addition, note these more detailed aspects of the architecture:
Connection authorization and connection auditing execute inside the OpenEdge database.
The OpenEdge database delegates all user authentication (a.k.a., direct login) to the Authentication Gateway.
The OpenEdge database requires sealed client-principal objects from all clients as proof of user identity in connection authorization and change-user operations.
The OpenEdge database executes Role-Based-Authorization, employing the user’s sealed client-principal object, to grant/deny the user access to the database connection
Utilities to configure OpenEdge databases to access OpenEdge Authentication Gateway services
