Activating CA IDMS Security › Creating Security Definitions

Creating Security Definitions

External Security Definitions

If security enforcement for a CA IDMS resource is external, you do not need to store information about the resource in the CA IDMS security database.

Before you create the SRTT entries that contain external security information, be sure to complete the steps necessary to define resources and security rules for resources in the external security system. When you create the SRTT with entries that include SECBY=EXTERNAL, you activate external security enforcement for the resource types specified in those entries.

Note: For more information, see Using External Security.

For external security checking, you must specify in the #SECRTT entry the format of the resource name that centralized security should forward to the external security system. You construct the external resource name format in the SRTT to match the format you have specified for the resource in the external security system.

Note: For more information, see Constructing an External Resource Name.

Internal Security Definitions

To secure one or more resources internally, you must define users to the user catalog and grant privileges on the resources to users. You can create any or all of these definitions before activating security in the SRTT. Remember, however, that until you activate security for CA IDMS administration privileges, any users signed on to the system can also manipulate internal security definitions (and any user can sign on until signon is secured).

As you plan the sequence of creating the security definitions needed for your security scheme, be aware of these considerations:

• You can add a user to a group in one of these ways:
  • Using the GROUP parameter of the CREATE/ALTER USER statement.

    This specifies the user's default group. Only one group can be specified.

  • Using the ADD USER clause of the CREATE/ALTER GROUP statement.

    You can add the user to any number of groups in this way. You must first create the user.

• You associate a user profile with a user in the CREATE/ALTER USER statement. You can do this before you define the profile; the information is stored, and a warning is issued.
• Profiles may be associated with user identifiers but not group identifiers.
• The scope of a user profile is the domain, but a system profile, like the grant of signon privilege which associates a system profile with a user, is system-specific.
• You can grant privileges on resources defined by CA IDMS to authorization IDs before the authorization IDs are defined; the information is stored, and a warning is issued.
• You can grant privileges on resources defined by CA IDMS to authorization IDs before the resources are defined except for resources specified in the CREATE RESOURCE statement (systems, activities, and categories).
• If you create groups corresponding to sets of privileges that you will grant, the number of CREATE GROUP statements required is likely to be much less than the number of GRANT statements to users that you would otherwise issue.
• In general, it is easier to restrict grants of privilege only to groups because it is easier to grant a set of privileges implicitly to a user by adding the user to the group than it is to grant each privilege individually to the user.
• A group may consist of only one user.
• The group PUBLIC is an authorization ID (defined by the system the first time a privilege is granted to it) to which all users belong by default. An appropriate step to consider is transferring ownership of the demonstration database schemas to PUBLIC.
• Categories allow you to group system resources so that you can grant execution privilege on the category (multiple resources) to a user or a group (multiple users) with one statement.
• A resource occurrence may participate in only one category.
• In general, you ease the administration of internal security if you establish a 1:1:1 correspondence among groups, categories, and execution privileges.
• When you create application activities, name the activities in a way that will allow you to use a wildcard in grants of execution privilege on activities.

  Note: For more information, see Using a Wildcard.

• If you plan to activate security for the system dictionary and the user catalog, consider doing it with DB occurrence overrides.

  Note: For guidance in planning security for the system dictionary and the user catalog, see Securing the Dictionaries and the User catalog.