z/OS Security Server RACF Security Administrator's Guide
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Summary of steps for defining general resource profiles

z/OS Security Server RACF Security Administrator's Guide
SA23-2289-00

This summary presents the steps required by RACF® to define general resource profiles. Note that specific instructions for most resources supported by the supplied general resource classes are contained elsewhere in this document.
  1. Determine which resources are to be protected by the profile. This involves the following information:
    • The general resource class, such as TAPEVOL or TERMINAL
    • The profile name:
      • If you specify a generic profile name, the profile can protect more than one resource.

        Using generic profiles instead of discrete profiles can greatly reduce the effort of maintaining the profiles. In general, create generic profiles to cover most resources, using discrete profiles only for exceptions.

        Also, consider creating a profile to be used as a model, especially if you are specifying complex access lists. Models can be used when creating any kind of resource profile (discrete or generic), and modeling can be done across classes. To model, specify the FROM operand on the RDEFINE command. To model across classes, you should also specify the FCLASS operand. Before using modeling, see Possible changes to copied profiles when modeling occurs.
        Note: To specify generic profile names, either generic command processing or generic profile checking (the SETROPTS GENCMD or SETROPTS GENERIC option) must be in effect for the class. For example, for the TERMINAL class:
        SETROPTS GENERIC(TERMINAL)
      • If you specify a discrete profile name, the profile can protect only one resource.
      • The rules for specifying profile names for most supplied general resource classes are described elsewhere in this document.
      Note:
      1. For some kinds of resources, (such as terminals, DASD volumes, and CICS®, IMS™, and SDSF classes), you should consider using resource group profiles instead of generic profiles. Creating resource group profiles can save a significant amount of work. See Creating resource group profiles for more information.
      2. You can use RACFVARS profiles to specify values for variables (indicated by an ampersand &) in profile names. For more information, see Using RACF variables in profile names (RACFVARS class).
    • Decide which access is to be allowed to all users on the system who are not otherwise limited. In RACF, this is called the universal access authority (UACC). This has the same meaning as the access authority on access lists (see Step 3). In most cases, the UACC should be NONE or READ.
    • Decide which user or group is to be the owner of the new resource profile. By default, this is the user who creates the profile.
      • If the owner is a user, the owner can list, modify, or delete the resource profile. Note that being the owner of a resource profile does not, by itself, allow a user to have access to the resource or resources that are protected by the profile. For more information, see Step 16 in Authorizing access to RACF-protected resources.
      • If the owner is a group, the authority of a user who has a group-level attribute in that group (such as group-SPECIAL or group-AUDITOR) extends to resources that are protected by this profile.
    • Decide which user, if any, should be notified by a message when users make unsuccessful attempts to access resources that are protected by the profile (NOTIFY operand).
    • Decide whether RACF should log access attempts to resources that are protected by the profile (AUDIT operand).
      Note: To see the results of the logging done by RACF, use the RACF report writer. For more information, see z/OS Security Server RACF Auditor's Guide.
    • If your installation is using some form of security classification, do one of the following:
      • If security labels are used on your system, decide which security label (if any) to assign to the profile.

        When security labels are being used on your system, be aware that security levels and categories are ignored.

      • If security levels are used on your system, decide which security level (if any) to assign to the profile.
      • If security categories are used on your system, decide which security categories (if any) to assign to the profile.
      • If your installation has written RACF installation exits to use the LEVEL operand, decide which value to specify for LEVEL.
    • Depending on the class of the resource, the profile might have additional fields for which you should assign values. For example:
      • Profiles in the APPCLU class have SESSION segments
      • Profiles in the TAPEVOL class have the SINGLEDSN and TVTOC operands
      • Profiles in the TERMINAL and GTERMINL classes have the WHEN and TIMEZONE operands (both optional). WHEN determines the times and days a terminal can be used.
        Note: This WHEN is not the same as the WHEN operand in a conditional access list.

      See the appropriate topic of this document or the description of the RDEFINE command in z/OS Security Server RACF Command Language Reference for specific information on these operands.

    • To copy an existing profile, specify the name of the existing profile on the FROM operand. If the existing profile is in a different class, specify FCLASS also.
  2. Create the general resource profile using the RDEFINE command:
    RDEFINE classname profile-name other-operands
    Note: To change a general resource profile, use the RALTER command.
  3. If specific users or groups are to have specific access to the resource, use the PERMIT command to create one or both of the access lists:
    • Each entry in the standard access list states which access (such as NONE or READ) a specific user or group has:
      PERMIT profile-name CLASS(classname)
             ID(userid or group) ACCESS(access-authority)
    • Each entry in the conditional access list states which access (such as NONE or READ) a specific user or group has, and also states which condition a user must meet to get the specified access:
      PERMIT profile-name CLASS(classname)
             ID(userid or group) ACCESS(access-authority)
             WHEN(condition)
    Note:
    1. Access authorities that you can specify with UACC or specifically assign to users vary from class to class, and are described in the topics of this document that describe the specific classes.
    2. Not all classes are described in this document. (For example, the DSNR class is not described in this document.) Also, in some classes (notably the FACILITY class), the access required by some resource managers to specific profiles is described in the documentation of the resource manager. Therefore, go to that resource manager to find the descriptions of that class. (In the case of DSNR, which is used by DB2®, see RACF and DB2.)
    3. The profile creator might be automatically added to the access list with ALTER authority. For more information, see Automatic addition of creator's user ID to access list.
  4. If you have not already done so, activate the resource class:
    SETROPTS CLASSACT(classname)
  5. For performance benefits, consider doing one of the following:
    • Allow all users on the system to have access to the resource at some level (such as READ or UPDATE) by creating a global access checking table entry that has a name similar to the new resource profile.

      See Setting up the global access checking table.

    • Reduce I/O to the RACF database by requesting that RACF keep all profiles in the class in storage:
      SETROPTS RACLIST(classname)
      Note: This is required for some classes.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014