Securing Database Resources › Securing the Dictionaries and the User catalog

Securing the Dictionaries and the User catalog

Activating Database Security

The dictionaries and the user catalog are CA IDMS databases. To secure these entities, you must activate database security for them.

The following discussion explains what to do when you secure dictionaries by defining occurrence overrides.

Note: You can secure all dictionaries by specifying security for all databases in an SRTT entry for the DB resource type.

For the purposes of discussion, the authorities that you give to allow access to a dictionary are the CA IDMS privileges you would grant if the dictionary is secured internally.

Securing the System Dictionary

To secure the system dictionary using occurrence overrides, you must secure the DB resource type for database name 'SYSTEM' and the names of the three segments that comprise the system dictionary.

In the following example, the first entry secures the name 'SYSTEM' which prevents access to the system dictionary through the database name defined for it at installation. This entry also prevents access to the SYSTEM segment. The next entries secure the SYSMSG segment, which contains messages, and the CATSYS segment, which is the catalog component of the dictionary.

#SECRTT TYPE=OCCURRENCE,                                      X
      RESTYPE=DB,                                             X
      RESNAME='SYSTEM',                                       X
      SECBY=INTERNAL

#SECRTT TYPE=OCCURRENCE,                                      X
      RESTYPE=DB,                                             X
      RESNAME='SYSMSG',                                       X
      SECBY=INTERNAL

#SECRTT TYPE=OCCURRENCE,                                      X
      RESTYPE=DB,                                             X
      RESNAME='CATSYS',                                       X
      SECBY=INTERNAL

Securing the User catalog

To secure the user catalog with an occurrence override, specify the SYSUSER segment, as in this example:

#SECRTT TYPE=OCCURRENCE,                                      X
      RESNAME='SYSUSER',                                      X
      RESTYPE=DB,                                             X
      SECBY=INTERNAL

If a database name has been defined for this segment, you must also include an entry specifying the database name.

Securing Application Dictionaries

If you activate database security with occurrence overrides, you must individually secure every segment in the application dictionary and every database name that includes a dictionary segment.

Privileges for Secured Dictionaries

After you have secured dictionaries and the user catalog, you grant privileges that permit appropriate access.

If security for the dictionary databases is internal, you grant CA IDMS privileges on the database resource types associated with the dictionary, including privileges on resources such as run units and areas that allow users to access the dictionary according to their needs.

If security for the dictionary databases is external, you define rules for each dictionary database and each of its associated database resources in the external system. You add SRTT entries with external class and resource name information for the dictionary database resources to be sent with security checks to the external security system.

For example, users who must execute the CA IDMS compilers such as the schema compiler require execute privilege on a Category containing compiler run unit resources. Users who must execute CA IDMS utilities require the appropriate privileges for area access.

Granting Privileges on Run Units

To grant blanket run unit access to an internally secured system dictionary, you first categorize all run units and then grant privilege on the category, as in this example:

create resource Category sysdict_general
  add rununit sysdict.* ;

grant execute
  on Category sysdict_general
  to general ;

To categorize specific run units for CA IDMS compilers and tools that access the dictionary, you can specify as appropriate run units listed in the installation source library member DLODSECR.

For the purpose of using the CA IDMS Command Facility, there is no need to grant privileges on run units that access the SYSUSER segment.

Example

In this example, the system and application dictionaries have been secured. The first statement creates a Category of run units that access these dictionaries, and the second statement grants EXECUTE privilege on the Category:

create resource Category rununit_category
    add rununit appldict.idmsnwka.idmschem
    add rununit appldict.idmsnwka.idmsdddl
    add rununit appldict.idmsnwka.idmsubsc
    add rununit appldict.idmsnwkg.idmsrpts
    add rununit system.idmsnwka.idmsdddl
    add rununit system.idmsnwka.rhdcsgen
    add rununit system.idmsnwkg.idmsrpts
    ;

grant execute on Category rununit_category
    to rununit_group
    ;

Granting Privileges on Areas

To allow execution of certain CA IDMS utilities against a secured database, you grant DBAREAD or DBAWRITE privilege on the area or areas to be accessed. The following table presents the installation names of the areas of the system dictionary and the user catalog:

Granting Privileges on Non-SQL-defined Schemas

When you secure the dictionaries and the user catalog, you control SQL access to these databases. You allow SQL access by creating SQL schemas for the non-SQL-defined schemas that describe these databases (IDMSNTWK for the dictionary and IDMSSECU for the user catalog) and granting table access privileges.

Similarly, security definitions for system and non-SQL-defined database resources are inaccessible through SQL unless you create an SQL schema for IDMSSECS, the non-SQL-defined schema for system resources security database.

Granting Access to SYSTEM Tables

When you secure a dictionary as a database, you secure tables associated with the SYSTEM schema in the catalog component of the dictionary. To allow access to the SYSTEM tables, you have these options:

• Grant access privileges on SYSTEM tables, individually or collectively.
• Grant access privileges on SYSCA views, which allow the executing user to view data in SYSTEM tables about only those tables on which the user holds SELECT privilege.

Note: For more information about SYSTEM tables and SYSCA views, see the CA IDMS SQL Reference Guide.