CA-ACF2 MVS interface

From m204wiki
Revision as of 21:09, 21 November 2016 by JAL (talk | contribs) (misc cleanup)
Jump to navigation Jump to search

Overview

This topic presents an overview of how the Access Control Facility/2 (ACF2) Interface from Computer Associates, Inc. (CA) works in the IBM z/OS environment. It also describes the impact of the CA-ACF2 MVS Interface on the Model 204 user, system manager, and CA-ACF2 installation security officer. This topic also provides requirements and a conversion checklist for installing and activating the CA-ACF2 interface.

CA-ACF2 MVS

CA-ACF2 MVS provides comprehensive data security functions for the IBM z/OS operating system. CA-ACF2 MVS protects all data and installation-defined resources by default, sharing data only when explicitly requested to by the owner of the data or by a security officer. CA-ACF2 MVS differs from other security systems that force you to define what is to be protected, rather than what is to be shared.

Model 204 CA-ACF2 MVS Interface

The Model 204 CA-ACF2 MVS Interface provides for an orderly migration from Model 204 security to CA-ACF2 security and allows an installation to use a combination of either or both security methods.

The interface provides the tools and instructions needed to:

  • Define Model 204 as a CA-ACF2 Multiuser Single Address Space System (MUSASS)
  • Define the meaning of Model 204 user privileges
  • Define CA-ACF2 Generalized Resource Rules for CA-ACF2 authorization of Model 204 user login privileges
  • Define an installation default user priority class or the offset of a priority class byte within the user’s CA-ACF2 Logonid record
  • Define the offset and length of a default login account within a CA-ACF2 Logonid record, and provide account authorization services
  • Define the offset and bit within the CA-ACF2 Logonid record that determines whether or not a user can log in to a particular Model 204 job
  • Define the offset and length within the CA-ACF2 Logonid record that contains data to be used as the user’s record security key field
  • Activate the external CA-ACF2 Interface security mechanism

In summary, the CA-ACF2 MVS Interface provides all the facilities an installation site needs to implement CA-ACF2 security within the Model 204 environment.

CA-ACF2 MVS Interface components

The following figure illustrates the components of the CA-ACF2 MVS Interface, which consists of:

  • Model 204
  • ACF2 Interface module, which is linked into Model 204
  • ACF2PARM module, which can be linked with Model 204 or loaded dynamically at initialization
  • SBA20S module, which is linked into Model 204 and contains the ACFSVC macro that invokes the CA-ACF2 SVC
  • Model 204 system file, CCASTAT, which contains user IDs subject to Model 204 security
  • CA-ACF2 MVS, which retrieves data from its VSAM databases and returns it to Model 204 for processing

CA-ACF2 MVS Interface

Conversion tasks and considerations

The following checklist identifies the general tasks that must be completed to install and activate the CA-ACF2 Interface.

Conversion checklist for CA-ACF2 MVS
Step Task
1.

Define the Generalized Resource Type (204 or the value that will be specified in the ACF2GEN RESOURC argument). Change the ACFFDR system definition by adding:

  • Definition of the Model 204 authority bit, if the LOGIN argument is specified in the ACF2GEN macro
  • Definition of the default account field, if the ACCOUNT argument is specified in the ACF2GEN macro
  • Definition of the PRIORITY byte, if individual priorities are assigned to each other
  • @MUSASS macro to define Model 204 as a MUSASS
2. If an ACF2PARM module is to be linked with Model 204, execute member ACF2GEN in the installation JCL library. If ACF2PARM will be loaded dynamically, also execute SECRLINK.
3. Unload the installation software (if necessary) and assemble SBA2OS. Link Model 204 with the modules ACF2, $ACFGCVT, ACF$FGCB, SBA2OS, and ACF2PARM.
4. Insert the MUSASS Logonid that defines Model 204 to CA-ACF2. Add the default Logonid with the RESTRICT attribute.
5. Prepare batch JCL or a started task cataloged procedure to execute the defined Model 204 MUSASS name.
6. Prepare user privilege rule sets to correspond with fixed privilege names in Model 204. Specify which users are allowed or prevented from using those privileges.
7. Provide valid CA-ACF2 users the privilege to use Model 204.
8. Change User 0 input in CCAIN to include the SECPLIST=parametername parameter.
9. Delete Model 204 users from CCASTAT, forcing logins through CA-ACF2.

Brief introduction to CA-ACF2 MVS

This section provides a brief summary of key CA-ACF2 MVS features that are used in the discussion of the Model 204 CA-ACF2 MVS Interface.

For more information about CA-ACF2 MVS, see the CA Technologies documentation for that product.

CA-ACF2 processing

When a user logs in to the z/OS environment, CA-ACF2 MVS performs the following functions:

  • Validates the password found for the Logonid in the CA-ACF2 Logonid database
  • Checks for password expiration
  • Optionally, ensures that the user is accessing the system from a specific terminal or other source
  • Optionally, ensures that the user is only accessing the system during certain dates and times

System manager options

The system manager has the following additional options when a user logs in to Model 204 with a CA-ACF2 Logonid:

  • Require each user’s login to go through Login or Account validation, defined by the ACF2GEN macro
  • Set the priority for each user through the user’s Logonid record or set one priority for all CA-ACF2 users
  • Change the user’s record security key and not default to the Model 204 user ID

CA-ACF2 MVS and the CA-ACF2 MVS Interface

The Model 204 CA-ACF2 MVS Interface uses the following CA-ACF2 SVC macro calls to send validation requests to CA-ACF2:

ACFSVCA Performs login validation requests
ACFSVCS Performs DASD validation requests of sequential data, VSAM files, and new DASD space allocation.

Since validation requests are performed in the main Task Control Block (TCB) in the Model 204 job’s address space, Model 204 must be defined as a MUSASS (Multiuser Single Address Space System) to allow multiple user validation in the same address space.

Logonid record

CA-ACF2 MVS maintains a Logonid record, or LIDREC, for each user on the system and each Logonid has an associated password. All passwords are stored in an encrypted format that cannot be reversed. CA-ACF2 MVS validates users by acquiring and processing the Logonid and password during TSO LOGON, IMS SIGNON, batch job submission, CICS SIGNON, and other TP product signons (COM-PLETE or ROSCOE, for example).

Users are defined only once to CA-ACF2 MVS, regardless of how many subsystems they access. To define differing authorizations for different subsystems, users can be identified via a UID (user Identification) string.

User identification string

A UID string is a character string, up to 24 bytes long, constructed from the user’s Logonid and other site-definable fields such as department number or employee ID. CA-ACF2 MVS compares the user’s UID with the UID masks specified in a rule set to determine whether a user can have access to a resource.

UID masks

A UID mask can be placed on any rule to allow or prevent access to a resource by a group of users based on their UID string. For example, a rule in the Rules database can have a UID mask that allows everyone with a department code of DEV to have access to a certain resource.

Data access control

CA-ACF2 MVS protects all data by default from all users except the data owner. Each Logonid on the system has an owned data set prefix that controls this function.

When any user tries to access a data set, the CA-ACF2 high-level index is compared to the value of the prefix field in the Logonid record.

  • If the two are equal, access is automatically allowed.
  • If the two are not equal, CA-ACF2 MVS searches for an access rule set that governs access to that index:
    • If an access rule does not exist for that index, access is denied.
    • If CA-ACF2 MVS obtains an access rule set, the access rules are interpreted to locate one that matches the currently existing environment.
      • If a matching access rule is not found, access is denied.
      • If a matching access rule is located, the purpose of the access request is compared with the read, write, allocate, and execute-only permission values specified in the access rule, and access is either allowed, allowed and journaled, or prevented and journaled.

CA-ACF2 MVS uses character string patterns to perform the validation matching function. The patterns can define the data set, volume, UID string, program library, and program name fields in the Logonid to be verified.

Generalized Resource control

CA-ACF2’s Generalized Resource Rules are similar to data access control rules. However, they control access to resources other than files. These system resources can be defined either by CA-ACF2 MVS or by each site locally.

By allowing each site to specify which local resources require security protection, the rules for a data processing installation can be complex enough to define any arbitrary or real system resources needed. Generalized Resource Rules typically are used for TSO account numbers, IMS transaction names, and CICS transaction names.

Model 204 user login privileges are defined as general system resources, and local installation rules control who can use those resources. These rules are written by the Model 204 system manager and the CA-ACF2 MVS installation security officer. For more information, see Defining corresponding Generalized Resource Rules.

Running the CA-ACF2 MVS Interface with Model 204

A Model 204 multiuser Online always runs as a CA-ACF2 MUSASS (Multiuser Single Address Space System). A MUSASS is defined by CA-ACF2 MVS as any program that runs as a single job in one address space that supports more than one user.

Other Model 204 configurations such as BATCH204 and IFAM1 do not normally run as a MUSASS, because only a single user’s authorization is in question.

IFAM4 might run as a MUSASS, but each IFAM4 user application must also be APF-authorized in addition to the IFAM4 Load Module, otherwise the multiple IFAM4 threads must log in as the same user.

Model 204 user privileges

In either a MUSASS or single-user environment, Model 204 queries CA-ACF2 MVS for the authority to grant access to various system resources on behalf of the user. User privileges are defined as resources to be protected, and rules are written to determine who is authorized to use of those resources.

Managing the authorization process

In a MUSASS, Model 204 manages the authorization process because only Model 204 can identify which user initiates a request for a resource. Model 204 assists CA-ACF2 MVS in validating those requests and responds to users who issue requests for unavailable resources.

The three distinct areas where Model 204 interfaces with CA-ACF2 MVS are:

  • User logins
    • LOGIN/LOGON command
    • IFSTRT function
    • IFLOG function
  • User resource requests
    • Job submission (USE $JOB command)
    • Dynamic allocation of new DASD space (ALLOCATE command)
    • All sequential file and VSAM file opens for READ/WRITE access
    • Sequential data set handling (record I/O)
    • DUMP/RESTORE commands
    • OPEN command naming a deferred update data set

    Note: Because Model 204 databases are not validated on behalf of the user by the security interface, CA-ACF2 MVS must grant the owner of an address space permission to open Model 204 file data sets for update, regardless of whether the owner has write or read-only privileges. This allows Model 204 to write back updates to the FPL (File Parameter List) page, as required by the database management system, regardless of the Model 204 file open privileges.

  • User logouts
    • LOGOUT/LOGOFF command
    • IFFNSH/IFDTHRD function

The CA-ACF2 MVS Interface uses the standard SVC calls supplied by Computer Associates, Inc. (CA) to validate user requests for Model 204 resources. No source code modifications or exits to the CA-ACF2 MVS software are necessary. However, CA-ACF2 MVS system parameters must be modified as described in Preparing the ACF2PARM parameter module with ACF2GEN.

Using the CA-ACF2 MVS Interface

This section describes how to log in to Model 204 and identifies the changes required for:

  • LOGIN/LOGON
  • IFSTRT function
  • IFLOG function within IFAM1
  • Dynamic allocation
  • Job submission
  • Sequential and VSAM data set handling

LOGIN or LOGON command

The LOGIN/LOGON command allows you to gain access to Model 204. To log in, enter:

LOGIN userid [account]

or

LOGON userid [account]

where:

userid Is a character string that identifies you.
account Is an optional character string that identifies the account under which you log in.

If Model 204 is providing security authorization checks, every Model 204 user has a user ID, password, and user privileges assigned by the system manager consisting of:

  • User ID that identifies you to Model 204
  • Password that provides access to the system. Note that Model 204 versions 7.7 and later also support passphrases.
  • User privileges associated with your user ID and password that define the particular type of access you have
  • Default priority class assigned to your user ID

When native Model 204 security is in effect, this user ID information is stored in a record in the system file CCASTAT. This record can be deleted from CCASTAT when the system manager puts the user under CA-ACF2 MVS security. The ACF2PARM module supplies a default Logonid for CCASTAT login access validations. In addition, ACF2PARM defines the following:

  • Other CA-ACF2 ID validations to be done at login
  • Login validation for the particular Model 204 job
  • Defaults and/or location within the your CA-ACF2 Logonid record where the data can be found

When CA-ACF2 MVS is performing login validation, the user ID (that is, the Logonid) must be eight characters or fewer. The user ID is verified by CA-ACF2 MVS before you can log in to Model 204.

If your installation performs CA-ACF2 account validation, any value entered in the account field is verified via CA-ACF2 services. If you do not enter an account, a default account is supplied from the CA-ACF2 user Logonid record as discussed on the LOGIN or LOGON command page.

Changing your password

You can change your CA-ACF2 Logonid password when you log in to Model 204. See the LOGIN or LOGON command page for more information.

Passphrases

If CA-ACF2 MVS is configured to support passphrases, they can be used with Model 204 version 7.7 and later. Passphrases are 9-127 characters long and can contain any special characters (such as blanks, commas, and semicolons) supported by CA-ACF2 MVS. See Setting a password on the LOGIN or LOGON command page for more information.

IFSTRT function

In the IFAM1 and IFAM4 environments, the IFSTRT function allocates a Host Language Interface thread for a Host Language program. IFSTRT also establishes the calling convention, performs a user login, and determines whether the thread has update privileges.

When processing the login argument of the IFSTRT call, the user login process follows the rules of a User 0 login (unless you have defined IFAM4 as a MUSASS and APF-authorized all user applications). See User 0 login for more information.

IFLOG function within IFAM1

The IFLOG function is used only in the IFAM1 environment. It is called following IFSTRT to identify the user when a login is required. This function is necessary in any IFAM1 program where CA-ACF2 MVS validates user authorization.

As with the IFSTRT function, the user login process is the same as the process for User 0 login.

Dynamic allocation considerations

Dynamic allocation services for new data sets in a CA-ACF2 environment are subject to CA-ACF2 system rules for data set validation. For example, you can restrict data set allocation to only allow certain data set name patterns to be created on certain predefined volumes. The rules for data set access are determined by the CA-ACF2 installation security officer.

To dynamically allocate a new data set, you must have ACF2 ALLOC authority in CA-ACF2. If you issue an ALLOCATE command for a new data set and you do not have ALLOC authority, you receive a Model 204 error message.

If you log in to Model 204 via CCASTAT, your allocation privileges are determined by the CA-ACF2 default user’s Logonid authorization.

Note: When you open a new or existing sequential or a VSAM data set, it is validated for read/write access. CA-ACF2 does not perform access authorization on Model 204 data sets, because these data sets are currently protected under Model 204 security.

Job submission considerations

When you issue a USE command to submit a batch job, Model 204 must identify who submitted the job so that CA-ACF2 MVS can properly determine the authorization for that execution. When the CA-ACF2 MVS Interface is running, the following JCL statement is added automatically to the submitted job to identify the user and the user’s level of authorization:

//*JOBFROM userid | source

where:

userid Is your Model 204 user ID. CA-ACF2 MVS uses your ID to determine your batch job authorization at execution time.
source Identifies the terminal, using TERMID, from which you submit the job. If you are connected via a CRAM interface, such as TSO, CICS, or IFDIAL, the source becomes the appropriate CRAM channel name that was used to gain access to Model 204.

CCASTAT IDs use the default Logonid defined in the ACF2PARM module. The source is the job name, and User 0’s source is also the job name.

Neither you nor the system manager can modify this information. If you supply your own //*JOBFROM userid/source statement, the system-supplied statement overrides it.

To submit a job, the Model 204 Online requires the correct authority, which means:

  • MUSASS ID must have JOBFROM privileges.
  • All user IDs must have TSO SUBMIT permission to issue USE $JOB.
  • If the TSO option of JOBCK is specified, a user ID and the MUSASS ID must have JOB privileges to submit jobs with the USE $JOB command.

Model 204-submitted jobs go directly to the internal reader. If the local site has a TSO SUBMIT exit in effect to enable you to modify submitted jobs, the exit does not receive control.

To submit batch jobs, you must be defined to CA-ACF2 MVS as having the authority to do so. Model 204 checks the standard CA-ACF2 TSO JCL/SUBMIT attribute flag to determine whether or not you have the authority to submit JCL. If you are not authorized to submit a job, you receive a Model 204 error message.

Sequential and VSAM data set considerations

To use a sequential or VSAM data set, you must have the appropriate Model 204 privileges. CA-ACF2 MVS does an authorization check to ensure that you have the appropriate privileges:

With these privileges... You can...
CA-ACF2 write privileges Open a deferred update data set or write to the output sequential files of the DUMP, DUMPG, or USE data set commands
CA-ACF2 read privileges Read sequential or VSAM files from User Language or read the sequential input file specified in a RESTORE or RESTOREG command
ALLOC authority Dynamically allocate a new data set (any new DASD space)

If you issue a sequential or VSAM data set OPEN command that fails for CAACF2 reasons, a Model 204 error message is displayed.

If you log in to Model 204 via CCASTAT, the CA-ACF2 default user’s LIDREC determines your authorization.

Model 204 sequential file data sets (such as CCASTAT, CCAAUDIT, CCAJRNL, or CCAJLOG) are also checked to determine if the owner of the address space has the authority to write to them.

The CA-ACF2 Interface directly checks the following Model 204 commands:

Login processing

The system manager is responsible for defining and controlling security processing in a Model 204 installation in which CA-ACF2 MVS supplies authorization services. This section describes the login processing performed by the interface.

When a user logs in

  1. When a user logs in, Model 204 acquires the user ID and account and searches CCASTAT to determine whether or not that Model 204 user ID exists.
    • If the user ID is found, Model 204 queries the user for a password and proceeds with authorization processing.
    • If the user ID is not found in CCASTAT and CA-ACF2 MVS security is in effect, Model 204 uses CA-ACF2 facilities to authorize the user login. Model 204 passes the Logonid and password to CA-ACF2 to verify that the user is allowed to log in. After the user’s CA-ACF2 user ID and password are verified, CA-ACF2 presents the user’s Logonid record to Model 204.
  2. Next, if the authorization check to use Model 204 is active, Model 204 examines the CA-ACF2 Logonid record to ensure that the user is allowed to use Model 204. If this check is successful, account processing occurs.

If a default account location and length were specified at installation time and the user does not enter an account, the default account is retrieved from the user’s Logonid record and the user is allowed in to Model 204.

Verifying the login account

If the installation has chosen to verify the account, the value entered is compared to the user’s default account. If the values match, the user is allowed in to Model 204. If the values do not match, standard CA-ACF2 account validation is performed to ensure that the user is allowed to log in under the specified account.

If CA-ACF2 denies system access because of an invalid password or account, or if the user is not authorized to use Model 204, no login occurs and Model 204 issues an error message. In addition, any login failure caused by entering an invalid password counts against the user’s CA-ACF2 password violation counter. This counter is maintained by CA-ACF2 and, when the count reaches an installation maximum, CA-ACF2 suspends the user.

Once the user has successfully logged in, the user is granted Model 204 privileges of X‘00’. Any additional privileges are determined at the time a Model 204 command requires a specific privilege.

CCASTAT considerations

To provide a smooth transition from Model 204 security to CA-ACF2 security, user ID data can continue to be stored in CCASTAT. As users become secured by CA-ACF2, delete the standard Model 204 CCASTAT user ID entries.

All the system manager commands concerning CCASTAT maintenance functions continue to work as usual. The ZBLDTAB and ZCTLTAB utilities also continue to work as usual.

File, group, and subsystem security functions are defined and described in the File management and System management M204wiki pages.

User 0 login

When the CA-ACF2 MVS Interface is active, User 0 is validated as the owner of the Model 204 run, regardless of whether the run is Online or BATCH204.

Model 204 always attempts to log in User 0 automatically and verify that the user ID supplied matches the user ID of the owner of the address space. Do not supply a user ID or password on the login command for User 0; Model 204 determines the owner user ID and supplies it automatically.

AUTHCTL VIEW command

The AUTHCTL VIEW command displays the interface control options currently in effect for the active interface (CCASTAT and ACF2GEN).

For example, if you enter the following command:

AUTHCTL VIEW

or

AUTHCTL VIEW ACF2

A list similar to the following is displayed:

ACF2 INTERFACE OPTIONS RESOURCE JST ACF2 RESOURCE TYPE LOGIN X'0172' AUTHORITY BYTE OFFSET IN LIDREC X'80' BIT DEFINING MODEL204 AUTHORITY ACCOUNT X'0176' ACCOUNT OFFSET IN LIDREC X'04' ACCOUNT LENGTH RECSCTY X'0000' RECORD SECURITY KEY OFFSET IN LIDREC X'00' RECORD SECURITY KEY LENGTH PRIORITY LOW PRIORITY DEFAULT OR OFFSET IN LIDREC VALIDATE ACCOUNT VALIDATION OPTION IN EFFECT DLMCHECK USE $JOB DLM CHECKING OPTION M204USER DEFAULT LOGONID IN USE

The last line displayed indicates the current default Logonid in use. For more information, refer to Inserting a CA-ACF2 default Logonid.

For information about setting control information, see Preparing the ACF2PARM parameter module with ACF2GEN.

Using trusted login for CRAM users

If your site uses CRAM, you can use the trusted login feature, which allows users to issue login commands or calls that do not include a user ID and password. For a user to log in as trusted, the user ID must be defined to CAACF2 MVS. User IDs defined to CCASTAT are not allowed to log in as trusted users. CICS users must be using the CA-ACF2 MVS interface for CICS. Only CICS user IDs that log in through CA-ACF2 can log in as trusted users.

Trusted login can be used with the following CRAM thread IODEV types:

  • IODEV11 (CRFSCHNL)
  • IODEV29 (CRIOCHNL)
  • IODEV23 (IFAMCHNL)

To set up trusted login for a user, set the SECTRLOG user parameter, as discussed in Setting the SECTRLOG parameter.

Login processing for trusted login

For users connecting with a CRAM thread that allows trusted login, the user login processing routines are changed to handle a LOGIN command or IFSTRT call without a user ID and password.

  • The CRFS and CRIO channel threads handle User Language statements. These users ordinarily issue a LOGIN or LOGON request with the following format:
    • version 7.6 and earlier:

      LOGIN userid [account];password [:new password];apsyname

    • version 7.7 and later:

      LOGIN userid [account];password;apsyname

    For trusted logins, the format is:

    LOGIN;;apsyname

  • The IFAM channel threads handle IFAM2 statements. These users ordinarily issue an IFSTRT or IFSTRTN call with the following format:

    IFSTRT (RETCODE,LANG_IND,LOGIN,THRD_TYP,THRD_ID) IFSTRTN (RETCODE,LANG_IND,LOGIN,THRD_TYP,THRD_ID,CHAN)

    The LOGIN parameter is required and supplies the user ID and password as a character string using the following format:

    • version 7.6 and earlier:

      'userid [account];password [:new password];'

    • version 7.7 and later:

      'userid [account];password;'

    For trusted logins, the statement format is the same but the login character string is a semicolon surrounded by single quotes (';').

Trusted login errors

When using trusted login, you might receive one of the following errors:

  • M204.2378: SECURITY TRUSTED LOGIN FEATURE DISABLED

    This message is generated when either:

    • The Model 204 job requesting the trusted login feature is running without a Model 204 Security Interface.
    • The Model 204 address space does not have enough storage to allocate an internal work area for the trusted login feature. In this situation, the Model204 job does not initialize, because it still has to allocate storage for the Model 204 file buffers.
  • M204.2379: INVALID TRUSTED USERID LENGTH = length.

    This message is issued when the trusted user ID passed by CRAM is not between 1-8 bytes long.

Maintaining the CA-ACF2 MVS Interface

At each CA-ACF2 MVS site, the installation security officer (ISO) performs systemwide maintenance functions within CA-ACF2 MVS. This section describes the role of the security officer in maintaining the Model 204 CA-ACF2 MVS Interface.

Defining user privileges

The security officer must identify Model 204 privileges to CA-ACF2 MVS.

The Model 204 login privileges for CA-ACF2 MVS users are defined as Generalized Resource Rules. The RESOURC argument of ACF2GEN is used along with fixed CA-ACF2 key names. If an argument is not specified, RESOURC defaults to 204.

User privilege names

The following set of user privilege names define the possible privilege rules for a user. See the LOGCTL command page for more information on the LOGCTL settings.

User privilege name Defines users...
‘PRIV.SUPER.USER’ With Superuser privileges. A superuser can create a file with the CREATE command. This privilege name corresponds to the LOGCTL setting X‘80’.
‘PRIV.SYSTEM.ADMIN’ With System Administrator privileges. A system administrator can issue commands such as LOGWHO, MONITOR, PRIORITY, and WARN. This privilege name corresponds to the LOGCTL setting X‘40’.
‘PRIV.CHANGE.FILE.PASSWORD’ Who can change CCASTAT file passwords when opening a file. This privilege name corresponds to the LOGCTL setting X‘20’.
‘PRIV.SYSTEM.MANAGER’ Who can issue system manager commands. A system manager can issue all system administrator commands plus certain other privileged commands. This privilege name corresponds to the LOGCTL setting X‘08’.
‘PRIV.OVERRIDE.RECORD.SECURITY’ Who can override record security. This privilege name corresponds to the LOGCTL setting X‘04’.

CCASTAT users

For CCASTAT users, privileges are defined to the CCASTAT user ID by the Model 204 LOGCTL command.

Note: The LOGCTL command contains an additional privilege bit (X'10') that indicates whether or not CCASTAT users can change their own login passwords at login time. This privilege bit is not required for the Interface, because you set this privilege for all CA-ACF2 MVS users within CA-ACF2.

Defining corresponding Generalized Resource Rules

Generalized Resource Rules that correspond to the defined privileges must be defined to CA-ACF2 MVS. The rules (and ACF command) to define the standard Model 204 privileges to CA-ACF2 are as follows:

ACF (Begins CA-ACF2 rule maintenance) SET RESOURCE (Sets CA-ACF2 to resource mode) *COMPILE $KEY(PRIV.SUPER.USER) TYPE(acf2type) UID(authorized user) ALLOW UID(unauthorized user) PREVENT . . . $KEY(PRIV.SYSTEM.ADMIN) TYPE(acf2type) UID(authorized user) ALLOW . . . $KEY(PRIV.CHANGE.FILE.PASSWORD) TYPE(acf2type) UID(authorized user) ALLOW . . . $KEY(PRIV.SYSTEM.MANAGER) TYPE(acf2type) UID(authorized user) ALLOW . . . $KEY(PRIV.OVERRIDE.RECORD.SECURITY) TYPE(acf2type) UID(authorized user) ALLOW . . . STORE END

where:

PRIV.privilege.type Specifies one of the fixed privilege names (discussed in User privilege names) that Model 204 uses to build CA-ACF2 retrieval search keys for the rules
acf2type Is the Generalized Resource Type field as defined to Model 204 by the ACF2GEN RESOURC argument

The CA-ACF2 UID entry referred to here either allows or prevents a specified user from accessing that named resource.

A privilege rule is tested whenever a user issues a command that requires a specific privilege. If the user is authorized to have that privilege, the command succeeds. If not, the user typically receives a Model 204 error message and the attempt is logged as a CA-ACF2 violation.

Setting up the rules and masking patterns is a detailed process and is not described fully here. Information regarding setting up CA-ACF2 UID strings and writing rules using masks referring to these strings is documented in the CA-ACF2 MVS documentation from CA Technologies.

Preparing the ACF2PARM parameter module with ACF2GEN

The ACF2PARM module allows you to define CA-ACF2 MVS arguments for your site. ACF2PARM consists of one or more ACF2GEN macros that are coded, assembled, and generated by your site.

The ACF2GEN macro generates a named set of arguments that govern login and other security processes. At run time one of these named sets is used by the CA-ACF2 MVS Interface. The ACF2PARM parameter module can be linked with Model 204 or dynamically loaded when the CA-ACF2 Interface is initialized.

SECPLIST parameter

The SECPLIST User 0 parameter in CCAIN allows you to specify the name of the ACF2GEN argument set to initialize the interface. The name is defined by the assembler label name of the ACF2GEN macro.

If the SECPLIST parameter is not in CCAIN, ACF2PARM is used as the default name of the argument set. If no match is found for the SECPLIST name or the ACF2PARM default name in the ACF2PARM module, the interface is initialized using the precoded default parameters of the CA-ACF2 Interface. In this case, Login, Account, and Record Security Key validation are not performed.

ACF2GEN macro

The JCL needed to assemble ACF2PARM is in the installation JCL library (as member ACF2GEN).

The format of the ACF2GEN macro is as follows:

TITLE 'GENERATE AN ACF2 PARAMETER MODULE' NAME ACF2GEN RESOURC=204, ACF2 resource type X LOGIN=(0,0), Login ensure position and bit X ACCOUNT=(0,0), Account position and length X RECSCTY=(0,0), Record secty key position & length X VALIDAT=, Account validation X PRTY=, Priority position X LOGONID=M204USER, Default Logonid X NODLMCHECK/DLMCHECK Perform DLM check ACF2GEN TYPE=END End of macro definitions END

Where:

NAME Defines the name of this set of CA-ACF2 arguments. Because any number of argument sets can be in the ACF2PARM module, each set must be given a unique name. Use the default name of ACF2PARM for one of the argument sets in case a SECPLIST is not specified.
RESOURC argument Specifies the 3-character CA-ACF2 Generalized Resource Type code for this argument set. The Generalized Resource Rules for Model 204 privileges are defined and grouped by this code and stored in CA-ACF2. The code must match the Generalized Resource Type code described to CA-ACF2 in the ACFFDR statements for your site. The default is 204.
LOGIN argument Specifies the position and bit mask in the Logonid record that determines if a user is allowed to log in to Model 204. If you specify position, the CA-ACF2 MVS Interface determines if the appropriate bit is set before allowing access. If you do not specify position, all users have access to Model 204, provided that they pass the user ID/password and optional account validation.

The rules for specifying position and bit mask are:

  • position indicates the offset within the CA-ACF2 Logonid record where the data is stored. To verify the position, look in the LIDREC DSECT of the ACFFDR listing.

    Specify position as a hexadecimal value (X'nnnn').

  • bitmask indicates which bit within the byte at the specified location is being tested. Specify bit mask as a hexadecimal byte (X'mm').
  • If you specify LOGIN, the operands must be separated by a comma and enclosed within parentheses.
  • ACCOUNT argument specifies the position and length within the Logonid record where the user’s default account can be found. If there is a position defined, and the user does not enter an account while logging in, the account in the user’s Logonid is used.

    The rules for specifying position and length are as follows:

    • position indicates the offset within the CA-ACF2 Logonid record where the data is stored. To verify the position, look in the LIDREC DSECT of the ACFFDR listing.

      Specify position as a hexadecimal value (X'nnnn').

    • length is a hexadecimal value from 1 to 10.

      If you specify ACCOUNT, the operands must be separated by a comma and enclosed within parentheses.

  • The RECSCTY argument specifies the position and length within the Logonid record where the user’s default record security key can be found. This value overrides the standard Model 204 record security key, which defaults to the user ID.

    The rules for specifying position and length are as follows:

    • position indicates the offset within the CA-ACF2 Logonid record where the data is stored. To verify the position, look in the LIDREC DSECT of the ACFFDR listing.

      Specify position as a hexadecimal value (X'nnnn').

    • length is a hexadecimal value from 1 to 10.

      If you specify RECSCTY, the operands must be separated by a comma and enclosed within parentheses.

  • The VALIDAT argument has only one valid parameter, ACCOUNT, which specifies that any account entered by the user during the login process that does not match the LIDREC default account value is validated by CAACF2.

    VALIDAT=ACCOUNT compares the account value entered by the user to the value in the user’s Logonid. If the values match, the user is allowed in to Model 204. If the values do not match, the account entered by the user is validated against the standard CA-ACF2 Resource type TAC (refer to the CA-ACF2 System Programmer’s Guide for more information). If this validation is successful, the user is allowed into Model 204. Otherwise, the login fails.

  • The PRTY argument specifies the default user priority or a position within the CA-ACF2 Logonid where a priority character can be found. PRTY options are:
    • Priority specified by a one-character value:
      H (high)
      S (standard)
      L (low)
      N (none)

      PRTY=priority indicates the default user priority for all users logged in under CA-ACF2.

    • position indicates the offset within the CA-ACF2 Logonid record where the data is stored. To verify the position, look in the LIDREC DSECT of the ACFFDR listing.

      Specify position as a hexadecimal value (X'nnnn').

    The default priority is Standard if the PRTY keyword is omitted or if an invalid character is found at the specified offset in the Logonid record. For more information about priorities, refer to Priority scheduling.

  • The LOGONID argument specifies the 1- to 8-character default Logonid described earlier in this section.

    If this field is left blank, CCASTAT-defined users are not allowed to log in to Model 204. Only valid CA-ACF2 users can utilize the running system.

    If this value is specified as JOBLID, the Logonid of the executing job is used as the default Logonid.

  • The DLMCHECK/NODLMCHECK argument specifies DLM processing options for jobs submitted through the internal reader using the USE $JOB command. The DLM parameter on a DD * or DD DATA statement allows users to submit jobs that can, in turn, submit other jobs. This can potentially compromise security. The DLMCHECK argument allows you to prevent additional parameters from being processed when coding the DLM= parameter.

    DLM processing options are as follows:

    • DLMCHECK requires that if a DLM= parameter is used in a JCL stream, it must be the only parameter supplied. In this case, only the following forms of these statements are correct:

      //DDNAME DD *,DLM=';;' //DDNAME DD DATA,DLM='&&&&'

      In the statements above, DLM follows the rules described in IBM JCL documentation: any other parameters supplied result in an error. If there is a job statement following the offending statement, Model 204 inserts //*JOBFROM after the JOB statement set and treats it like an independent job.

    • NODLMCHECK checks only the validity of the DLM= parameter and does not look for the other parameters that can be specified on the JCL statement. All JCL statements after the DLM= parameter are sent to the internal reader without being checked.

      NODLMCHECK does not guarantee that an error on the statement with the DLM= parameter is caught before submission. In case of an error, the JCL following the offending statement is submitted with the CAACF2 authority from the MUSASS.

      The default is DLMCHECK.

Sample ACF2PARM module

The following ACF2PARM module contains two sets of ACF2 arguments.

  • In the first set, the name is LOG1 and account security is in effect. If the user is logged on through CCASTAT, the default Logonid is M204USER.
  • In the second set, the name is LOG2 and both account and login security are in effect. In addition, if the user is logged on through CCASTAT, the Logonid of the executing job is considered the default Logonid.

TITLE 'ACF2PARM MODULE' LOG1 ACF2GEN RESOURC=204, X LOGIN=(0,0), X ACCOUNT=(X'0141',X'0A'), X RECSCTY=(0,0) X VALIDAT=ACCOUNT, X PRTY=S, X LOGONID=M204USER, X DLMCHECK LOG2 ACF2GEN RESOURC=204, X LOGIN=(X'012F',X'04'), X ACCOUNT=(X'0132',X'0A'), X RECSCTY=(0,0) X VALIDAT=ACCOUNT, X PRTY=S, X LOGONID=JOBLID, X DLMCHECK ACF2GEN TYPE=END END

Installing the Model 204 CA-ACF2 MVS Interface

Follow these steps to install the CA-ACF2 MVS Interface.

  1. Assemble SBA2OS.
  2. Assemble ACF2PARM and optionally link it as a separate load module.
  3. Link-edit Model 204.
  4. Define Model 204 as a CA-ACF2 MUSASS.
  5. Add the @MUSASS macro to ACFFDR.
  6. Define Logonid fields for Model 204.
  7. Insert a CA-ACF2 default Logonid.
  8. Define Model 204 user privileges.
  9. Update CCAIN with the SECPLIST parameter.

Terminal security considerations

ACF2 can enforce terminal security when a user logs in. At that time, the source of the login is passed to CA-ACF2. For systems running Model 204 with the SNA Communications Server (formerly VTAM) interface, Model 204 recognizes the terminal name and stores it for use.

Model 204 configurations that use CRAM (TSFS, CICS, IFDIAL) must use the CRAM channel name instead of the terminal ID as the user source, because there is no secured mechanism in CRAM for identifying the source of the user. Because CRAM channel names can be identified as valid sources, the Logonids allowed to use those sources can be validated. Using the CRAM channel name temporarily ensures that entry to Model 204 is from an approved source.

CRAM sites can also use the trusted login feature to allow users to log in to Model 204 without supplying a user ID. See Using trusted login for CRAM users for more information.

Assembling SBA2OS

All CA-ACF2 MVS Interface users must assemble SBA2OS.

Assemble SBA2OS with the CA-ACF2 macro library. To assemble SBA2OS, customize and run the supplied SBA2ASM JCL member from your Model 204 JCLLIB (PDS data set) and place the object code in the Model 204 object library (OBJLIB). Follow the instructions in the JCL comments to customize the job; it expects the source to come from the Model 204 macro library (MACLIB).

Assembling ACF2PARM

The JCL needed to assemble ACF2PARM is in the installation JCL library (as member ACF2GEN). Refer to Preparing the ACF2PARM parameter module with ACF2GEN for more information on ACF2GEN.

The result of the assembly of the ACF2GEN macro can be link-edited to an authorized library for retrieval during Model 204 initialization, or provided at the time of the Model 204 link-edit.

Optionally linking ACF2PARM as a separate load module

If you link ACF2PARM as a separate load module, use the SECRLINK job in the JCL library. Modify the job according to the comments.

If you link ACF2PARM with the Model 204 configuration, add the following line in SYSLIN for the link-edit steps for Online, BATCH204, IFAM1, and IFAM4:

INCLUDE OBJLIB(ACF2PARM)

Link-editing Model 204

To link Model 204, make the following changes to Model 204 link-edit JCL and control statements (for the link-edit of the Online, BATCH204, IFAM1, and IFAM4 load modules) in order to include the interface modules supplied by Computer Associates, Inc. (CA) and used by the CA-ACF2 Interface. The actual data set names used for the CA-ACF2 modules depend on your site. An example of the JCL statement is:

//ACFLIB DD DSN=SYS1.ACFAMOD,DISP=SHR

The corresponding link-edit statements to add to the current Model 204 link-edit input are:

INCLUDE ACFLIB($ACFGCVT) INCLUDE ACFLIB(ACF$FGCB) INCLUDE OBJLIB(SBA2OS) INCLUDE OBJLIB(ACF2)

Customize the JCL according to the comments in the job before running it. When the job successfully completes, the new load modules must be copied back into the Model 204 load library, which replaces the old load modules.

In order for Model 204 to execute as a MUSASS, Model 204 must be linked into an APF-authorized library. This means that any Online configuration, or batch jobs that perform multiple logins for different user IDs, must be linked to an authorized library.

Note: All concatenated members of a STEPLIB must be APF-authorized for the Model 204 LOADLIB to stay APF-authorized.

BATCH204 or IFAM can be linked to a nonauthorized library, because the user who logs in is the same user who starts the job, or the user logs in with a user ID that is on CCASTAT. Any other CA-ACF2 Logonid fails.

Defining Model 204 as a CA-ACF2 MUSASS

The Model 204 Online is a MUSASS (Multiuser Single Address Space System) to CA-ACF2. A MUSASS provides services to many users through its own processing; however, CA-ACF2 is aware only of the maintask in the address space (in this instance, Model 204).

To define an Online MUSASS to CA-ACF2, CA-ACF2 must be modified through the @MUSASS macro supplied by Computer Associates, Inc. (CA) in order to identify one or more Model 204 Online environments as a MUSASS. This process defines the named Online environment as having the appropriate CA-ACF2 privileges to perform services on behalf of Model 204 users.

This definition process is necessary only for the job that starts a Model 204 Online execution with many users. It need not be performed for IFAM1/IFAM4 or for any copies of Model 204 that run as BATCH204, because these do not issue protected MUSASS service calls when running only one user Logonid. Defining a formal MUSASS to CA-ACF2 provides better control of the address space.

When defining a MUSASS, you can ensure that an Online MUSASS is not canceled in case of a security violation by specifying the NON-CNCL attribute.

Use the NON-CNCL attribute rather than an z/OS non cancellable PPT entry to achieve this, because a security violation can cause non cancelable loops in Model 204. It is valid to have Model 204 marked as non cancellable to z/OS, as long as the CA-ACF2 Logonid describing the MUSASS also has the NONCNCL attribute.

The steps in the definition process are:

  1. Select a name and insert a Logonid for the MUSASS.
  2. Define an @MUSASS macro in the ACFFDR.

The following example illustrates how to create a MUSASS Logonid through the ACF command in either TSO or with a batch job:

INSERT MODEL204 NAME(MODEL 204 MUSASS PROGRAM) - MUSASS - NO-SMC - SECURITY ACCOUNT NON-CNCL JOBFROM

where:

MODEL204 Is the name of the job or started task running as a MUSASS.

Note: The name following the INSERT (here, MODEL204), must be the same as the name in the @MUSASS entry.

Adding the @MUSASS macro to ACFFDR

The following modification must be made to the standard CA-supplied macro definitions. The ACFFDR must be reassembled as described in the CA-ACF2 documentation.

The @MUSASS entry that must be made in the ACF2 Field Definition Record (ACFFDR) follows:

@MUSASS MODEL204,MLID=ACF2,FASTPTH=YES,CACHE=NO

where:

MODEL204 Is the logonid of the submitted Online system or started task that executes Model 204.
Other options Are installation-definable options to control the storage and processing of rules.

No specific options are required for the operation of the CA-ACF2 Interface.

Defining Logonid fields for Model 204

In CA-ACF2, the Logonid record contains all information for a defined user of a computer system. Depending on the parameters specified in one or more ACF2GEN macros, you might need to add fields to the Logonid records.

The optional CA-ACF2 MVS Interface features that might require fields in the Logonid record are:

  • Login validation (see the ACF2GEN LOGIN parameter)
  • Account validation (see the ACF2GEN ACCOUNT parameter)
  • Individual user priorities (see the ACF2GEN PRTY=position parameter)

To add fields to the Logonid records:

  1. Add the assembler field definitions to the USERLID extension of the CAACF2 LIDREC.
  2. Add @CFDE entries to the ACFFDR.

The following sample illustrates how to define a field in CA-ACF2 that is tested for user authority to log in to various Online copies of Model 204.

Assume the following field definition exists in the USERLID extension of CAACF2 LIDREC:

M204AUTH DS X M204 authority to use privilege M204TEST EQU X'01' may use M204TEST online M204PROD EQU X'02' may use M204PROD online

The following @CFDE entries would be made in the ACFFDR to define the CA-ACF2 maintenance requirements. These attributes could then be assigned specific CA-ACF2 Logonids.

@CFDE M204TEST,M204AUTH,BIT, may use TEST M204 BITMAP=M204TEST, use this bit GROUP=2,ALTER=SECURITY, secty group and admin auth LIST=ALL, who can list data FLAGS=NULL+RESTRICT,PRTN=3,RRTN=3 field default/list routines @CFDE M204PROD,M204AUTH,BIT, may use production M204 BITMAP=M204PROD, use this bit GROUP=2,ALTER=SECURITY, secty group and admin auth LIST=ALL, who can list data FLAGS=NULL+RESTRICT,PRTN=3,RRTN=3 field default/list routines

These examples illustrate the relationship between the LIDREC field and usage of that field on the @CFDE definition. The GROUP, ALTER, LIST, and FLAGS keywords are variable depending on local requirements.

When these modifications are incorporated into an ACFFDR and reassembled and relinked, each user Logonid can be given the authority to use the attribute of M204PROD and/or M204TEST.

If the M204AUTH field is at Logonid location x‘22F’, the LOGIN parameter in ACF2GEN for the test MODEL204 address space indicates:

ACF2GEN ....other entries...,LOGIN=(X'22F',X'01')

This also illustrates how other fields are defined for use by Model 204, with the exception of different field lengths and the CA-ACF2 specification necessary to work with these fields.

Inserting a CA-ACF2 default Logonid

When Model 204 is executing as a MUSASS, the CA-ACF2 MVS Interface might require a default Logonid. This default Logonid limits the authorization of users who are still defined in CCASTAT. Each user not logged directly into CAACF2 is assigned the authorization of the default Logonid. This Logonid defaults to M204USER, unless it has been changed by the installation via the ACF2PARM module.

The default user’s Logonid must be inserted in CA-ACF2 for CCASTAT-defined users to log in. Because the login occurs without a password, the default Logonid definition must be assigned the RESTRICT attribute (refer to the CA-ACF2 documentation for a complete description of this attribute).

If RESTRICT is not specified, the login for the default user fails. If the login for the default user fails, users cannot log in to Model 204 unless they are CA-ACF2 users. Additionally, the default Logonid must have job submit authority for Model 204 CCASTAT users to submit jobs.

If the LOGIN argument of the ACF2GEN macro is specified, the default user’s authority to log in to Model 204 is checked for authorization. If the default Logonid does not have authority to log in to this Model 204 job, then no CCASTAT-defined user has authority to log in to Model 204.

For security purposes a site can set up rules restricting who can modify and relink a new ACF2PARM module. Therefore, a system manager cannot alter the default Logonid. If a different default Logonid is required, the security officer or systems programmer must modify and link a new ACF2PARM parameter module, or allow access to a different parameter set in the ACF2PARM module.

If the LOGON ID parameter is blank, all user logins from CCASTAT are disallowed. This mode of operation forces all users to log in to CA-ACF2 to gain access to Model 204.

Note: Default Logonid privileges are in effect for the duration of a run. Changes to the privileges become effective after the Online is recycled.

Defining Model 204 user privileges

In either a MUSASS or single-user environment, Model 204 queries CA-ACF2 for the authority to grant access to various system resources on behalf of the user. User privileges are defined as resources to be protected, and rules are written to determine who is authorized for use of that resource. See Defining corresponding Generalized Resource Rules for more information.

ACF2 Interface storage requirements

When operating as a CA-ACF2 MUSASS, CA-ACF2 is responsible for building several control blocks for each user. Because the storage allocation comes from the address space in which the MUSASS is running, it is necessary to increase the value of the Model 204 SPCORE parameter for Online executions and all MUSASS controlled Model 204 jobs.

Converting users from CCASTAT security to CA-ACF2 security

When the CA-ACF2 MVS Interface is running, user IDs can be moved from CCASTAT to CA-ACF2 security. Once the user IDs have been transferred to CA-ACF2, they can be deleted from CCASTAT.

Setting the SECTRLOG parameter

The SECTRLOG user parameter defines which CRAM thread applications are allowed to log in to Model 204 with a trusted user ID. SECTRLOG must be set only if your site is using the trusted login feature. The CRAM threads for which trusted login applications are allowed are:

  • IODEV11 (CRFSCHNL)
  • IODEV29 (CRIOCHNL)
  • IODEV23 (IFAMCHNL)

SECTRLOG must be set on the first IODEV line for each trusted CRAM thread, because it is picked up during the initialization of each CRAM channel. The following settings are valid:

Setting Meaning
X'00' Trusted Login not allowed (default)
X'01' CICS applications (CRFS, CRIO, IFAM)
X'02' TSO applications (CRIO, CRFS)
X'04' Batch applications (CRIO, IFAM)

See also

Retrieved from "https://m204wiki.rocketsoftware.com/index.php?title=CA-ACF2_MVS_interface&oldid=94665"