Security Server (formerly RACF) interface

From m204wiki
Revision as of 20:54, 12 January 2015 by JAL (talk | contribs) (link repair)
Jump to navigation Jump to search

Overview

This topic presents an overview of how Security Server works and describes the impact of the Security Server Interface on the Model 204 user, system manager, and Security Server security administrator.

Note: The Security Server interface was formerly known as the RACF interface.

Security Server

Security Server is an extension of the IBM z/OS operating system that provides comprehensive data security. The Security Server Interface allows a Model 204 installation to use Security Server services within the Security Server environment.

Model 204 Security Server Interface

The Model 204 Security Server Interface allows an orderly migration from Model 204 security to Security Server security and allows an installation to use a combination of either or both security methods. The interface provides the tools and instructions necessary to:

  • Define a Security Server control group so that Model 204 can distinguish between separately running copies (that is, test and production)
  • Define Security Server generic profiles for Security Server authorization of Model 204 user privileges within a control group
  • Define a generic profile within Security Server that is associated with a control group, and determines whether a user can log in to Model 204
  • Define a Security Server common control group for Model 204 resources that can be shared between running copies
  • Define a default user priority class, or define the Security Server generic profiles that permit certain users to have specified Model 204 priorities
  • Provide a mechanism to validate accounting information
  • Determine a generic profile within Security Server that can define whether a user is allowed to submit JCL through the USE command
  • Allow a system manager to add, change, or delete Security Server Interface options that control interface operations
  • Provide a mechanism that establishes a shadow login capability to restrict user authorization via a default user ID for users who do not log directly in to Security Server
  • Provide a method for a Security Server security administrator to define a default group, user ID, and password for the default user ID
  • Provide a method for a Security Server security administrator to force users to log in through Security Server and not through CCASTAT

Model 204 Security Server Interface components

In summary, the Security Server Interface provides all the facilities an installation needs to implement Security Server security within the Model 204 environment.

The following figure illustrates the components of the Security Server Interface.

Security Server Interface

The Security Server Interface consists of the following components:

Component Notes
Model 204 Links with the Security Server Interface module
Security Server Interface module, RACFOS Communicates with Security Server by using the System Authorization Facility (SAF) z/OS router
RACFPARM module Can be linked with Model 204 or loaded dynamically at initialization
Model 204 system file, CCASTAT Contains file protection passwords, user IDs, and user ID passwords

Brief introduction to Security Server

This section provides a brief summary of key Security Server features that are used in the discussion of the Model 204 Security Server Interface.

For more information about the Security Server, see the IBM documentation associated with that product.

Security Server processing

Security Server identifies and verifies users accessing a system in which Security Server is installed and determines whether or not the user:

  • Is defined to Security Server
  • Has supplied a valid password (and/or operator identification card) and group name
  • Has the REVOKE attribute, which prevents a Security Server defined user from entering the system at all or from entering the system with certain groups
  • Can use the system only at certain times or on certain days as specified by the system manager or Security Server security officer
  • Is authorized to access the terminal (which also can include day and time restrictions for accessing that terminal)
  • Is authorized to access the application

The following types of checking are performed by Security Server:

  • Authorization
  • Global access

Authorization checking

When Security Server verifies a user’s identity, Security Server specifies the scope of that user’s authorization for the current terminal session or batch job in a control block called the accessor environment element (ACEE). Security Server controls the interaction between the user and protected resources and authorizes not only which resources the user can access, but the way in which the user can access them (for example, as read-only or update).

At the start of processing, Security Server performs the following checks that are related to the security classification of users and data:

  • Compares the security level in the user and resource profiles. If the resource has a higher security level than the user, Security Server denies the request.
  • Checks a category list (that is, a list of site-defined names corresponding to departments or areas within an organization) in t user’s profile against the category list in the resource profile. If the resource profile contains a category that is not in the user’s profile, Security Server denies the request.

If Security Server has not denied the request as a result of the security classification checks, processing continues.

Security Server permits access to a resource if the user satisfies any of a number of conditions, such as the following:

  • The resource is a data set and the high-level qualifier is the user’s user ID
  • The user’s user ID is in the access list with sufficient authority
  • The user’s current connect group is in the access list with sufficient authority
  • When list-of-group checking is active, one of the other groups with which the user is connected is in the access list with sufficient authority
  • The universal access authority (UACC) is sufficiently high
  • The user satisfies both of these conditions:
    • The user has the OPERATIONS attribute or the resource is within the scope of a group in which the user has the group-OPERATIONS attribute
    • The user’s user ID or any group name the user is connected to is in the access list with an authority not less than the user’s intended access

Security Server provides two installation exits that a site can use during RACHECK processing, as well as a quicker form of authorization checking called FRACHECK, or fast path RACHECK processing.

Global access checking

In addition to authorization checking, Security Server also provides global access checking. Global access checking allows a site to store a system-wide table of default authorization levels for selected resources. Security Server checks this table to determine if access to a resource is permitted.

If access is permitted, Security Server bypasses further RACHECK processing. If the global access check fails, RACHECK processing continues. Frequently accessed resources with generalized access rules are good candidates for global access checking.

Global access checking handles resources in both the data set and the general resource classes, with the exception of group resource classes.

Global access checking does the following:

  • Grants access, but does not, by itself, deny any request for access
  • Does not allow logging of permitted access or gather statistics
  • Does not offer a postprocessing installation exit
  • Performs no I/O on the Security Server data set, thus offering a high-performance checking option

Using profiles to protect resources

Security Server protects data sets (both DASD and tape) and general resources such as tape volumes and terminals. These resources are protected through profiles defined by the site. Authorized users can create, modify, list, and delete profiles using Security Server commands.

When the ADDSD statement is used to define and protect a data set, Security Server builds a data set profile and stores it in the Security Server data set. Profiles can be either generic or discrete depending on the nature of the resource.

Generic profile

A generic profile protects a single resource such as one data set, or a number of related resources; for example, those having similar naming structures, or the same access, authorization, and auditing requirements.

A generic profile contains a list of authorized users and the access authority of each user. A single generic profile can protect many data sets that have similar naming structures. Data sets protected by generic profiles need not be defined individually to Security Server, which saves the system manager from having to enter and maintain individual profiles.

Many users can protect all their data sets with a single generic profile consisting of their user ID and an asterisk:

user_id.*

This profile protects all the user’s data sets that begin with the user’s user ID, regardless of the number of qualifiers.

Discrete profile

A discrete profile protects resources that have specific or unique access authorization or logging requirements such as a single sensitive data set on a specified volume.

A discrete profile contains the same kind of information as a generic profile, but it protects only the one identified data set on the specified volume or volumes.

If the access authorization requirements are general, define a generic profile. If the data set has unique access authorization requirements, define a discrete profile.

Either type of profile can protect tape data sets as well as the following:

  • Cataloged and uncataloged non-VSAM data sets
  • VSAM data sets
  • Data sets with the same name residing on different volumes
  • Generation data group (GDG) data sets
  • Data sets and catalogs with single level names via a site-supplied prefix

In Model 204, the Security Server Interface user privileges and other authorization items are defined as data set names and treated as system resources. Generic profiles control who can use those resources by permitting individual users to access them. These rules are written by the Model 204 system manager and the Security Server security administrator.

Running the Security Server Interface with Model 204

When running either as an Online or in batch mode, Model 204 checks Security Server for the system resources a user has permission to access. Model 204 manages the authorization process, because only Model 204 can identify the user requesting a resource. Model 204 asks Security Server to validate those requests and responds to users who have been denied requests for resources.

Model 204 interfaces with Security Server in the following distinct areas:

  • User logins
    • LOGIN/LOGON command
    • IFSTRT function
    • IFLOG function
  • User resource requests
    • Dynamic allocation of new DASD space (ALLOCATE command)
    • Job submission (USE $JOB command)
    • Sequential data set handling (Record I/O)
    • VSAM data set handling (External I/O)

    Note: Because Model 204 databases are not validated on behalf of the user by the security interface, Security Server 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 permission 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 Security Server Interface uses the standard IBM-supplied calls to validate user requests for Model 204 resources. No source code modifications or exits to the Security Server software are needed. However, you can define an additional Security Server control group for nonshared resources as well as for resources shared between multiple copies of Model 204.

Using the Security Server Interface

This section describes the changes that affect a Model 204 user. They include:

  • LOGIN or 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. Once you are connected to Model 204, and if the system manager has set Model 204 to require logins, any commands you enter (other than LOGIN or LOGON) produce the following message:

*** PLEASE LOGIN

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.

User ID information

If Model 204 provides security authorization checks, as a Model 204 user you are assigned the following by the system manager:

  • User ID that identifies you to Model 204
  • Password that provides access to the system
  • User privileges associated with your user ID and password to define the particular type of access that you have
  • Default priority class assigned to your user ID

When native Model 204 security is in effect, this ID information is stored in a record in the system file CCASTAT. This record is deleted from CCASTAT when the system manager moves the user into Security Server security mode. The RACFPARM module supplies a default Logonid for CCASTAT Logonids to do validation requests on Security Server.

Security Server processing

When Security Server performs login validation, the user ID must be eight characters or less (seven characters if jobs are submitted through the internal reader). Your user ID is verified by Security Server before you can log in to Model 204.

If your site chooses to perform Security Server account validation, any value entered in the account field is verified via Security Server services. When Security Server is performing account validation, the account is limited to a maximum length of eight characters. If you do not enter an account, the default account becomes your user ID. Refer to Login processing for more information on login processing.

If you have the appropriate authority, you can change your Security Server user ID password when you log in to Model 204. For more information about the LOGIN and LOGON command, refer to the LOGIN or LOGON command wiki page.

IFSTRT function

In the IFAM1 and IFAM4 environments, the IFSTRT function is used in a Host Language Interface program to allocate a Host Language Interface thread. IFSTRT also establishes the calling convention, performs a user login, and determines whether or not the thread has updating privileges.

When processing the login argument of the IFSTRT call, the user login process follows the rules for User 0 login.

IFLOG function within IFAM1

The IFLOG function is used only in the IFAM1 environment. It is called following IFSTRT to identify you when a login is required. This function is necessary in any IFAM1 program where user authorization is validated by Security Server.

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

Dynamic allocation considerations

All dynamic allocation services in a Security Server environment are subject to Security Server system rules for data set validation. For example, data set allocation can be restricted to allow the creation of data sets with certain name patterns. The rules for data set access are determined by the Security Server security administrator.

To dynamically allocate a new data set, you must have Security Server ALTER authority. If you issue an ALLOCATE command and you do not have ALTER authority, you receive a Model 204 error message.

If you log in to Model 204 via CCASTAT, your allocation privileges are determined by the Security Server default user’s authorization.

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

Job submission considerations

When an Online user issues the USE $JOB command to submit a batch job, Model 204 identifies the user so that Security Server can determine if the user has proper authorization. If the submitter is IFAM1, IFAM4, or User 0, no additional processing occurs; the submitted job inherits the privileges from the submitting job, because it has already been authorized to run by Security Server.

In a Model 204 system in which the Security Server Interface is running, the following JCL statement is appended automatically to the submitted job statement(s) to identify the Model 204 user:

// USER=userid,PASSWORD=password,GROUP=groupname

where:

userid Is the submitting user’s Security Server user ID, or the default user ID if the user is logged in through CCASTAT.
password Is the user password associated with the particular user ID, or the default password for the default user ID if the user is logged in through CCASTAT.
groupname Is the Security Server group to which the submitting user is assigned. This is the group identified in the user’s ACEE that is provided by Security Server during user login, or the default group if the user is logged in through CCASTAT.

The default user ID, password, and group information is defined in the Security Server Interface parameter module (RACFPARM) and cannot be modified by the user or controlled by the system manager. RACFPARM is described later in this section.

If Model 204 finds any of the Security Server control parameters listed previously while processing the submitted JOB, they are deleted from the JCL to prevent users from violating security.

An installation can request that Model 204 check for user authority to submit a job. Because Security Server does not have a facility to restrict job submission, Model 204 checks the generic profile for the comgroup.SUBMIT option. Comgroup.SUBMIT determines whether or not a user is permitted to submit JCL. For more information about comgroup.SUBMIT, refer to the RACFGEN macro discussion.

If an unauthorized user attempts to submit a job, Model 204 issues an error message.

For users logged in via CCASTAT, the authority to submit jobs is determined by the default user’s authorization.

Sequential and VSAM data set considerations

Security Server always performs an authorization check if you try to use a sequential or VSAM data set. To use a sequential or VSAM data set you must be a member of a control group (or optionally a common control group) that has:

  • Security Server alter or update privileges to open a deferred update data set or to issue the DUMP or USE commands
  • Security Server alter authority to dynamically allocate a new sequential data set
  • Security Server read privileges to read sequential files from User Language or to read the file specified in a RESTORE command
  • Security Server read privileges to read external VSAM files from User Language.

If you issue a sequential or VSAM data set OPEN command that fails for Security Server reasons, Model 204 issues an error message.

If you log in to Model 204 via CCASTAT, authorization is determined by the default user’s authorization limits.

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.

Security Server directly checks the following Model 204 commands:

Login processing

The system manager is responsible for defining security processing in a Model 204 installation in which Security Server supplies authorization services. This section describes the login processing performed by the Security Server Interface.

Model 204 and Security Server login processing

When a user logs in to Model 204, Model 204 acquires the user ID and account and searches CCASTAT to determine whether or not the user ID exists.

If the user ID is found, Model 204 queries the user for a password and proceeds with authorization processing. If the RACFPARM module indicates that CCASTAT defined users cannot log in, the login fails.

If the user ID is not found in CCASTAT and Security Server security is in effect, Model 204 uses Security Server facilities to authorize the user login:

  • Model 204 passes the login user ID and password to Security Server to verify that the user is a valid Security Server user and that the password is correct.
  • If the site has chosen to verify that the user is authorized to use Model 204, Security Server is asked if the user has PERMIT authority to access the generic profile for resource group.LOGIN. If this check is successful, account processing occurs.
  • If the installation has chosen to verify the account, the value entered is checked against the Security Server profile for comgroup.ACCOUNT.account. If the value entered has PERMIT authority, the user is allowed into Model 204.

If Security Server 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.

Once users are successfully logged in, they are granted Model 204 privileges of X‘00’. Any additional privileges are determined whenever they enter a Model 204 command that requires a specific privilege.

Users who do not log in directly to Security Server are automatically restricted in what they can do by the privileges associated with the default user ID. Refer to Security Server default user ID for more information.

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

File, group, and subsystem security functions are defined as described in the Model 204 documentation, particularly the Security wiki topic.

User 0 login

When the Security Server Interface is active, User 0 is validated as the owner of the Model 204 run, regardless of whether the run is Online, BATCH204, IFAM1, or IFAM4. Model 204 always attempts to log in User 0 automatically, and verifies that any user ID supplied matches the user ID of the owner of the address space. It is not necessary to supply a user ID on the login command for User 0; Model 204 determines the owner user ID and supplies it automatically.

If a user ID is supplied on the login command and the user ID does not exist on CCASTAT, it must match the user ID of the owner of the address space or the login fails. If the user ID is found on CCASTAT and CCASTAT users are allowed to log in, all further authorization checking is based on a default user ID specified by the installation (if running as an APF-authorized program).

BATCH204 and IFAM4 can run without APF authorization if the user ID is equal to the ADDR SPACE ID and there is no default login ID (you cannot login from CCASTAT). If you try to log in without meeting these conditions, your login fails or a B78 System ABEND occurs.

Technical Support recommends that you do not specify a user ID in the login for User 0, so jobs can be easily migrated from test to production without having to change the login command.

Whether or not you supply a user ID, no password is needed and Model 204 does not prompt for one. If a password statement is coded in the input stream, it is treated as an invalid Model 204 command. If the user ID is on CCASTAT, Model 204 prompts for a password. If the password is correct, the login succeeds but all future data set authorization checking is based on the default user ID.

AUTHCTL VIEW command

The AUTHCTL VIEW command displays the interface control options currently in effect for the active interface.

For example, if you enter:

AUTHCTL VIEW

or

AUTHCTL VIEW RACF

The following list is displayed (assuming this information was used during initialization):

Security Server INTERFACE OPTIONS GROUP M204TEST Security Server control group name COMGROUP M204COM Security Server common control group name VALIDATE LOGIN Validation option in effect VALIDATE ACCOUNT Validation option in effect PRIORITY LOW Priority default DLMCHECK Use $JOB DLM checking option M204GRP Default user group M204USR Default user ID

The additional lines displayed indicate the current default user ID and group in use. For more information about defaults, refer to Security Server default user ID.

For information about setting control information, see Preparing a RACFPARM parameter module with RACFGEN.

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 Security Server. User IDs defined to CCASTAT are not allowed to log in as trusted users. CICS users must be using the Security Server interface for CICS. Only CICS user IDs that log in through Security Server 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 up the SECTRLOG parameter for trusted login.

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:

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

    LOGIN userid [account];password [:new 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:

    ‘userid [account];password [:new 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 errors described in this section.

  • The following message:

    M204.2378: SECURITY TRUSTED LOGIN FEATURE DISABLED

    is generated in either of the following situations:

    • The Model 204 job requesting the trusted login feature is running without a Model 204 Security Interface (CA-ACF2, Security Server, or CA-Top Secret).
    • 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.
  • The following message is issued when the trusted user ID passed by CRAM is not between 1-8 bytes long:

    M204.2379: INVALID TRUSTED USERID LENGTH = length

Maintaining the Security Server Interface

At each Security Server site, the security administrator performs system-wide maintenance functions within Security Server. The security administrator is responsible for defining and maintaining the Security Server generic profiles and permits for authorization that are eventually used by Model 204. The following discussions describe the Model 204 data maintained by the security administrator.

The privilege names that Model 204 uses are based on generic data set profiles. Although the Security Server ADDSD command describes a resource profile for Model 204, use it as if you are defining a data set.

This method provides the simplest way to describe resources. You do not need to reassemble any Security Server modules because all definition is external. In addition, it is portable across Security Server releases, because no internal modifications are made to Security Server tables and no Security Server exits are used.

In the following examples, the simplest set of conditions is described. You can fully utilize all Security Server options (for example, auditing when a resource is used, changing the universal access authority, or naming a specific owner of the group). Use security access levels for both the profiles and the permits for authorized users of those profiles.

The interface requires that users of these resources are permitted READ authority.

Defining user privileges

You must identify user privilege names as Security Server generic data set profiles. The standard Model 204 user privileges described earlier have been assigned fixed names. The following set of user privilege names defines the possible privilege types for a user. These names are further qualified by the control group name entered in the RACFPARM module.

These user privilege profile names are described in the following table. See the LOGCTL command page for more information on the LOGCTL settings.

User privilege names
User privilege name... Defines a user who can... Corresponding LOGCTL setting
‘group.PRIV.SUPER.USER’ Exercise superuser privileges: a user with READ access to this profile can execute a CREATE command. X’80’
‘group.PRIV.SYSTEM.ADMIN’ Exercise system administrator privileges: a user with read access to this profile can issue system administrator commands such as LOGWHO, MONITOR, PRIORITY, and WARN. X’40’
‘group.PRIV.CHANGE.FILE .PASSWORD’ Change the file password that is used to open a file: valid only if the file entry is stored in CCASTAT. X’20’
‘group.PRIV.SYSTEM .MANAGER’ With system manager privileges: a user with read access to this profile can issue all system administrator commands along with certain other privileged commands such as LOGCTL, AUTHCTL VIEW, and DUMPG. X’08’
‘group.PRIV.OVERRIDE .RECORD.SECURITY’ Override record security. X‘04’

Defining corresponding generic profiles

Security Server generic data set profiles must be developed and defined to Security Server to correspond to the defined privileges. The Security Server generic data set profiles used to define the standard Model 204 privileges and other resources to Security Server in a batch TSO execution are as follows:

//JOBNAME JOB (other information)..... //DOIT EXEC PGM=IKJEFT01,DYNAMNBR=20 //SYSTSPRT DD SYSOUT=A //SYSTSIN DD * ADDGROUP group DATA('MODEL204 Security Server CONTROL GROUP NAME') ADDSD 'group.PRIV.SUPER.USER*' UACC(NONE) GENERIC ADDSD 'group.PRIV.SYSTEM.ADMIN*' UACC(NONE) GENERIC ADDSD 'group.PRIV.CHANGE.FILE.PASSWORD.*' UACC(NONE) GENERIC ADDSD 'group.PRIV.SYSTEM.MANAGER*' UACC(NONE) GENERIC ADDSD 'group.PRIV.OVERRIDE.RECORD.SECURITY.*' UACC(NONE) GENERIC ADDSD 'group.LOGIN*' UACC(NONE) GENERIC ADDGROUP comgroup DATA('MODEL204 Security Server COMMON GROUP NAME') ADDSD 'comgroup.SUBMIT*' UACC(NONE) GENERIC ADDSD 'comgroup.PRIORITY.HIGH*' UACC(NONE) GENERIC ADDSD 'comgroup.PRIORITY.STANDARD.*' UACC(NONE) GENERIC ADDSD 'comgroup.PRIORITY.LOW*' UACC(NONE) GENERIC ADDSD 'comgroup.ACCOUNT.nnnnnnnn.*' UACC(NONE) GENERIC

Note: nnnnnnnn represents an account number; there are as many as required. Also, high-level qualifiers cannot exceed eight (8) characters.

In the following two sample PERMIT statements, the first is for a system manager and the second is for login authorization to a copy of Model 204:

PERMIT 'group.PRIV.SYSTEM.MANAGER*' ACCESS(READ) ID(user ID1,user ID2.....) PERMIT 'group.LOGIN*' ACCESS(READ) ID(user ID1,user ID2.....)

where:

group.PRIV.privilege Specifies one of the fixed types that Model 204 uses to build Security Server retrieval search keys for the rules
group Is the Security Server control group defined to Model 204

The previous Security Server PERMIT statement sample permits the specified users to access the named resource. Rules for determining the authorized user are described in the IBM Security Server documentation.

The privilege rules are 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 might be logged as an Security Server violation.

Installing the Security Server Interface

The Model 204 interface to Security Server consists of the following components:

  • Code in Model 204 that utilizes Security Server facilities
  • Security Server group and generic data set profile definitions defined at your site
  • SECPLIST User 0 parameter in CCAIN

The user site requirements that must be met in order to activate the Security Server Interface are identified in this section.

Terminal security considerations

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

Configurations using 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 user IDs 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.

Decrypting Security Server

As part of INS204, the M204DECR job is generated with all the steps needed to decrypt Security Server. Refer to the Rocket Model 204 Installation Guide for IBM z/OS for more information.

SECPLIST parameter

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

  • If the SECPLIST parameter is not in CCAIN, RACFPARM is used as the default name of the argument set.
  • If no match is found for the SECPLIST name or the RACFPARM default name in the RACFPARM module, the interface is initialized using the precoded default parameters defined in the Security Server Interface. In this case, Login, Account, and Priority validation are not performed.

The following RACFPARM module contains two sets of Security Server 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 'RACFPARM MODULE' X LOG1 RACFGEN GROUP=M204PROD, X COMGRUP=M204RACF, X PRTY=H, X VALIDAT=ACCOUNT, X DEFUSER=M204USER, X DEFGRP=, X DEFPASS=, X DMLCHECK LOG2 RACFGEN GROUP=M204TEST, X COMGRUP=M204RACF, X PRTY=S, X VALIDAT=(ACCOUNT,LOGIN), X DEFUSER=JOBNAME, X DEFGRP=M204GRP, X DEFPASS=DEFPASS, X DMLCHECK RACFGEN TYPE=END END

Preparing a RACFPARM parameter module with RACFGEN

The RACFGEN macro generates a set of arguments that govern login and other security processes. There can be multiple argument sets in a RACFPARM module. The RACFPARM parameter module can be linked with Model 204 or dynamically loaded when the Security Server Interface is initialized.

The arguments for the RACFGEN macro are described in detail in this section.

The following is a sample RACFGEN macro with one set of arguments. The name of the argument set is RACFPARM, which is the required name if you are linking statically into your Model 204 modules.

TITLE 'GENERATE A Security Server PARAMETER MODULE' RACFPARM RACFGEN GROUP=M204RACF, Control group X COMGRUP=M204RACF, Common control group X PRTY=S, Priority X VALIDAT=, Validation items X DEFUSER=M204USR, Default user ID X DEFUGRP=M204GRP, Default user group X DEFPASS=M204PASS, Default user password X DLMCHECK/NODLMCHECK Check DLM= RACFGEN TYPE=END END

where:

  • RACFPARM defines the name of this set of Security Server arguments. Because there can be any number of argument sets in the RACFPARM module, each set must be given a unique name. There is no default name.

    Note: If you want to statically link the RACFPARM module, you must include (as the first argument) a Security Server argument set named RACFPARM. Otherwise, the SECPLST value for the user is not found in the RACFPARM module, and the interface is initialized using the precoded default parameters defined in the Security Server Interface. In this case, Login, Account, and Priority validation are not performed. This may result in the user being unable to login.

  • GROUP specifies the 1- to 8-character Security Server control group name selected by your site. The rules for Model 204 privileges are defined and grouped by this code and stored in Security Server profiles. The group name must match the generic profile high-level qualifier defined to Security Server in the ADDSD statements for the profiles, all of which take the form of group.keyword.variable.data.

    The default is M204RACF.

    You can use the GROUP name to create a separate set of privilege definitions for an individual copy of Model 204. This allows your site to have different privileges for different versions of Model 204, for instance for test and production.

  • COMGRUP specifies the 1- to 8-character Security Server common group name selected by your site. The rules for the VALIDAT ACCOUNT, PRIORITY, and SUBMIT options are defined and grouped by this code and stored in Security Server profiles.

    The common group name must match the generic profile high-level qualifier defined to Security Server in the ADDSD statements for the profiles, all of which take the form of comgroup.keyword.variable.data.

    The default is M204RACF, if a group name is not specified.

    Note: COMGRUP is used to create a common set of privilege definitions shared between copies of Model 204.

  • PRTY specifies the default priority for any user who successfully logs in through Security Server. Options are H (high), S (standard), L (low), or N (none). The default priority is STANDARD if the PRTY keyword is omitted. For more information about priorities, refer to Priority scheduling.
  • VALIDAT specifies the type of validation to be performed. Multiple validation types can be specified for the interface.

    Options are:

    • ACCOUNT specifies that Security Server validates any account entered by the user during the login process. VALIDAT ACCOUNT verifies that Security Server permits the account value entered by the user. If so, the user is allowed in to Model 204. If not, the login fails. This validation uses the comgroup.ACCOUNT.account# profile.
    • LOGIN specifies that Security Server rules are tested to determine if a user is allowed to log in to Model 204. If VALIDAT LOGIN is specified, the Security Server Interface determines if the user is permitted to use Model 204 before allowing access. If LOGIN is not specified, all users who pass the user ID/password and optional account validation are allowed access to Model 204.

      This validation is performed using the profile group.LOGIN, so it can be used to limit the ability to log in when several copies of Model 204 are running.

    • PRIORITY verifies which priority the user is permitted to have. This option can be specified in addition to a standard priority. If priority validation fails, the standard priority is the default.

      This validation uses the profiles:

      comgroup.PRIORITY.HIGH comgroup.PRIORITY.STANDARD comgroup.PRIORITY.LOW comgroup.PRIORITY.NONE

      Validation is checked from highest to lowest priority. If a user has PERMIT access to one of these priorities, the value is assigned. If no PERMIT is found and a standard priority is not specified, the priority for the user is set to STANDARD.

    • SUBMIT uses Security Server rules to determine whether or not a user is allowed to issue the USE command to submit a job through the internal reader. If this option is specified, Security Server checks the user’s authorization privileges before allowing the user to submit the job. If this option is not specified, all users who pass the user ID/password and optional account validation are allowed to submit jobs.

      This validation uses the comgroup.SUBMIT profile.

  • DEFUSER defines the default submitting user’s Security Server user ID if the user is not directly logged in through Security Server. Refer to Job submission considerations for a description of how the Security Server user ID is used when submitting jobs.
    • If DEFUSER=, that is, this field is left blank, then CCASTAT-defined users are not allowed to log into Model 204. Only valid Security Server users can utilize the running system.
    • If DEFUSER=JOBNAME, then the following occurs. The ASID ACEE is moved to DEFUSER, the GROUP ACEE is moved to DEFGROUP, and the default user’s ACEE pointer is set to AUCKDPTR.
  • DEFUGRP defines the default Security Server group to which a submitting user is assigned if the user is not directly logged in through Security Server. Refer to Job submission considerations for a description of how the Security Server group is used when submitting jobs.
  • DEFPASS defines the default PASSWORD for the default user ID if the user is not directly logged in through Security Server. Refer to Job submission considerations for a description of how the Security Server password is used when submitting jobs.
  • The DLMCHECK/NODLMCHECK argument specifies DLM processing options for jobs submitted through the internal reader using the USE command. The DLM parameter on a DD * or DD DATA statement allows a job to be submitted that can itself submit other jobs. This is a potential security compromise. The DLMCHECK/NODLMCHECK argument provides the ability to enforce certain rules when coding the DLM= parameter.

    DLM processing options are as follows:

    • DLMCHECK enforces the rule 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=';;'

      or

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

      In these statements, the DLM value 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 appends the following to the job statement set as if it is an independent job:

      USER=...,PASSWORD=...GROUP=...

    • NODLMCHECK checks only the validity of the DLM= parameter and not the other optional 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. This argument does not guarantee that an error on the statement with the DLM= parameter is caught before it is submitted.

      DLMCHECK is the default.

The result from assembling the RACFGEN macro is link-edited to a library that is included in a Model 204 link-edit, or it can be optionally linked into a separate library and loaded at execution time.

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

If you link RACFPARM with the Model 204 configuration, add the following line in SYSLIN for the link-edit steps of ONLINE, BATCH204, IFAM1, and IFAM4.

INCLUDE OBJLIB(RACFPARM)

Model 204 link-editing requirements

To support multiple Model 204 logins for different user IDs, Model 204 must be linked to an authorized library using the appropriate Security Server services. This means that any Online configuration must be linked to an authorized library.

BATCH204 or IFAM can be linked to a nonauthorized library, provided that the user logging in is the same user who starts the job and there is not a default login ID that prevents CCASTAT logins. Otherwise, the login fails or a System B7A ABEND occurs.

Defining Model 204 to Security Server

Model 204 allows multiple users per address space and provides services to many users through its own processing, but Security Server is aware only of the main task in the address space (in this instance, Model 204). Model 204 must be defined as having the appropriate Security Server privileges to perform services on behalf of a Model 204 control group.

You can define an additional Security Server control group for nonshared resources as well as for resources shared between multiple copies of Model 204.The first step in the definition process is to choose a name and define a profile for the Model 204 control group and optionally the common group. For example:

ADDGROUP M204RACF OWNER(SECURITY) DATA('MODEL 204 CONTROL GROUP') ADDGROUP M204COM OWNER(SECURITY) DATA('MODEL 204 COMMON CONTROL GROUP')

Defining Model 204 users in Security Server

In Security Server, the user profile record contains all information for a defined user of a computer system. There are no special entries or any differences in the way a Security Server user is defined to the system. All authorization services are performed using the generic profiles for privileges. See Defining corresponding generic profiles for more information.

Security Server default user ID

The default user ID limits the authorization of users that have not logged in directly to Security Server (that is, users still defined in CCASTAT).

Each user not logged directly into Security Server is assigned the authorization provided by Security Server for the default user ID. The authorization includes all user resource requests, as described in Running the Security Server Interface with Model 204.

The default user ID automatically is assigned the user ID M204USR with the password M204PASS and belongs to group M204GRP. A user ID of this name must be defined to Security Server for CCASTAT-defined users to be able to log in.

For security reasons, the system manager cannot modify this group, user ID, and password. If different data is required or if the installation would like to change defaults, the parameter module RACFPARM must be modified by the Security Server security administrator or systems programmer.

RACFPARM provides the mechanism to supply overrides to the default group, user ID, and password. This module can be made available during the Model 204 link-edit. Otherwise, Model 204 attempts to load it at the time the interface is initialized. If the module is loaded dynamically, it must be made available in the STEPLIB containing Model 204 or in a system load library. The RACFPARM module is generated with the RACFGEN macro.

Note: All LOADLIBs concatenated in one STEPLIB must be APF-authorized or you lose your APF authorization for that job step.

Setting up the SECTRLOG parameter for trusted login

The SECTRLOG user parameter defines which CRAM thread applications are allowed to log in to Model 204 with a trusted user ID. 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)

Conversion tasks and considerations

The following table identifies the general tasks that must be completed to install and activate the Security Server Interface. Before conversion, you also might want to review the RACFPARM module definitions and link a separate copy of Model 204 for testing and production.

Conversion checklist for Security Server

Step Task
1. Define a Security Server GROUP control profile for Model 204.
2. Define a Security Server GROUP common profile for Model 204.
3. Define Security Server generic profiles for user privileges, and specify the users who have PERMIT access to have those privileges.
4. Define Security Server generic profiles for:
  • Model 204 login authority related to the control group if the VALIDAT LOGIN option is specified in the RACFPARM
  • Authorized account code profiles related to the common group if the VALIDAT ACCOUNT option is specified in the RACFPARM
  • Authorized PRIORITY profiles if the VALIDAT PRIORITY option is specified to assign individual priorities to users and specify which users have PERMIT access for those privileges
5. Run RACFGEN to assemble the RACFPARM module.
6. Link RACFOS into Model 204.
7. Link RACFPARM$ into Model 204 directly or use SECRLINK to create a separate LOAD module to be used for dynamic linking at initialization.
8. Add a new parameter in the user zero input stream called SECPLIST=parametername.
9. Delete Model 204 users from CCASTAT to turn on Security Server authorization checking.
Retrieved from "https://m204wiki.rocketsoftware.com/index.php?title=Security_Server_(formerly_RACF)_interface&oldid=74567"