Security in z/VSE is provided by the Basic Security Manager (BSM) or by security products from Independent Software Vendors (ISVs). The BSM is part of z/VSE and provides basic functionality. Customers who need more functionality (e.g., field-level security, command security) may choose an ISV product instead of the BSM. With z/VSE V3.1.1, the BSM was enhanced to support additional resources and new functions. This article offers a short overview about the changes in the BSM.

Support of CICS RSL Resources

With VSE/ESA V2.4, CICS/VSE was replaced by CICS Transaction Server for VSE/ESA (CICS TS). Unlike CICS/VSE, CICS TS has no internal security function. Instead of CICS internal security, it issues RACROUTE calls. To support these RACROUTE calls, VSE/ESA V2.4 imported the System Authorization Facility (SAF) from MVS and introduced the BSM. Initially, the BSM protected only CICS sign-on and CICS transactions. With z/VSE V3.1.1, the BSM also supports the CICS Resource

Security Level (RSL) security for these CICS resources:

• Transient data
• Files
• Journals
• Started and XPCT-checked transactions
• Application programs
• Temporary storage.

Control Terminal Users’ Access to CICS

To control the terminal users’ access to VTAM applications such as CICS, the BSM supports the resource class APPL. The users’ authority will be checked during sign-on. For example, if a user isn’t authorized to use the application DBDCCICS, the sign-on attempt will be rejected. This is an easy way to keep the user of a test CICS from using the production CICS.

General Resource Class FACILIT Y

The resource class FACILITY is for miscellaneous use by applications such as DITTO or the CICS Report Control Facility. The applications use their own resource names for access checks. For example, DITTO expects profile names of class FACLITY (e.g., DITTO.DISK.UPDATE or DITTO. DISK.INPUT) to control access to its disk accessing functions.

Flexible User Group Concept

In the past, the BSM supported the CICS security concept such as 64 transaction security keys. Instead of assigning such a security key to a user, you may connect a user to a group. For migration and maintenance reasons, we provide the groups GROUP01 through GROUP64. An installation is free to build its own groups and change the user connections as required.

New Profiles for a New Repository

With z/VSE V3.1.1, IBM introduced a VSAM-based BSM control file (VSE. BSTCNTL.FILE) for the new resource classes. It replaces the old DTSECTXN table for the CICS transactions (see Figure 1).

We call the security entries in the BSM control file profiles. A profile has a fixed part and a variable part. The fixed part contains the profile name, which is the resource name or the beginning of the resource name string for a generic profile, the name of the resource class, a universal access specification, and a description field. The variable part is the access list (see Figure 2).

The access list can be empty, or contain user IDs or groups and their access right for the protected resource. If you specify a user ID on the access list, and that ID is also part of a group that’s also on the access list, the access right of the individual user ID is used. This allows you to exclude a single user of a group from accessing a resource.

Administering Profiles in the BSM Control File

You can administer profiles either by using the Interactive Interface dialogs (fast path 28), or by using the commands of the BSTADMIN program.

The BSTADMIN program is similar to the LIBR program. It can be used in a batch job or from the console (e.g., in PAUSEBG). You can use BSTADMIN program commands to administer resource profiles and groups, activate resource classes, change password rules, and modify other BSM settings.

Migration

The Interactive Interface supports CICS transaction migration in two steps:

• Migrate the transaction security keys of each user to the group concept using the PF6 key (GROUPS) on the MAINTAIN USER PROFILE panel. It creates the job CICSICCF and stores it in the punch queue. Copy it to your primary library to change and submit it.
• Migrate the transactions defined in the DTSECTXN table to the new profiles via fast path 285. Before you start the migration, ensure you’ve merged all your DTSECTXN definitions. The migration itself follows these steps:

1. Create BSTADMIN ADD and PERMIT commands from each DTSECTXN entry.

2. Submit a batch job that executes the BSTADMIN commands and activate these changes.

3. Deactivate the DTSECTXN table.

User Profiles Enhancement

In the past, installations sometimes had problems identifying the owner of a user ID. With z/VSE V3.1.1, you can specify a 20-character programmer name in the ADD OR CHANGE USER PROFILE panel.

More Information

For more information about the BSM and how it was enhanced in z/VSE V3.1.1, access these IBM resources:

• CICS Transaction Server for VSE/ESA Security Guide (SC33-1942)
• z/VSE V3R1.1 Planning (SC33-8221)
• z/VSE V3R1.1 Administration (SC33-8224)
• http://www.ibm.com/servers/eserver/zseries/zvse/documentation/index.html.

Figure 2: Sample Profile as Displayed by the BSTADMIN Command LIST