Creating tenant definitions in RACF

Edit online

Secure your OMEGAMON enhanced 3270 user interface multi-tenancy environment using RACF. This topic describes the profiles that must be created.

Before you begin

Because of the authority that is required, some of the steps in this task must be performed by the RACF administrator. It is recommended that you test your tenant definitions using PDS members and then, when satisfied, transfer the definitions to RACF.
Note: The definitions described in this topic can also be made in PDS members. For more information, see Creating tenant definitions in PDS members.

Additionally, if RACF is used, the OMEGAMON enhanced 3270 user interface started task needs to be authorized to issue RACROUTE EXTRACT requests for CSDATA fields for any user ID that logs in to the enhanced 3270 user interface.

About this task

To secure your multi-tenancy environment using RACF, you must create profiles for the tenant. You create the customer, group, and user definitions for the tenant in RACF using the following profiles:
  • To create customer and group definitions, use RACF general resource profiles in the following naming patterns, respectively:
    KOBUI.MULTI.CUST.customerID
    KOBUI.MULTI.GROUP.group
    You must create a resource for each customer and group within the security class specified in parameter RTE_SECURITY_CLASS.
    Customer and group details are defined by setting parameters in the installation data field and, if additional space is needed, in the application data field. A parameter and its value must be defined entirely in either field; and, if a parameter is specified in both places, the definition in the application data field is used.
    Note: Installation data (INSTDATA) and application data (APPLDATA) are limited to 255 characters each.
  • To create user definitions, use RACF user profiles.

The following list describes the definitions:

  • Customer. A resource is created for each customer. The customer ID is defined as a resource using the naming pattern KOBUI.MULTI.CUST.customerID. The customer details are defined as installation data (and, if additional space is needed, application data) for the resource. The following example shows a customer definition:
    CLASS      NAME
-----      ----
class      KOBUI.MULTI.CUST.customerID

LEVEL  OWNER      UNIVERSAL ACCESS  YOUR ACCESS  WARNING
-----  --------   ----------------  -----------  -------
 00    ownerid         NONE               NONE    NO

INSTALLATION DATA
-----------------
msType="msl" CUSTNAME="customerTitle"

APPLICATION DATA
----------------
NONE

AUDITING
--------
FAILURES(READ)

NOTIFY
------
NO USER TO BE NOTIFIED
    Where:
    • class is the name of the RACF security class specified in parameter RTE_SECURITY_CLASS.
    • customerID is the customer ID.
    • customerTitle is the unique customer descriptive title, which can be up to 50 characters.
      Tip: If the entire customer name cannot be specified in the installation data due to the 255-character limit, it can be specified in the application data, as follows:
      INSTALLATION DATA
-----------------
msType="msl" 

APPLICATION DATA
----------------
CUSTNAME="customerTitle"
    • msType is the managed system type. A separate definition is made for each type. Valid values: ZOS, CICS, IMS, DB2, CTG, MQ, QSG, IIB, STOR, MFN, TCP, VTAM, MFAD, JAVA.
      Note: With APAR OA59694, managed system type MFN has been replaced with the following managed system types for IBM OMEGAMON for Networks for z/OS: TCP, VTAM, and MFAD (Administration). It is recommended that you use TCP, VTAM, and MFAD instead of MFN.
    • msl is the name of the managed system list (group) for the respective managed system type. A unique MSL must be specified for each managed system type. If the MSL name ends with ?, then the customer ID will be substituted. See Naming convention for the recommended MSL name format.
  • Group. A resource is created for each group. The group name is defined as a resource using the naming pattern KOBUI.MULTI.GROUP.group. The group details are defined as installation data (and, if additional space is needed, application data) for the resource. The following example shows a group definition:
    CLASS      NAME
-----      ----
class      KOBUI.MULTI.GROUP.group

LEVEL  OWNER      UNIVERSAL ACCESS  YOUR ACCESS  WARNING
-----  --------   ----------------  -----------  -------
 00    ownerid         READ               READ    YES

INSTALLATION DATA
-----------------
FIRSTWS=workspace,SHOWEVT=n,SHOWZOS=n,SHOWCICS=n,SHOWCTG=n,SHOWIMS=n,SHOWDB2=n,
SHOWMQ=n,SHOWIIB=n,SHOWMFN=n,SHOWSTOR=n,SHOWJAVA=n

APPLICATION DATA
----------------
NONE

AUDITING
--------
FAILURES(READ)

NOTIFY
------
NO USER TO BE NOTIFIED
    Where:
    • class is the name of the RACF security class specified in parameter RTE_SECURITY_CLASS.
    • group is the group name.
    • workspace is the workspace to display at logon, which is an 8-character panel ID.
    • n specifies whether the respective tab is displayed in the first workspace. Valid values are Y and N. The variables and corresponding tabs are as follows:
      Table 1. OMEGAMON tab options in first workspace
      Option Tab
      SHOWEVT Events
      Note: Multi-tenancy mode is not supported for the Events tab. The user will see all available resources and will not be restricted to only those resources in the user-defined MSLs for the tenant.
      SHOWZOS z/OS
      SHOWCICS CICS
      SHOWCTG C/TG
      SHOWIMS IMS
      SHOWDB2 DB2
      SHOWMQ MQ
      Note: The MQ tab displays the queue-sharing group (QSG) information. To include QSG information, you must define an MSL for the QSG managed system type for the customer.
      SHOWIIB n/a
      Note: There is not a corresponding tab for the Integration Bus (IIB) agent. To view IIB information, use the Integration Bus option on the Navigate menu.
      SHOWMFN MFN (Mainframe Networks)
      SHOWSTOR STOR (Storage)
      SHOWJAVA JVM
  • Users. Definitions for user IDs are contained within RACF custom data fields, which are contained in a CSDATA segment. For each user ID, the following RACF CSDATA fields are used:
    • OMGROUP. This field has a maximum length of 10 and typically contains an 8-character value like OMEGCICS.
    • OMPOWER. This field has a maximum length of 8. Valid values are YES and NO.
    • OMSUPER. This field has a maximum length of 8. Valid values are YES and NO.
    • OMCUST. This field has a maximum length of 10 and typically contains a 6 to 8-character value like CUSTID.
    The following example shows the CSDATA fields for a user:
    SECURITY-LEVEL=NONE SPECIFIED
CATEGORY-AUTHORIZATION
 NONE SPECIFIED
SECURITY-LABEL=NONE SPECIFIED

CSDATA INFORMATION
------------------
OMEG GROUP group
OMEG POWER Y|N
OMEG SUPER Y|N
OMEG CUSTOMER customerID
    Where:
    • group is the associated group name, which can be up to 10 characters.
    • customerID is the associated customer ID, which can be up to 10 characters. This parameter is omitted for super users.
    For more information about CSDATA fields, see the z/OS Security Server RACF Security Administrator's Guide.
    Note: To display, add, or modify information in the CSDATA segment, you must have the appropriate authorization. These tasks are typically performed by the RACF administrator. Additionally, the OMEGAMON started task needs to be authorized to issue RACROUTE EXTRACT requests for CSDATA fields for any user ID that logs in to the enhanced 3270 user interface.

Use the following procedure to create the customer, group and user definitions in RACF. Refer to the z/OS Security Server RACF documentation for details.

Procedure

  1. Create your customer definitions using RACF General Resource Profiles (Option 2 on the RACF - Services Option Menu).
  2. Create your group definitions using RACF General Resource Profiles (Option 2 on the RACF - Services Option Menu).
  3. Create your user definitions using RACF User Profiles (Option 4 on the RACF - Services Option Menu).
  4. Authorize the OMEGAMON started task to issue RACROUTE EXTRACT requests for CSDATA fields for any user ID that logs in to the enhanced 3270 user interface.

What to do next

Because tenant definitions can exist in either PDS members or an external security system, you must indicate the location of the tenant definitions that you want to use. For more information, see Setting the location of the tenant definitions.