Try OpenEdge Now
skip to main content
Identity Management
Configuring and Implementing Authentication in OpenEdge : Configuring authentication

Configuring authentication

To configure authentication, the following tasks must be completed for all types of OpenEdge database clients and sessions:
*In multi-tenant databases, configure all required regular tenants and super-tenants. You must add a super-tenant if you want to make super-tenant access rights available for a database. Also, the tenant must be enabled for data access in order to authenticate the tenant identity. For more information, see documentation on configuring tenants using OpenEdge Management or OpenEdge Explorer.
*Configure all required domains with their authentication system, access code, and for multi-tenant databases, their tenant (see Defining and configuring security domains). Note that you must configure at least one domain per each tenant or super-tenant to which you want to provide access in a multi-tenant database. That one domain can have the same name as the tenant for which it is configured.
*For OpenEdge-performed user authentication, configure users in the user accounts associated with each domain configured for user authentication. Note that the OpenEdge _User table accounts supported by _oeusertable domains, and the Windows user accounts supported by _oslocal domains are the only built-in user accounts that OpenEdge supports for access to multiple tenants and super-tenants of a multi-tenant database, because Windows supports multiple domains that can be arbitrarily mapped to tenants. Of these two choices, Windows user accounts offer the stronger overall security. Unix user accounts support only a single domain, and can therefore only authenticate a single tenant. Unix accounts can be useful in a multi-tenant database, for example, to support users of a single super-tenant domain, such as database administrators. However, using Unix accounts to authenticate a regular tenant is not recommended, because all Unix users would be limited to a single tenancy.
Caution: The OpenEdge _User table accounts do not meet recommended best practices for strong user authentication. The _User table accounts do not support: strong password storage, password rules, password history, resistance to off-line alterations, password cracker utilities, authentication time-out, and so on. Check these factors with your production site security policies when configuring domains to use _User table accounts.
*An additional option when setting up _User table accounts is to specify that a given account is available for SQL access only, which provides another level of authentication.
*Assign users to roles responsible for managing security. For DDL administration, you assign users to the role of SQL DBA (database administrator). For general ABL security, you assign users to the role of security administrator using the database administration tools. And for auditing, you assign users to specific audit roles.
*Finally, you can prevent users with the default (blank) user ID from connecting to or accessing a database. This requires all database access settings to specify a non-blank user ID.