_progress._sec-role

This table defines the roles that are available to control authorized access to resources. The use of roles for authorization provides high scalability by minimizing the need to setup specific permissions against individual user accounts, with restrictions on specific user accounts being the exception case. The definition of a role in this table is mandatory and a role cannot be granted to a user or other role until it is created in this table. This table therefore provides a registry of the available roles and can be used to validate rules such as the inability for a user to have the same name as a role and the limitation that a user can never authenticate as a role name. The SQL standard states that a role cannot be defined with the same name as a user account and vice-versa. This constraint is generally useful and is enforced in all cases, thereby avoiding the need to record whether a granted role is for a user or for a role. The role name will be defined with a namespace to avoid conflicts. The role name will be case insensitive and will be limited to 32 characters. The role itself can be used as a permission and the fact the user is granted the role can drive authorized behavior. This concept will be used for internal system roles, e.g. a DBA or Audit Administrator. As far as possible however permissions for system roles will be explicit (defined in ACLs). System roles will follow a standard naming convention in that they will all start with an underscore and a code to determine which clients the system role is applicable to as follows; _SYS - Internal system role applicable to all clients _PVM - Internal PVM specific role. This role is only valid for 4GL clients _SQL - Internal SQL specific role. This role is only valid for SQL clients In addition, for application defined roles they cannot begin with an underscore but can follow a similar convention, namely: SYS - Application defined role applicable to all clients 4GL - Application defined role applicable to 4GL clients only SQL - Application defined role applicable to SQL clients only If there is no such prefix to the role name then it will be assumed to be an application role applicable to all clients. Note that the above rules are purely a convention and not currently enforced by the database, or the SQL/4GL clients. It is strongly recommended that the convention is followed however to support future migration in the event that behavior is added later that uses this convention. As mentioned above, the fact a user or role is granted membership of a role can be useful in itself for authorizing actions on resources, but to support a finer level of detailed permissions to be defined, roles can have explicit permissions granted or denied via the _sec-access-control-entry table used to define ACLs. Sample rolenames could include; _sys.audit.admin _sys.audit.archive _sys.audit.insert