OpenEdge supports multiple configurable domains. At run time, all configured and enabled domains are made accessible through a trusted domain registry. A trusted domain registry is a run-time cache of domain entries loaded for any OpenEdge session or database connection that establishes a user identity. For SQL clients and database command-line utilities, a separate local registry is loaded for every database connection.
For ABL database clients, OpenEdge supports three basic configurations for trusted domain registries:
Using local database registries — Each database connection relies on the local domain registry automatically loaded by OpenEdge for each database connection to allow a user authentication or SSO operation to set the user identity for the connection. In an ABL client, a database connection can be configured to trust a domain registry that the ABL application can load in the ABL session.
Loading a session registry from a database — The ABL client uses the LOAD-DOMAINS( ) method on the SECURITY-POLICY system handle to load the domains of a single OpenEdge RDBMS into client memory, creating a session domain registry. A session domain registry allows the ABL client, through user authentication or SSO, to set a user identity for the ABL session that is separate from any database connection identity. In addition, by setting the database administration option, Use Application Domain Registry, for every database that is connected in an ABL session, all the databases rely on the single source of domain configuration provided by the session domain registry. Note that the session domain registry never automatically loads. So, if no ABL session registry is available when needed, the trusted domain registry for every database connection auto-defaults to the local database registry.
Note: If you rely on database local domain registries, you can still use a single operation to set multiple database connections to the same identity as the session. However, you must ensure that the domain and user configurations are identical for every database, especially the access code that you assign to the same domain in each database.
Creating a session registry entirely in ABL — The ABL client uses the REGISTER-DOMAIN( ) method on the SECURITY-POLICY system handle to create and load domains into the session registry one domain at a time, which includes setting the domain name and description, domain type (authentication system), and the access code for each domain. This is the only way to build a custom session domain registry that might be a subset, or even an entirely different set of domains from those configured in connected databases. This might be useful, for example, if you rely on the domain name of an authenticated session user to determine what databases to connect. However, such a custom session domain is inherently more error prone to maintain than one loaded from a database, and it is less secure, because you have to expose the clear-text access code for each domain to the application. You also cannot use an ABL-created domain registry to authenticate identity for a multi-tenant database connection, because such a registry has no tenant information associated with the registered domains.
Note: In an ABL application, loading or creating any session registry is one of the first tasks after starting up, so user logins can be supported.
Using local database registries — Each database connection relies on the local domain registry automatically loaded by OpenEdge for each database connection to allow a user authentication or SSO operation to set the user identity for the connection. In an ABL client, a database connection can be configured to trust a domain registry that the ABL application can load in the ABL session.