Example security scenario

Table 1 presents a scenario for restricting access to API commands based on the types of user described in Workflow and types of user. In this table, "Yes" indicates that a user is allowed to perform the command. The table represents only one possible scenario: these types of user and restrictions may not exactly match your working environment. This scenario is presented as an example only; a starting point for developing your own security rules.

Table 1. Example: restricting access to API commands according to type of user
API command (resource key field) Type of user (RACF® group name)
CICS® Configuration Manager administrator Security administrator Change administrator Project manager Application developer CICS administrator Approver
List (LIS) Yes
Inquire (INQ)
Create (CRE) Yes

(repository location only)

Yes

(repository location only; approval profile objects only)

    Yes

(some CICS configurations only; change package-related repository objects only)

 
Update (UPD)
Delete (DEL)
Copy (CPY)
Add (ADD)         Yes

(some CICS configurations only)

 
Remove (REM)
Ready (RDY)       Yes Yes

(some migration schemes only)

 
Unready (UNR)
Migrate (MIG)     Yes   Yes

(some migration schemes only)

 
Backout (BAC)
Install (INO, INS)           Yes  
Discard (DIO)
Newcopy (NEO, NEW)
Approve (APP)             Yes
Disapprove (DIS)

Here is a summary of the permissions for each type of user, with general resource profiles that specify these permissions (these profiles assume that you have chosen "CICSCM" as the security key prefix):

All users
List or inquire on any object in any location:
CICSCM.LIS.*.*.*
CICSCM.INQ.*.*.*
CICS Configuration Manager administrator
Create, update, or delete any type of repository object:
CICSCM.CRE.*.REPOSITORY.NONE
CICSCM.UPD.*.REPOSITORY.NONE
CICSCM.DEL.*.REPOSITORY.NONE
Security administrator
Create, update, or delete approval profiles:
CICSCM.CRE.APROFILE.REPOSITORY.NONE
CICSCM.UPD.APROFILE.REPOSITORY.NONE
CICSCM.DEL.APROFILE.REPOSITORY.NONE
Change administrator
Migrate or back out change packages:
CICSCM.MIG.*
CICSCM.BAC.*

In this scenario, the change administrator is likely to be the person who "owns" the overall process of migrating all kinds of changes (not just CICS resource definitions) from development environments through to production. Change administrators might be the only users authorized to migrate change packages to a production environment. The CICS administrators for a production environment might be the only users authorized to install change packages into those production environments (after migration).

Project manager
Ready or unready change packages:
CICSCM.REA.*
CICSCM.UNR.*

You might want to restrict project managers so that they can only ready or unready change packages for particular migration schemes. In this scenario, however, we are allowing project managers to ready or unready any change package.

Application developer
You might want to restrict application developers so that they can affect only the development environments in which they work. This means defining general resource profiles that specify particular CICS configurations and migration schemes.
  • Create, update, delete, or copy any object (such as resource definitions) in a CICS configuration:
    CICSCM.CRE.*.CCONFIG.CICS_configurationCICSCM.UPD.*.CCONFIG.CICS_configurationCICSCM.DEL.*.CCONFIG.CICS_configurationCICSCM.CPY.*.CCONFIG.CICS_configuration
  • Add or remove resource definitions in ResGroups, or ResGroups in ResDescs:
    CICSCM.ADD.*.CCONFIG.CICS_configurationCICSCM.REM.*.CCONFIG.CICS_configuration
  • Start of changeCreate, update, or delete change packages (and their related repository objects):
    CICSCM.*.CHGPKG.REPOSTRY.NONE
    CICSCM.*.KEYASSOC.REPOSTRY.NONE
    CICSCM.*.PSCHEME.REPOSTRY.NONE
    CICSCM.*.READYLST.REPOSTRY.NONE
    End of change
  • Ready or unready change packages:
    CICSCM.REA.migration_schemeCICSCM.UNR.migration_scheme
  • Migrate or back out change packages:
    CICSCM.MIG.migration_schemeCICSCM.BAC.migration_scheme
CICS administrator
Similar to application developers, you might want to restrict CICS administrators so that they can affect only the CICS regions for which they are responsible.

Start of changeIn this scenario, CICS administrators have all of the permissions of application developers (as listed above), with the following additional permissions:End of change

  • Perform actions on active CICS regions:
    CICSCM.INO.*.*.location_nameCICSCM.INS.migration_schemeCICSCM.DIO.*.location_nameCICSCM.NEO.*.location_nameCICSCM.NEW.migration_scheme
Approver
Approve or disapprove change packages:
CICSCM.APP.migration_scheme.approver_profile.approver_role
CICSCM.DIS.migration_scheme.approver_profile.approver_role

How you define these permissions in your external security manager is up to you. Here is one general approach:

  1. Define one or more groups for each type of CICS Configuration Manager user.

    For example, for the CICS Configuration Manager administrator you might define one group named CICSADMN. For CICS administrators, you might define a group for each of your CICS environments: a CICSADMD group for development CICS administrators, and a CICSADMT group for test CICS administrators.

  2. Define general resource profiles that specify the permissions for each group.
  3. Add the groups to the access list of the general resource profiles.
  4. Add users to each group.
Note: Users need only READ authority to the general resource profiles for CICS Configuration Manager security keys.

Rather than defining separate groups for approvers, you might want to add general resource profiles for approval and disapproval to existing groups.

For example, suppose that you have defined groups for the CICS administrators for each environment, and that you want CICS administrators to be able to approve or disapprove change packages that affect their environments. Test CICS administrators (belonging to the CICSADMT group) should be able to approve or disapprove change packages that affect the test CICS regions. If your migration schemes that target test environments all have 8-character names that end in "TEST", then you could define the following general resource profiles for the CICSADMT group:

CICSCM.APP.%%%%TEST.*.CICSADMN
CICSCM.DIS.%%%%TEST.*.CICSADMN

where CICSADMN is one of the approver roles in the approval profiles for those migration schemes. The * indicates any approval profile.

These general resource profiles would permit any member of the CICSADMT group to represent the CICSADMN approver role for any change package whose migration scheme has an 8-character name that ends in "TEST".

For a detailed, step-by-step example of how to define group resource profiles for approvers, see Session 3. Approving change packages.