Configuring the z/OS system for Zowe
Configure the z/OS security manager to prepare for launching the Zowe started tasks.
If Zowe has already been launched on a z/OS system from a previous release of Version 1.8 or later, then you are applying a newer Zowe build. You can skip this security configuration step unless told otherwise in the release documentation.
A SAMPLIB JCL member ZWESECUR
is provided to assist with the security configuration. You can submit the ZWESECUR
JCL member as-is or customize it depending on site preferences. The JCL allows you to vary which security manager you use by setting the PRODUCT variable to be one of RACF
, ACF2
, or TSS
.
If ZWESECUR
encounters an error or a step that has already been performed, it will continue to the end, so it can be run repeatedly in a scenario such as a pipeline automating the configuration of a z/OS environment for Zowe installation.
It is expected that security administrator at a site will want to review, edit where necessary, and either execute ZWESECUR
as a single job or else execute individual TSO commands one by one to complete the security configuration of a z/OS system in preparation for installing and running Zowe.
If you want to undo all of the z/OS security configuration steps performed by the JCL member ZWESECUR
, Zowe provides a reverse member ZWENOSEC
that contains the inverse steps that ZWESECUR
performs. This is useful in the following situations:
- You are configuring z/OS systems as part of a build pipeline that you want to undo and redo configuration and installation of Zowe using automation.
- You have configured a z/OS system for Zowe that you no longer want to use and you prefer to delete the Zowe user IDs and undo the security configuration settings rather than leave them enabled.
If you run ZWENOSEC
on a z/OS system, then you will no longer be able to run Zowe until you rerun ZWESECUR
to reinitialize the z/OS security configuration.
#
User IDs and groups for the Zowe started tasksZowe requires a user ID ZWESVUSR
to execute its main z/OS runtime started task ZWESVSTC
. This userid must have a valid OMVS segment.
Zowe requires a user ID ZWESIUSR
to execute the cross memory server started task ZWESISTC
. This userid must have a valid OMVS segment.
Zowe requires a group ZWEADMIN
that both ZWESVUSR
and ZWESIUSR
should belong to. This group must have a valid OMVS segment.
The JCL member ZWESECUR
contains the TSO commands to create the user IDs.
To create the
ZWEADMIN
group, issue the following command:To create the
ZWESVUSR
user ID for the main Zowe started task, issue the following command:To create the
ZWESIUSR
group for the Zowe cross memory server started task, issue the following command:
#
Configure ZWESVSTC to run under ZWESVUSR user IDWhen the Zowe started task ZWESVSTC
is started, it must be associated with the user ID ZWESVUSR
and group ZWEADMIN
. A different user ID and group can be used if required to conform with existing naming standards.
If you use RACF, issue the following commands:
If you use CA ACF2, issue the following commands:
If you use CA Top Secret, issue the following commands:
#
Grant users permission to access z/OSMFTSO user IDs using Zowe must have permission to access the z/OSMF services that are used by Zowe. They should be added to the group with appropriate z/OSMF privileges, IZUUSER
or IZUADMIN
by default.
If you use RACF, issue the following command:
If you use CA ACF2, issue the following commands:
If you use CA Top Secret, issue the following commands:
#
Configure the cross memory server for SAFZowe has a cross memory server that runs as an APF-authorized program with key 4 storage. Client processes accessing the cross memory server's services must have READ access to a security profile ZWES.IS
in the FACILITY
class. This authorization step is used to guard against access by non-priviledged clients.
Activate the FACILITY class, define a ZWES.IS
profile, and grant READ access to the user ID ZWESVUSR
. This is the user ID that the Zowe started task ZWESVSTC
runs under.
To do this, issue the following commands that are also included in the ZWESECUR
JCL member. The commands assume that you run the ZWESVSTC
under the ZWESVUSR
user.
If you use RACF, issue the following commands:
- To see the current class settings, use:
- To define and activate the FACILITY class, use:
- To RACLIST the FACILITY class, use:
- To define the
ZWES.IS
profile in the FACILITY class and grant Zowe's started task userid READ access, issue the following commands:where<zwesvstc_user>
is the user IDZWESVUSR
under which the ZWESVSTC started task runs. - To check whether the permission has been successfully granted, issue the following command:This shows the user IDs who have access to the
ZWES.IS
class, which should include Zowe's started task userid with READ access.
- To see the current class settings, use:
If you use CA ACF2, issue the following commands:
If you use CA Top Secret, issue the following commands, where
owner-acid
can be IZUSVR or a different ACID:Notes:
The cross memory server treats "no decision" style SAF return codes as failures. If there is no covering profile for the
ZWES.IS
resource in the FACILITY class, the request will be denied.Cross memory server clients other than Zowe might have additional SAF security requirements. For more information, see the documentation for the specific client.
#
Configure an ICSF cryptographic services environmentTo generate symmetric keys, the ZWESVUSR
user who runs ZWESVSTC
requires READ access to CSFRNGL
in the CSFSERV
class.
Define or check the following configurations depending on whether ICSF is already installed:
The ICSF or CSF job that runs on your z/OS system.
The configuration of ICSF options in
SYS1.PARMLIB(CSFPRM00)
,SYS1.SAMPLIB
,SYS1.PROCLIB
.Create CKDS, PKDS, TKDS VSAM data sets.
Define and activate the CSFSERV class:
- If you use RACF, issue the following commands:
- If you use CA ACF2, issue the following commands (note that
profile-prefix
andprofile-suffix
are user-defined):(repeat for userids IKED, NSSD, and Policy Agent) - If you use CA Top Secret, issue the following command (note that
profile-prefix
andprofile-suffix
are user defined):(repeat for user-acids IKED, NSSD, and Policy Agent)
- If you use RACF, issue the following commands:
Notes:
- Determine whether you want SAF authorization checks against
CSFSERV
and setCSF.CSFSERV.AUTH.CSFRNG.DISABLE
accordingly. - Refer to the z/OS 2.3.0 z/OS Cryptographic Services ICSF System Programmer's Guide: Installation, initialization, and customization.
- CCA and/or PKCS #11 coprocessor for random number generation.
- Enable
FACILITY IRR.PROGRAM.SIGNATURE.VERIFICATION
andRDEFINE CSFINPV2
if required.
#
Configure security environment switchingTypically, the user ZWESVUSR
that the ZWESVSTC
started task runs under needs to be able to change the security environment of its process to allow API requests to be issued on behalf of the logged on TSO user ID, rather than the server's user ID. This capability provides the functionality that allows users to log on to the Zowe desktop and use apps such as the File Editor to list data sets or USS files that the logged on user is authorized to view and edit, rather than the user ID running the Zowe server. This technique is known as impersonation.
To enable impersonation, you must grant the user ID ZWESVUSR
associated with the ZWESVSTC
started task UPDATE access to the BPX.SERVER
and BPX.DAEMON
profiles in the FACILITY
class.
You can issue the following commands first to check whether you already have the impersonation profiles defined as part of another server configuration, such as the FTPD daemon. Review the output to confirm that the two impersonation profiles exist and the user ZWESVUSR
who runs the ZWESVSTC
started task has UPDATE access to both profiles.
- If you use RACF, issue the following commands:
- If you use CA Top Secret, issue the following commands:
- If you use CA ACF2, issue the following commands:
If the user ZWESVUSR
who runs the ZWESVSTC started task does not have UPDATE access to both profiles follow the instructions below.
If you use RACF, complete the following steps:
Activate and RACLIST the FACILITY class. This may have already been done on the z/OS environment if another z/OS server has been previously configured to take advantage of the ability to change its security environment, such as the FTPD daemon that is included with z/OS Communications Server TCP/IP services.
Define the impersonation profiles. This may have already been done on behalf of another server such as the FTPD daemon.
Having activated and RACLIST the FACILITY class, the user ID
ZWESVUSR
who runs the ZWESVSTC started task must be given update access to the BPX.SERVER and BPX.DAEMON profiles in the FACILITY class.where <zwesvstc_user> is
ZWESVUSR
unless a different user ID is being used for the z/OS environment./ Activate these changes /
Issue the following commands to check whether permission has been successfully granted:
If you use CA Top Secret, complete the following steps:
- Define the BPX Resource and access for <zwesvstc_user>.where <zwesvstc_user> is
ZWESVUSR
unless a different user ID is being used for the z/OS environment. - Issue the following commands and review the output to check whether permission has been successfully granted:
- Define the BPX Resource and access for <zwesvstc_user>.
If you use CA ACF2, complete the following steps:
- Define the BPX Resource and access for <zwesvstc_user>.where <zwesvstc_user> is
ZWESVUSR
unless a different user ID is being used for the z/OS environment. - Issue the following commands and review the output to check whether permission has been successfully granted:
- Define the BPX Resource and access for <zwesvstc_user>.
#
Configure address space job namingThe user ID ZWESVUSR
that is associated with the Zowe started task ZWESVSTC
must have READ
permission for the BPX.JOBNAME
profile in the FACILITY
class. This is to allow setting of the names for the different z/OS UNIX address spaces for the Zowe runtime components. See Address space names.
To display who is authorized to the profile, issue the following command:
Additionally, you need to activate facility class, permit BPX.JOBNAME
, and refresh facility class:
For more information, see Setting up the UNIX-related FACILITY and SURROGAT class profiles in the "z/OS UNIX System Services" documentation.