Try OpenEdge Now
skip to main content
SQL Development
Data Control Language and Security : Working with database security : Comparing authentication and authorization : Authentication
 
Authentication
Authentication is the process of providing your user ID and password to the server in order to connect to the database from a client. The server then verifies your user identification. The client might be either an ABL client or an OpenEdge SQL (JDBC or ODBC) client.
For both OpenEdge SQL and ABL, support for users depends on the definition of OpenEdge security domains configured for supported authentication systems. A security domain defines the common mechanisms that a given security system (or systems) relies on to provide authentication, authorization, and session management services. A DBA defines these domains in each OpenEdge database using Database Administration and configures each domain for a particular authentication system. An authentication system determines the mechanism by which users are authenticated for access to the resources (e.g., databases) controlled by a given security system (such as OpenEdge SQL or ABL). By configuring an OpenEdge domain with a given authentication system, the DBA allows all the user accounts controlled by that authentication system to authenticate to the OpenEdge database in which the domain is defined (or in which the domain is defined to be a trusted authentication domain).
For both OpenEdge SQL and ABL, a user identifies the authentication system that OpenEdge uses to authenticate their user ID and password by specifying the name of an appropriate OpenEdge domain as part of their user ID. Such a user ID is known as a fully qualified user ID, because it specifies both their user name and domain name separated in a single string by the '@' delimiter character. Depending on the database configuration, non-qualified user IDs (the user name, alone, with no specified domain) can be used. In this case, OpenEdge uses the authentication system configured for the blank ("") domain to authenticate non-qualified user IDs.
Note: Only multi-tenant databases require and assume the use of a qualified user ID for authentication. For non-multi-tenant databases, while fully qualified user IDs can be defined and used, non-qualified user IDs can also be used for authentication.
OpenEdge supports a particular built-in set of authentication systems. Of these built-in authentication systems, two can be used to authenticate both SQL and ABL client connections to a database server:
*_oeusertable — Authenticates users defined in the database _User table accounts.
*_oslocal — Authenticates users defined in the server operating system accounts. Currently these include accounts created in the native Windows or Unix account systems.
For more information on OpenEdge support for security domains, authentication systems, and user IDs for authentication, see OpenEdge Getting Started: Identity Management.
From OpenEdge SQL, authentication can be enabled through _oeusertable domains when a DBA uses the CREATE statement to create a user and assign a password, thus creating an entry in the database's _User table accounts. ABL DBAs can create entries in the same _User table accounts by assigning user IDs and passwords through Database Administration. In addition, users defined in _User table accounts can be designated as SQL-only accounts, which can only authenticate users for access through OpenEdge SQL. For both OpenEdge SQL and ABL, administrators can enable authentication through _oslocal domains by creating user IDs and passwords for the user accounts of the Windows or Unix system that hosts the database server.
Although OpenEdge SQL and ABL security models are independent of each other, they do share common authentication systems. User IDs and passwords created for ABL in the supported authentication systems are also recognized by OpenEdge SQL, unless marked for SQL use only. Likewise, user IDs and passwords created using OpenEdge SQL are also recognized by ABL. In OpenEdge SQL, authentication occurs at the server; in ABL, authentication occurs at the ABL client.
Note: When initially populating the _User table from the SQL side, ensure that the first table entry is that of the DBA and ensure that particular username is granted DBA and RESOURCE privileges in the same transaction. Similarly, before populating the _User table from the ABL side, ensure that a database administrator defines at least one non-blank user ID as a Security Administrator. Otherwise, you can lock yourself out of the database.