OpenEdge allows you to set up table- and field-level security, which OpenEdge uses to authorize access to database tables and fields. This authorization can be specified to apply at:
Compile time — Checks to verify that the user has authorization to compile procedures that access database tables and fields as coded. Database authorization is always applied at compile time. For more information, see Compile-timesecurity.
Run time — Checks an authenticated user's authorization to access protected databases tables and fields as defined by the database's security settings. You can choose to apply database authorization at run time, but it is not applied by default. For more information, see Specifying run-time permissions checking and Run-time security.
Caution: If you plan to use OpenEdge SQL, as your first task be sure that you create an SQL DBA account as the first user account. Grant the account DBA rights by executing the GRANT statement. For more information, see OpenEdge Data Management: SQL Development.
Note: Table- and field-level security for the _Sequence metaschema table applies at both compile time and run time. For more information on this table, see OpenEdge Development: Programming Interfaces.
To set up database table- and field-level security, you and any other trusted users must be set up as security administrators. After you have designated yourself and others as security administrators, be sure that the user ID of each security administrator is included in all the permissions lists for the tables and fields for the database. For example, if you assign user ID sjones as a security administrator, but sjones is not included in the permissions for the customer table, sjones will not be able to modify permissions for the customer table. Any attempt to do so results in the error message, "Invalid access to change security for customer table." Thus, to modify table and field permissions, a user ID must be designated as a security administrator and be included in each of the CRUD (Create, Read, Update, and Delete) operations of the individual table and field permissions.
The user ID format you can specify for table- and field-level security differs depending on the tenancy configured for your database. So, if your database is:
Non-multi-tenant (the default) — The user IDs that you specify must be non-qualified, and cannot contain the domain-name delimiter character (@). OpenEdge interprets the user ID as a user name only.
Multi-tenant (license required) — The user IDs that you specify can be fully qualified, containing both a user and domain name separated by the domain-name delimiter character (@). If you specify a non-qualified user ID, OpenEdge interprets it as the specified user name in the blank ("") domain.
Note that to authenticate their identity for any database connection (non-multi-tenant or multi-tenant), users can authenticate to OpenEdge using a fully qualified user ID, which tells OpenEdge the domain in which to authenticate their identity. However, for non-multi-tenant databases, you can specify only a user's non-qualified user ID (user name) in table- and field-level security permissions lists.
For more information about user authentication, domains, and database tenancy, see OpenEdge Getting Started: Identity Management.
Compile time — Checks to verify that the user has authorization to compile procedures that access database tables and fields as coded. Database authorization is always applied at compile time. For more information, see Compile-timesecurity.
