Creating access controls for the Software Management task

The Software Management task allows users with proper authorization to manage global zones, software instances, deployments, and categories. For some actions, users must also have appropriate authorization to the physical resource these objects describe, such as a target zone or data set. This topic describes how to control user access to the objects in the Software Management task. Creating access controls for the actual physical resource is outside the scope of z/OSMF.

You can use a security manager, such as RACF®, to control access to the task and to create more granular authorizations, such as restricting access to an object or an action. Access to the Software Management task and its objects are controlled through the following default resource profiles, which are defined in the ZMFAPLA class:


<SAF-prefix>.ZOSMF.SOFTWARE_DEPLOYMENT.SOFTWARE_MANAGEMENT
<SAF-prefix>.ZOSMF.SOFTWARE_DEPLOYMENT.DATA.** 
<SAF-prefix>.ZOSMF.SOFTWARE_DEPLOYMENT.SOFTWARE_MANAGEMENT.PRODUCT_INFO_FILE.RETRIEVE
<SAF-prefix>.ZOSMF.SOFTWARE_DEPLOYMENT.SOFTWARE_MANAGEMENT.CATEGORIES.MODIFY

With the default access authorities in effect, z/OSMF users and administrators are allowed to perform all actions for all software instances, portable software instances, and deployments, and only z/OSMF administrators are allowed to retrieve information from product information files and add, modify, or remove categories.

Important: All users of the Software Management task should be permitted at least READ access to profile <SAF-prefix>.ZOSMF.SOFTWARE_DEPLOYMENT.DATA.**. Otherwise, no actions can be performed because users will not have access to any objects.

To further restrict access to the objects and actions, define a SAF resource profile for each object and grant users the appropriate access authority. Regardless of where the physical resource that is described by an object resides, the SAF profiles for that object must be defined on the z/OS® system that hosts the z/OSMF instance to which a user's web browser is connected. The Software Management task uses this z/OS system when it checks SAF authorizations.

Use the SAF resource names, which are generated by the Software Management task, to help you define profiles that control user access to an object or an action. The SAF resource names for each object are constructed using properties of the object. The casing that is used for each property value is preserved; therefore, SAF resource names are case-sensitive. The SAF resource name format that is used for each object type and supported actions are described in the sections that follow.

Authorizing users to software instances

A software instance describes a deployable unit of software, which is composed of data sets containing SMP/E installed software. To control access to a specific software instance, define a SAF resource profile for that resource. The SAF resource name for a software instance object has the following format:

 
<SAF-prefix>.ZOSMF.SOFTWARE_DEPLOYMENT.DATA.SWI.category.systemName.instanceName

Where:

SWI indicates that the object that is associated with this SAF resource is a software instance.
category is the name of the category that is assigned to the software instance. If multiple categories are assigned, a separate SAF resource name is created for each category. If no category is assigned, the category value is NOCATEGORY.
To perform an action, users must have the access authority that is required for that action for all the SAF resource names that are associated with the software instance.
systemName is the name of the z/OSMF host system that has access to the volumes and data sets where the software instance resides. The system is inherited from the global zone that is associated with the software instance, and is defined in the Systems task.
instanceName is the name of the software instance.

For example, if you have a software instance that is named z/OSV2R3_Test that can be accessed by system AQFT and is assigned to categories z/OS and Test, its SAF resource names would be:

 
<SAF-prefix>.ZOSMF.SOFTWARE_DEPLOYMENT.DATA.SWI.z/OS.AQFT.z/OSV2R3_Test
<SAF-prefix>.ZOSMF.SOFTWARE_DEPLOYMENT.DATA.SWI.Test.AQFT.z/OSV2R3_Test

Table 1 lists the access authorities that you can assign to software instance resources and the actions that are permitted for each access authority. The Software Management task does not perform authorization checks to determine which software instances to display in a list or table; therefore, all software instances are displayed regardless of access authority.

Table 1. Actions users can take against software instances by access authority
Access Authority	Actions Allowed
READ	View the properties of the software instance. View information about the products, features, and FMIDs contained in a software instance. View information about the data sets contained in a software instance. Copy the properties of the software instance. Deploy the software instance during a deployment. Use the software instance as the model for priming a deployment configuration. Generate reports for the software instance. Export the software instance. Perform workflows for the software instance.
UPDATE	In addition to the actions specified for READ access, users can perform the following actions: Modify the software instance properties that are not used to create the SAF resource name for the software instance. This includes modifying the software instance explicitly using the Modify action or implicitly when completing a deployment where the objective is to replace the software instance. Replace the software instance during a deployment. Retrieve information from SMP/E about the products, features, and FMIDs contained in the software instance and make that information available to z/OSMF. Update the software instance in the Software Update task. Delete temporary catalog aliases for the software instance.
CONTROL	In addition to the actions specified for READ and UPDATE access, users can perform the following actions: Create new software instances explicitly using the Add action or implicitly as part of the Copy action or when completing a deployment where the objective is to create a new software instance. Modify the software instance properties that are used to create the SAF resource name for the software instance and control access to the software instance. This includes modifying the software instance explicitly using the Modify action or implicitly when completing a deployment where the objective is to replace the software instance. Remove the software instance.

Authorizing users to portable software instances

Each software instance archive has a unique SAF resource name that can be used by your security manager to control access to the portable software instance. The SAF resource name for a portable software instance archive object has the following format:

<safPrefix>.ZOSMF.SOFTWARE_DEPLOYMENT.DATA.PSWI.category.systemName.portableSwiName

where:

PSWI: Indicates that the object that is associated with this SAF resource is a portable software instance.
category: Is the name of the category that is assigned to the portable software instance. If multiple categories are assigned, a separate SAF resource name is created for each category. If no category is assigned, the category value is NOCATEGORY. To perform an action, users must have the access authority that is required for that action for all the SAF resource names that are associated with the portable software instance.
systemName: Is the nickname of the z/OSMF host system that has access to the UNIX directory where the portable software instance resides. The system is defined in the z/OSMF Systems task.
portableSwiName: Is the name of the portable software instance.

The following describes the access authority levels that are used to control access to portable software instance objects and the actions that are permitted for each access authority. The Software Management task does not perform authorization checks to determine which portable software instances to display in a list or table; therefore, all portable software instances are displayed regardless of a user's allowed access authority.

Table 2. Actions users can take against portable software instances by access authority
Access Authority	Actions Allowed
READ	View the properties of the portable software instance. Deploy the portable software instance during a deployment.
UPDATE	In addition to the actions specified for READ access, users can perform the following action: Modify the portable software instance properties that are not used to create the SAF resource name for the portable software instance.
CONTROL	In addition to the actions specified for READ and UPDATE access, users can perform the following actions: Create new portable software instances explicitly by using the Add action. Modify the portable software instance properties that are used to create the SAF resource name for the portable software instance and control access to the portable software instance. Remove the portable software instance.

Authorizing users to deployments

A deployment is a checklist that guides users through the process of cloning or deploying a software instance, and it is the object in which z/OSMF stores information about the clone, such as its data set names and locations, catalog structure, and SMP/E zone names. To control access to a specific deployment, define a SAF resource profile for that resource. The SAF resource name for a deployment object has the following format:

 
<SAF-prefix>.ZOSMF.SOFTWARE_DEPLOYMENT.DATA.DEP.category.deploymentName

where:

DEP indicates that the object that is associated with this SAF resource is a deployment.
category is the name of the category that is assigned to the deployment. If multiple categories are assigned, a separate SAF resource name is created for each category. If no category is assigned, the category value is NOCATEGORY.
To perform an action, users must have the access authority that is required for that action for all the SAF resource names that are associated with the deployment.
deploymentName is the name of the deployment.

For example, if you have a deployment that is named z/OS_R21_Production that is not assigned to any category, its SAF resource name would be:

 
<SAF-prefix>.ZOSMF.SOFTWARE_DEPLOYMENT.DATA.DEP.NOCATEGORY.z/OS_R21_Production

Table 3 lists the access authorities that you can assign to deployment resources and the actions that are permitted for each access authority. The Software Management task does not perform authorization checks to determine which deployments to display in a list or table; therefore, all deployments are displayed regardless of access authority.

Table 3. Actions users can take against deployments by access authority
Access Authority	Actions Allowed
READ	View the properties of the deployment. Copy the properties of the deployment.
UPDATE	In addition to the actions specified for READ access, users can perform the following actions: Modify the deployment properties that are not used to create the SAF resource name for the deployment. Cancel the deployment. This action ends the deployment, unlocks the associated software instances, and limits all future actions for the deployment to View and Remove.
CONTROL	In addition to the actions specified for READ and UPDATE access, users can perform the following actions: Create new deployments explicitly by using the New action or implicitly as part of the Copy action. Modify the deployment properties that are used to create the SAF resource name for the deployment and control access to the deployment. Remove the deployment.

Authorizing users to categories

A category is a string or label that is used to organize and group software instances and deployments. A category might denote a system, subsystem, software vendor, software life cycle state, business function, or geographic location. There are no predefined categories.

To control access to a specific category, define a SAF resource profile for that resource. The SAF resource name for a category object has the following format:

 
<SAF-prefix>.ZOSMF.SOFTWARE_DEPLOYMENT.DATA.CAT.categoryName

Where:

CAT indicates that the object that is associated with this SAF resource is a category.
categoryName is the name of the category.

For example, if you have a category that is named z/OS, its SAF resource name would be:

 
<SAF-prefix>.ZOSMF.SOFTWARE_DEPLOYMENT.DATA.CAT.z/OS

Table 4 lists the access authorities that you can assign to category resources and the actions that are permitted for each access authority. Note that the Software Management task does not perform authorization checks to determine which categories to display in a list or table; therefore, all categories are displayed regardless of access authority.

Table 4. Actions users can take against categories by access authority
Access Authority	Actions Allowed
READ	View the properties of the category. Copy the properties of the category. Assign deployments and software instances to the category.
UPDATE	In addition to the actions specified for READ access, users can perform the following action: Modify the category properties that are not used to create the SAF resource name for the category.
CONTROL	In addition to the actions specified for READ and UPDATE access, users can perform the following actions: Create new categories explicitly by using the Add action or implicitly as part of the Copy action. Modify the category properties that are used to create the SAF resource name for the category and control access to the category. Remove the category.

Using categories to authorize users to groups of software instances and deployments

Because category names are part of the SAF resource name for software instances and deployments, you can use categories to control access to groups of software instances and deployments. For example, if you want to give Db2® system programmers CONTROL access to all software instances and deployments in the Db2 category and give other users READ access to these objects, define a SAF profile for the following resource:

 
<SAF-prefix>.ZOSMF.SOFTWARE_DEPLOYMENT.DATA.*.DB2.**

If your installation is using RACF and your Db2 system programmers are defined in a group that is called DB2PROG, you can create a profile like the following:

 
RDEFINE ZMFAPLA +
(IZUDFLT.ZOSMF.SOFTWARE_DEPLOYMENT.DATA.*.DB2.**) UACC(NONE)
PERMIT +
IZUDFLT.ZOSMF.SOFTWARE_DEPLOYMENT.DATA.*.DB2.** +
CLASS(ZMFAPLA) ID(DB2PROG) ACCESS(CONTROL)
PERMIT +
IZUDFLT.ZOSMF.SOFTWARE_DEPLOYMENT.DATA.*.DB2.** +
CLASS(ZMFAPLA) ID(IZUUSER) ACCESS(READ)

Controlling who can manage categories

By default, z/OSMF users and administrators are authorized to add, copy, modify, and remove categories. However, if you plan to use categories to authorize users to groups of software instances and deployments, it is important to control who can perform these actions. Therefore, it is recommended that you permit READ access to the following resource to z/OSMF administrators or trusted users only:

 
<SAF-prefix>.ZOSMF.SOFTWARE_DEPLOYMENT.SOFTWARE_MANAGEMENT.CATEGORIES.MODIFY

If your installation is using RACF and you want to allow only administrators to perform these actions, you can define a profile like the following:

 
RDEFINE ZMFAPLA +
(IZUDFLT.ZOSMF.SOFTWARE_DEPLOYMENT.SOFTWARE_MANAGEMENT.CATEGORIES.MODIFY) +
UACC(NONE)
PERMIT +
IZUDFLT.ZOSMF.SOFTWARE_DEPLOYMENT.SOFTWARE_MANAGEMENT.CATEGORIES.MODIFY +
CLASS(ZMFAPLA) ID(IZUADMIN) ACCESS(READ)

Users who are not permitted at least READ access to this profile can only view a list of the categories and assign categories to software instances and deployments. This is true even if other controls exist that would otherwise allow such a user to perform actions on a specific category.

Ensuring that all objects are assigned to a category

When using categories to control access to groups of software instances and deployments, it is also important to ensure that all software instances and deployments are assigned to a category. To do so, permit no users access to the following resource:

 
<SAF-prefix>.ZOSMF.SOFTWARE_DEPLOYMENT.DATA.*.NOCATEGORY.**

If your installation is using RACF and you want to force all objects to be assigned to at least one category, you can define a profile like the following and permit no users to the profile:

 
RDEFINE ZMFAPLA +
(IZUDFLT.ZOSMF.SOFTWARE_DEPLOYMENT.DATA.*.NOCATEGORY.**) UACC(NONE)

Controlling who can retrieve product information files

A product information file is a file that contains information about one or more products, such as the product announce date and end of service date. Information that is extracted from these files are displayed in several views and reports in the Software Management task, such as in the Products view and in the End of Service report.

When you retrieve a product information file, z/OSMF reads the file and loads the extracted content into the database where data for the Software Management task is stored. The scope of this action is broad and spans all products in the database; therefore, this action should be carefully controlled.

To control who can retrieve product information files, permit users READ access to the following resource:

 
<SAF-prefix>.ZOSMF.SOFTWARE_DEPLOYMENT.SOFTWARE_MANAGEMENT.PRODUCT_INFO_FILE.RETRIEVE

By default, only z/OSMF administrators are permitted READ access to this resource. That is, by default, only z/OSMF administrators can retrieve product information files.