CA-Top Secret interface

Overview

This topic presents an overview of how CA-Top Secret works and describes the impact of the Model 204 CA-Top Secret Interface on the Model 204 user, system manager, and the CA-Top Secret security administrator. Installation requirements and a conversion task summary are also presented.

Note: Throughout this topic, the security administrator or security officer is referred to as the TSS administrator. There are many levels of control for TSS administrators, and the TSS administrator for Model 204 requires having enough scope of control to administer security functions needed to operate the CA-Top Secret Interface.

CA-Top Secret

CA-Top Secret is a security product owned by Computer Associates, Inc. (CA) and driven by IBM z/OS. Using the Standard Security Interface (SU32) or the System Authorization Facility (SAF) found in all versions of z/OS, CA-Top Secret accepts and validates security checking requests issued by the security drivers in major z/OS components. (IMS and CICS use the Standard Security Interface as do other IBM and vendor products.) Because CA-Top Secret can be installed without modifying the operating system, it is compatible with all software that uses the Standard Security Interface.

Model 204 CA-Top Secret Interface

The Model 204 CA-Top Secret Interface provides for an orderly migration from Model 204 security to CA-Top Secret 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 CA-Top Secret control accessor ID (ACID) for Model 204 to distinguish between separately running copies (that is, test and production)
• Define CA-Top Secret pseudo data sets for CA-Top Secret authorization of Model 204 user privileges within the control ACID
• Define a CA-Top Secret common control ACID for Model 204 resources that can be shared between running copies
• Define an installation default user priority class, or the CA-Top Secret pseudo data set profiles that permit Model 204 priority usage by permitted users
• Provide a mechanism to validate accounting information
• Allow a system manager or installation security officer to add, change, or delete interface options that can control the operation of the interface
• Allow a system manager to view interface control options while the CA-Top Secret Interface is operational
• Provide a mechanism that establishes a shadow login capability to restrict user authorization via a default ACID when users log in through CCASTAT
• Provide a method for a CA-Top Secret security administrator to define a default ACID and password
• Provide a method for a CA-Top Secret security administrator to force users to log in through CA-Top Secret and not through CCASTAT

In summary, the CA-Top Secret Interface provides all the facilities an installation needs to implement the CA-Top Secret security mechanism within the Model 204 environment.

CA-Top Secret components

The following table and figure describe the components of the CA-Top Secret Interface:

Component	Notes
Model 204	Linked with the CA-Top Secret Interface module
CA-Top Secret Interface module, TOPSOS	Communicates with CA-Top Secret by using the standard IBM Security Server macros
Module TOPSPARM	Can be linked with Model 204 or can be loaded dynamically at initialization

CA-Top Secret Interface

Introduction to CA-Top Secret features used with Model 204

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

For more information about CA-Top Secret, see the documentation associated with that product, or go to http://www.ca.com/us/products/detail/ca-top-secret.aspx.

CA-Top Secret processing

CA-Top Secret implements security throughout a data processing community by:

• Identifying users allowed to access the system
• Controlling access to system facilities (for example, BATCH, TSO, Model 204)
• Restricting use of system resources (such as files and programs)

This extremely flexible system can be tailored to meet the precise security requirements and operational characteristics of an installation.

An overview of the structure and components of CA-Top Secret is provided in the following sections.

Accessor ID (ACID)

An Accessor ID (ACID) is the fundamental key that CA-Top Secret uses to identify who has access to what resources. A set of resource access authorizations or CA-Top Secret administrative authorizations or both is associated with each unique ACID. This set of authorizations is maintained in one or more Security Records in the Security File whose primary access key is the designated ACID.

An ACID can be a maximum of eight alphanumeric characters. If the user is using TSO, the ACID is limited to seven characters because of TSO restrictions. A user’s ACID and user ID must be the same. A user can have multiple ACIDs, one for each facility (TSO, CICS) used.

A user with an ACID is considered defined to CA-Top Secret. Conversely, a user without an ACID is considered undefined by CA-Top Secret.

CA-Top Secret recognizes several different types of ACIDs. For example, each of the various system organizational elements described in System organizational elements possesses its own ACID type. The type of ACID indicates what administrative authorities it can possess.

System organizational elements

CA-Top Secret architecture is user-oriented, rather than resource-oriented. CA-Top Secret associates a set of specific resource access authorizations with each user, rather than each resource with a set of users who are allowed various types of access to it.

As a result of this approach, CA-Top Secret’s processing requires only one I/O operation, through a cross-memory call to the CA-Top Secret address space, when a batch job or Online session initiates. Every accessed resource need not be independently checked, which contributes to system efficiency.

CA-Top Secret architecture is constructed from the following basic elements:

• Users
• Profiles
• Departments
• Divisions

The function of the CA-Top Secret organizational elements is to serve as a coordinating framework for security implementation and maintenance. Therefore, a CA-Top Secret security system should be designed to follow the actual organizational structure at an installation.

User element

The user element is the lowest level in a CA-Top Secret organizational hierarchy. It associates a specific employee with a specific department. Every user must be associated with a single department. In a broader sense, a user can refer to any discrete entity whose access to resources is defined and specifically restricted.

For example, a batch job authorized to read data from only a specific file can be identified to CA-Top Secret as a user. An operating system started task (STC) also can be identified to CA-Top Secret as a user.

A user element is identified to CA-Top Secret by a unique user ACID.

Profile element

When a group of users uses a set of identical resources in the same way (that is, they perform the same job function), it is easier to define the set of access authorizations once and associate the entire set to each of the users in the group. In CA-Top Secret this set of common resource access characteristics is called a profile. Every profile is assigned a unique profile ACID.

A defined profile can be associated with any number of users, thereby eliminating the need to define each resource and resource access separately for each user. There is no limit to the number of profiles that can be defined. However, a single user can be associated with no more than 254 profiles.

Every profile must be associated with and defined within a single department.

Department element

At an installation, users typically work for a particular department. CA-Top Secret recognizes this and associates user ACIDs with departments. Every department is assigned a unique department ACID. Resources can be assigned to a department just as they can be assigned to a user or a profile.

Every user ACID must be associated with only one departmental ACID.

Division element

CA-Top Secret allows the user to define multiple divisions within the corporate security structure. Each division must include one or more departments. However, a department need not be associated with a division. Every division is assigned a unique division ACID, and resources can be assigned to a division just as they can be assigned to a department, profile, or user.

Facilities

A facility is any z/OS subsystem (IBM or vendor, provided it is managed by z/OS) that processes work on behalf of users or jobs (for example, Model 204, BATCH, TSO). CA-Top Secret can restrict users to only those specific facilities required to perform their jobs.

Because CA-Top Secret is driven by the Standard z/OS Security Interface, it is compatible with any z/OS subsystem facility or vendor facility that uses the Standard Security Interface including batch processing, STC, TSO, CICS, IMS, NCCF, ROSCOE, WYLBUR, ACEP, TONE, SNA Communications Server (formerly VTAM)/SPF, and COM-PLETE. CA-Top Secret checks the set of access authorizations of a particular ACID to determine whether or not it should be allowed to access this facility.

A single ACID can be allowed access to several different facilities, and multiple concurrent logins can be permitted.

Resources

CA-Top Secret protects a great variety of computer resources including data sets (VSAM and non-VSAM), programs, DASD and tape volumes, catalogs, terminals, readers, transactions, and jobs. Even user-defined, nonstandard resources that normally do not activate z/OS security interfaces (such as database fields and account codes) can be defined to CA-Top Secret and protected.

A site can choose whether or not to protect a particular class of resources by default; that is, determine whether or not a user must be specifically authorized to gain access to any resource protected in this manner. Resource types that are not protected by default must be explicitly defined for protection. Otherwise, they remain globally accessible to both defined and undefined users.

The techniques for defining resources are discussed in the following sections.

Prefixes

Resources are defined to CA-Top Secret either by their full name or through a generic prefix. Prefixing allows a group of resources of the same type to be defined to CA-Top Secret simultaneously. For example, the program type prefix IEH encompasses IEHPROGM, IEHINIT, IEHLIST, and so on. Using prefixing, the user ADM10MK can be granted access authorizations to all data sets whose first qualifier is ADM10 with a single CA-Top Secret entry.

Prefixing can be applied to any type of resource.

Data set masking

Another technique for significantly reducing the number of definitions required for CA-Top Secret is data set masking. Masking defines a group of data sets with similar naming characteristics, substituting special characters for the dissimilar characters. For example, the mask *.PROD ignores the high-level index to match it with APC001.PRODLIB.

Access controls

CA-Top Secret controls access to systems and system data in the following four stages:

• Performs the appropriate signon and password validation, and checks the ACID for validity and for whether or not it has been suspended or expired
• Determines whether or not a user is allowed access to the requested facility, forces the user to access the system through a specific source (for example, a particular terminal or to use a specific CPU)
• Checks whether or not the user is authorized to use a requested resource
• Checks exactly how and when the user is authorized to use the resource and whether or not a request is permitted by that authorization

CA-Top Secret allows great specificity in defining what restrictions are placed on the use of a resource by a user or profile group. (Facility and resource restrictions cannot be made at the divisional or departmental levels.)

For example, access to a resource can be restricted by expiration date, day of week or time of day, or by facility (for example, this ACID may only access this volume through TSO). For sensitive data sets, users can be restricted to privileged path access (that is, only through a particular program that also might have been forced to load from a specific library).

Access levels

A user either does or does not have access to resources such as terminals. However, other resources such as data sets, volumes, and CICS data (for example, DCT, FCT) can be restricted for specific uses for a specific user. In CA-Top Secret, an access level is defined as the manner in which a resource can be used. CA-Top Secret allows for specificity in defining restrictions on the manner in which a resource can be used by a user or profile group. For example, an ACID might be limited to read, write, update, create, scratch, or fetch access to a particular data set, granted a combination of these access levels, or granted total access.

Specific resources also can be made globally accessible to all users. Thus, system data sets, libraries, DASD storage, and work volumes that should be made available to all system users can be defined through a few simple CA-Top Secret entries. If access level restrictions are appropriate for one of the shared system resources (for example, SYS1.BRODCAST should be globally accessible, but for system-initiated update access only), such restrictions can be implemented.

Note: Global access restrictions apply to both defined and undefined users.

Ownership and authorization

A particular resource can be owned by only one ACID. In general, ownership of the resource gives full access automatically to that resource. Nonowners must be authorized to access resources and their access levels can be restricted.

When a resource is assigned an owner, it is defined to CA-Top Secret. This is important for resource types that are extended security protection only if they have been defined to the system (for example, programs, terminals, database fields). Any user can access a resource that is not owned.

To simplify security administration, resources should be owned by departments and divisions rather than users. Because ownership of a resource by a department does not imply automatic access to that resource for all users in that department (user ACIDs associated with that department ACID), explicit authorizations are required to restrict access to only the resources a user needs to perform job functions. An exception to this guideline allows users to own all files with data set name prefixes matching their ACID.

Division, department, profile, and user ACIDs can all own resources. Of these ACID types, however, only users and profiles (groups of users) can be authorized to access resources.

The use of profile ACIDs and generic prefixing greatly reduces the number of CA-Top Secret entries required to define an installation’s resource owners and resource access authorizations. A group of users performing the same job function usually need to access the same resources. Each of the individual users can be associated with a single profile authorized access to these required resources. If company standardized conventions exist, often these resources possess a family relationship that can be described as a generic prefix (for example, the same highest level qualifier shared among a group of data set names).

Access to facilities is controlled by using authorizations; facilities cannot be owned.

Model 204 user privileges and other authorization items are defined as pseudo data set resources. Local installation profiles are written to control who can use those data sets. The Model 204 system manager and the TSS administrator write these rules, which are described in Sample definition of Model 204 pseudo data set names.

Running the CA-Top Secret Interface with Model 204

When running either as an Online or in batch mode, Model 204 checks CA-Top Secret for the system resources a user can access. Model 204 manages the authorization process, because, in multiuser mode, only Model 204 can identify the user requesting a resource. Model 204 asks CA-Top Secret to validate those requests and responds to a user who has been denied a request for a resource. Model 204 must run from an APF-authorized load library to use the Top Secret interface.

Model 204 interfaces with CA-Top Secret in the following distinct areas:

• User logins
  • LOGIN/LOGON command
  • IFSTRT function
  • IFLOG function
• User resource requests
  • Dynamic allocation (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, CA-Top Secret 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

Managing the authorization process

The CA-Top Secret Interface uses the standard IBM Security Server macros to validate user identities and user requests for Model 204 resources. No source code modifications or exits to the CA-Top Secret software are necessary. However, the installation can define additional CA-Top Secret control ACIDs for nonshared resources as well as resources shared among multiple copies of Model 204. An installation must define pseudo data sets with appropriate PERMITs as described in Sample definition of Model 204 pseudo data set names.

Using the CA-Top Secret Interface

A user notices only slight changes when running Model 204 with CA-Top Secret. These changes include:

• LOGIN or LOGON
• IFSTRT function
• IFLOG function with IFAM1
• Dynamic allocation
• Job submission
• Data set handling

LOGIN or LOGON command

The LOGIN/LOGON command allows you to gain access to Model 204. After you are connected to Model 204, and if the system manager has set the Model 204 option to require logins, any command entered by the user (other than LOGIN or LOGON) produces the following message:

*** PLEASE LOGIN

To log in, enter:

LOGIN userid [account]

or

LOGON userid [account]

Where:

userid	Is a character string that identifies the user
account	Is an optional character string that identifies the account under which the user logs in

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

• User ID that identifies the user to Model 204
• Password that provides the user access to the system. Note that Model 204 versions 7.7 and later also support passphrases.
• User privileges associated with that user ID and password to define the particular type of access that the user is allowed
• Default priority class assigned to the 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 is deleted from CCASTAT when the system manager moves the user into CA-Top Secret security mode. The TOPSPARM module (described in Preparing a TOPSPARM parameter module with TOPSGEN) supplies a default Login ID for CCASTAT Login IDs to do validation requests to CA-Top Secret.

When CA-Top Secret is performing login validation, the user ID (that is, the ACID) is limited to a maximum length of eight characters. The ACID is verified by CA-Top Secret before the user can log in to Model 204.

If the installation chooses to perform CA-Top Secret account validation, any value entered in the account field is verified through CA-Top Secret services. When CA-Top Secret is performing account validation, the account is limited to a maximum length of 8 characters. If no account is entered, the default account becomes the user’s ACID.

See Login processing for more information.

Changing your password

If you have the appropriate authority, you can change your CA-Top Secret user ID password when you log in to Model 204. For more information, see the LOGIN or LOGON command page.

Passphrases

If CA-Top Secret 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-Top Secret. 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 is used in a Host Language 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 is allowed updating privileges.

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

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 user authorization is validated by CA-Top Secret.

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 in a CA-Top Secret environment are subject to CA-Top Secret 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 TSS administrator.

To dynamically allocate a new data set, the user must be defined to CA-Top Secret as having ALL or CREATE authority. Without this authority, a user issuing the ALLOCATE command receives a Model 204 error message and the ALLOCATE fails.

Allocation of an existing data set to the Online is not validated at allocation time, it is validated when the data set is opened.

If you log in to Model 204 via CCASTAT, your allocation privileges are determined by the CA-Top Secret default ACID.

Note: When you open a sequential or a VSAM data set, either new or existing, CA-Top Secret verifies that you have the appropriate access authority. CA-Top Secret does not perform access authorization on Model 204 data sets, because these data sets are currently protected under Model 204

Job submission considerations

When an Online user issues the USE $JOB command to submit a batch job, Model 204 identifies the user who submitted the job so that CA-Top Secret can properly determine the authorization for that execution. If the submitter is IFAM1/IFAM4 or User 0, no additional processing occurs. In these cases, the submitted job inherits the privileges that existed when the job doing the submitting was started, because they have already been authorized to run by CA-Top Secret.

When the Model 204 Online is running with an active CA-Top Secret interface, either the user’s ACID address or the default user’s ACID address is entered into the appropriate location within the JOB statement. Any attempt to circumvent this is denied.

Sequential and VSAM data set considerations

Any attempt to use a sequential or VSAM data set results in an authorization check of the following privileges:

• CA-Top Secret all, control, or write privileges to open a deferred update data set or to issue the DUMP or USE data set commands
• CA-Top Secret all or create privileges to dynamically allocate a new sequential data set
• CA-Top Secret read, all, or update privileges to read sequential files from SOUL or to read the file specified in a RESTORE command
• CA-Top Secret read, all, or update privileges to read external VSAM files from SOUL

If a Model 204 user issues a sequential or VSAM data set OPEN command that fails for CA-Top Secret reasons, a Model 204 error message is displayed and the operation fails.

For those users who logged in by being on 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.

CA-Top Secret directly checks the following Model 204 commands:

• DUMP and DUMPG
• RESTORE and RESTOREG
• USE OUTXXXXX
• ALLOCATE a new data set
• OPEN DATASET
• OPEN filename with deferred update

Login processing

The system manager is responsible for defining security processing in a Model 204 installation in which CA-Top Secret supplies authorization services. This section describes the login processing that the CA-Top Secret Interface performs. AUTHCTL VIEW, the Model 204 command used by the system manager to view CA-Top Secret control information, is also described.

When a user logs in

When a user logs in, 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 TOPSPARM module indicates that CCASTAT defined users cannot log in, the login fails.

If the user ID is not found in CCASTAT and CA-Top Secret security is in effect, Model 204 uses CA-Top Secret facilities to authorize the user login. Model 204 passes to CA-Top Secret the login user ID (that is, the ACID), the password and any new password, and finally the terminal ID or user source.

CA-Top Secret makes its own validation checks at this point, which include but are not limited to the following:

Validation check	Notes
ACID identification	The ACID must be defined and must not be suspended or expired.
Password checking	The password must be correct for the ACID.
New password check	The user can be prevented from specifying a new password or might require a new password.
FACILITY checking	Ensures that the user is authorized to use the Model 204 Facility and that the user is allowed to use Model 204 during the specified time.
Terminal security	Ensures that the user is allowed to use this terminal. Refer to the section on terminal security for non-SNA Communications Server terminal identification by Model 204.
Duplicate signon check	Ensures that each user is logged in only once. This check is independent of the Model 204 duplicate sign-on check, and its scope is wider. For example, you can ensure that a user who is logged in to IMS cannot also log in to Model 204.

Messages

At login, CA-Top Secret can issue messages to users advising them of their status, or why system access was denied. Model 204 passes any messages back to the user with an M204.1500 message.

Note: Model 204 passes back the entire CA-Top Secret error message series following the M204.1500 prefix, which might exceed the terminal line size. Technical Support recommends using the following MSGCTL command in the User 0 input stream to remove the Model 204 message prefix:

MSGCTL M204.1500 NOPREFIX

After the previous checks, CA-Top Secret indicates whether or not the user can enter into the system, and Model 204 acts accordingly.

• If the login is successful, account processing occurs.
• If the installation has chosen to verify the account, the value entered is checked against the CA-Top Secret profile for comacid.ACCOUNT.account.
• If the value entered is PERMIT READ for that user's ACID, the user is allowed in to Model 204.

After successfully logging in, the user is granted Model 204 privileges of X'00'. Any additional privileges are determined at the time a user command requires a specific privilege.

Users who do not log in directly to CA-Top Secret are automatically restricted in what they can do by the privileges associated with the default ACID.

All 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 and utilized as described in the Model 204 documentation. For example, see the Model 204 security features topic.

User 0 login

When the CA-Top Secret Interface is active, User 0 is validated as the owner of the Model 204 run, regardless of whether or not the execution is Online, BATCH204, IFAM1 or IFAM4, because User 0 has a higher ranking than an ordinary user.

Model 204 always attempts to log in User 0 automatically and verifies that any user ID supplied matches the ACID of the owner of the address space. It is not necessary to supply a user ID on the LOGIN command for User 0, because Model 204 determines the owner ACID 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 ACID 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 ACID specified by the installation.

Technical Support recommends that no user ID be specified 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 a user ID is supplied for User 0, no password is necessary 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 ACID of the address space or the default ACID.

AUTHCTL VIEW command

With the AUTHCTL VIEW command, you can view the interface control options currently in effect for the active interface. As of version 7.7 of Model 204, the command also displays a list of all the sets of control options that are available to the interface (and potential values of the SECPLIST parameter).

For example, if you enter:

AUTHCTL VIEW

Or:

AUTHCTL VIEW TOPSECRET

You see a list something like the following, which might be preceded by a list of available option sets, as described above:

TOP SECRET INTERFACE OPTIONS ACID M204TEST TOPSECRET CONTROL ACID NAME COMACID M204COM TOPSECRET COMMON CONTROL ACID NAME VALIDATE ACCOUNT VALIDATION OPTION IN EFFECT PRIORITY LOW PRIORITY DEFAULT DLMCHECK USE $JOB DLM CHECKING OPTION M204USR DEFAULT ACID

For information about setting control information, see Preparing a TOPSPARM parameter module with TOPSGEN.

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 CA-Top Secret. User IDs defined to CCASTAT are not allowed to log in as trusted users. CICS users must be using the CA-Top Secret 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.

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:
  • 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:

• The following message:

  M204.2378: SECURITY TRUSTED LOGIN FEATURE DISABLED

  is generated when either of the following conditions applies:

  • 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 Model 204 job is not initialized, 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 one and eight bytes long:

  M204.2379: INVALID TRUSTED USERID LENGTH = length

Maintaining the CA-Top Secret Interface

This section discusses the user site requirements that must be met in order to activate the CA-Top Secret Interface.

At each CA-Top Secret site, a TSS administrator performs system-wide maintenance functions within CA-Top Secret. A TSS administrator is responsible for defining and maintaining the CA-Top Secret pseudo data sets and PERMITs for authorization that are eventually used by Model 204. The following discussions explain the Model 204 data that TSS administrators maintain within their scope of control.

All the CA-Top Secret specific functions are administered by the TSS administrator using the TSS command. The TSS command is described fully in the CA-Top Secret documentation.

Defining Model 204 to CA-Top Secret

A Model  Online is defined to CA-Top Secret using the Facilities Matrix, because the Online must run as a multiuser address space. Model 204 can be initiated as a started task or as a batch job, depending on local security requirements.

The definition of Model 204 can be done through Online TSS services or through a batch job. The following sample batch execution can be used to define Model 204 (assuming the USER1 entry in the Facilities Matrix is available). The sample entries related to multiuser address spaces are required; however, the other sample options are merely recommended. Different options, as described in the CA-Top Secret documentation, might apply depending on local security rules.

//JOBNAME JOB (other information)..... //*-----------------------------------------------------* //* ADD THE MODEL 204 FACILITY TO TOP SECRET. * //*-----------------------------------------------------* //BATCHTSO EXEC PGM=IKJEFT01,REGION=300K //SYSPRINT DD SYSOUT=A //SYSTSPRT DD SYSOUT=A //SYSTSIN DD * TSS MODIFY('FAC(USER1=NAME=MODEL204)') TSS MODIFY('FAC(MODEL204=NOABEND,ASUBM,AUTHINIT)') TSS MODIFY('FAC(MODEL204=ID=M)') TSS MODIFY('FAC(MODEL204=NORNDPW)') TSS MODIFY('FAC(MODEL204=ACTIVE,LCFCMD,LUMSG)') TSS MODIFY('FAC(MODEL204=STMSG,MULTIUSER,PGM=ONL)') TSS MODIFY('FAC(MODEL204=RES,SIGN(M),SHRPRF,NOTSOC)') TSS MODIFY('FAC(MODEL204=WARNPW,XDEF)') TSS MODIFY('FAC(MODEL204=DEFACID(M204USR))') //

Note the following information regarding the above entries:

• USER1 can be changed to any open Facility Matrix entry available at the installation. The name specified for the NAME= entry can be changed to any name if the ACID used to define Model 204 uses this same name as its Master Facility.
• NOABEND and AUTHINIT are required entries to prevent abends due to user errors and security abends because Model 204 issues RACINIT commands. The ASUBM option is used if job submission is allowed.
• ID=M is variable. It is used in CA-Top Secret reporting as a one-character facility identifier.
• MULTIUSER is required to support Online users. PGM=ONL is a required entry to authorize a Model 204 use of security commands, and identifies the first three characters of the actual program name.
• DEFACID(M204USR) defines the default userid or ACID used to log users on who are defined in CCASTAT but not defined to TopSecret.

Defining the Model 204 ACID

Because facilities cannot own other objects, an ACID must be defined to be used as the main user when starting the facility. The name of this ACID is irrelevant to Model 204, but it might be useful to use the same name as the control ACID or common control ACID used for the pseudo data set names that Model 204 uses.

For example, the following TSS command can be used from a TSO terminal to define the ACID M204TPS:

TSS CREATE(M204TPS) TYPE(USER) FAC(STC,BATCH) PASS(NOPW) DEPT(department) NOSUBCHK MASTFAC(MODEL204) NAME('MODEL 204 ACID')

where the following options are the minimum required to be assigned to this ACID:

• CREATE(M204TPS) identifies the ACID to be created. (In a TSO environment, the ACID defined must be between one and seven characters long.)
• TYPE(USER) specifies that this is a user type ACID.
• FAC(STC,BATCH) indicates Model 204 can start as a batch job or started task.
• PASS(NOPW) specifies there is no password associated with this ACID. This should be changed in a secured environment.
• DEPT(department) specifies the department that owns and is responsible for this ACID.
• NOSUBCHK allows this ACID to bypass job submission checking, allowing this user to submit jobs. The submitted jobs must contain the USER= and PASSWORD= parameters.
• MASTFAC(MODEL204) indicates that this ACID’s master facility is MODEL204 (assuming MODEL204 was the name assigned to the facility).
• NAME('MODEL 204 ACID') simply assigns a name to the ACID.

This entry can be duplicated with a different ACID name if a common ACID is defined for pseudo data set name ownership that is shared between several copies of Model 204.

Defining the Model 204 default user ACID

Define a default ACID for Model 204. This ACID is named in the TOPSGEN MACRO, and it is used to limit the authorizations for Model  204 users that log in while still on CCASTAT. The ACID probably has minimal authority if used at all.

For example, the following TSS command can be used from a TSO terminal to define the ACID M204USR (that is, the default used by Model 204):

TSS CREATE(M204USR) TYPE(USER) FAC(MODEL204) DEPT(department) PASSWORD(M204PASS,0) NOPWCHG NAME('M204 DEFAULT USER')

where:

• CREATE(M204USR) names the ACID to be created. This name must match the name in the TOPSPARM parameter module or must be setup as M204USR, which is the default. Model 204 attempts to log in this user during initialization, and if unsuccessful, users on CCASTAT are denied login privileges.
• TYPE(USER) means that this is a user type ACID.
• FAC(MODEL204) indicates that this user can use the Model 204 facility.
• PASSWORD(M204PASS,0) establishes the password for this user (the default or it must match the DEFPASS entry in TOPSPARM). The 0 entry indicates that this password never expires.
• DEPT(department) names the department that owns and is responsible for this ACID.
• NOPWCHG indicates that this user is not allowed to change the password. This prevents a user from logging in to Model 204 and accidently changing the password, which would then cause a login failure for M204USR the next time Model 204 is initialized.
• NAME('M204 DEFAULT USER') assigns a name to the ACID.

Allowing users to log in to Model 204

The following TSS command is required to allow a user access to the Model 204 facility:

TSS PERMIT(acid) FAC(MODEL204)

where:

FAC(MODEL204) identifies the facility name under which Model 204 was set up.

Defining user privileges

The privilege names that Model 204 uses are based on pseudo data set profiles. The CA-Top Secret CREATE and ADD commands are used just as if a data set were being defined, but it really describes a resource profile for Model  204. This method provides the simplest way to describe resources.

In the following examples, the simplest set of conditions is described. The system manager can use all CA-Top Secret options (for example, auditing when a resource is used, changing the *ALL* authority, or naming a specific owner of the pseudo data sets). The system manager also uses security access levels for both the profiles and the PERMITs or REVOKEs for users of those profiles.

The interface requires that users authorized for pseudo data set resources are permitted read access.

One of the tasks that the TSS administrator must perform is to identify user privilege names as CA-Top Secret pseudo data set names.

The user privilege names listed in the following table define the Model 204 privilege types for a user. These names are further qualified by the control ACID name entered in TOPSPARM CSECT. See the LOGCTL command page for more information on the LOGCTL settings.

User privilege names and privileges

This user privilege...	Defines a user...	LOGCTL setting
'acid.PRIV.SUPER .USER'	With superuser privileges. A user with read access to this profile can create a file with the Model 204 CREATE command.	X'80'
'acid.PRIV.SYSTEM .ADMIN'	With Model 204 system administrator privileges. A user with READ access to this profile can issue commands such as LOGWHO, MONITOR, PRIORITY, and WARN.	X'40'
'acid.PRIV.CHANGE .FILE.PASSWORD'	Who can change the file password that is used to open a file. This privilege is valid only if the file being opened is secured through Model 204 facilities (that is, the file entry is stored in CCASTAT).	X'20'
‘acid.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 (for example, LOGCTL, AUTHCTL VIEW, DUMPG).	X'08'
'acid.PRIV.OVERRIDE .RECORD.SECURITY'	Who can override record security. A user with read access to this profile can do so.	X’04’

Sample definition of Model 204 pseudo data set names

CA-Top Secret pseudo data set names, which correspond to the defined privileges, must be defined to CA-Top Secret. This step is necessary, because an ACID must be assigned ownership of the pseudo data sets before permission can be granted to use them.

The CA-Top Secret statements used to define the standard Model 204 privileges and other resources to CA-Top Secret in a batch TSO execution are shown in the following example, which assumes M204TPS as both the control and common control ACIDs:

//JOBNAME JOB (other information) //DOIT EXEC PGM=IKJEFT01,DYNAMNBR=20 //SYSTSPRT DD SYSOUT=A //SYSTSIN DD * TSS ADD(M204TPS) DSN('acid.PRIV.SUPER.USER' TSS ADD(M204TPS) DSN('acid.PRIV.SYSTEM.ADMIN' TSS ADD(M204TPS) DSN('acid.PRIV.CHANGE.FILE.PASSWORD' TSS ADD(M204TPS) DSN('acid.PRIV.SYSTEM.MANAGER' TSS ADD(M204TPS) DSN('acid.PRIV.OVERRIDE.RECORD.SECURITY' TSS ADD(M204TPS) DSN('comacid.PRIORITY.HIGH' TSS ADD(M204TPS) DSN('comacid.PRIORITY.STANDARD' TSS ADD(M204TPS) DSN('comacid.PRIORITY.LOW' TSS ADD(M204TPS) DSN('comacid.ACCOUNT.nnnnnnnn'

nnnnnnnn represents an account number; there are as many as required.

The DSN prefix is irrelevant, but probably is the same as the control ACID for simplicity’s sake.

Next, permission to have these privileges would be granted to specific ACIDs or groups of ACIDs via profiles. The following sample TSS PERMIT gives a user Model 204 system manager authority:

TSS PER(useracid) DSN('acid.PRIV.SYSTEM.MANAGER') ACCESS(READ)

acid.PRIV.privilege specifies one of the fixed types that Model 204 uses to build CA-Top Secret search keys for the rules. This is the CA-Top Secret control ACID defined to Model 204 by the TOPSPARM parameter.

Another sample TSS PERMIT assigns a user all Model 204 privileges:

TSS PER(useracid) DSN('acid.PRIV.-') ACCESS(READ)

This CA-Top Secret PERMIT statement permits the specified user ACIDs to access the named resources. Rules for determining the authorized user are described in the CA-Top Secret documentation.

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 a CA-Top Secret violation.

CA-Top Secret default ACID

The default ACID limits the authorization of users that have not logged in to CA-Top Secret directly (that is, users still defined in CCASTAT). Each user not logged directly in to CA-Top Secret is assigned the authorization provided by CA-Top Secret for the default ACID. The authorization includes all data set access authorization as well as job submission, and so on.

Attention: If other Rocket Software products are to be installed, it is essential that the default ACID be able to log in and have the appropriate access privileges to data sets that might be read or written during installation. For example, if the default user cannot log in, all installation JCL that is supplied must be modified to provide valid login statements for valid CA-Top Secret ACIDs.

The default ACID automatically is assigned the ACID M204USR with the password M204PASS. An ACID of this name must be defined to CA-Top Secret for CCASTAT-defined users to be able to log in.

For security purposes, the system manager cannot modify this ACID and password. If different data is required or if the installation would like to change defaults, the parameter module TOPSPARM must be modified by the TSS administrator or systems programmer or both.

TOPSPARM allows you to override the default ACID and password. This module can be made available during the Model  204 link-edit. Otherwise, Model 204 loads it when the interface is initialized. If the module is loaded, it must be made available in the STEPLIB containing Model 204 or in a system load library. Be sure TOPSPARM resides in an APF-authorized load library so that it does not cause the Model 204 load module to lose its APF authorization. The TOPSPARM module is generated with the TOPSGEN macro.

Terminal security considerations

CA-Top Secret can enforce terminal security when a user logs in. At that time, the source of the login is passed to CA-Top Secret. For systems running Model 204 with the SNA Communications Server 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 no secured mechanism in CRAM identifies the source of the user. Because CRAM channel names can be identified as valid sources, the ACIDs 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.

Installing the CA-Top Secret Interface

CA-Top Secret can run in the following modes:

This mode...	Indicates that CA-TOP Secret is...
DORM	Installed but not actively validating activity.
WARN	Active but violations do not result in a failed request. WARN mode provides TSS administrators with the ability to tune definitions without affecting current activity. Violation messages are usually sent to users in this mode.
IMPL	Active and fails any unauthorized requests from defined ACIDs. Users not defined to CA-Top Secret execute normally, unless they access a protected resource.
FAIL	In full control of access requests. All users are defined and all resources are protected.

These modes can apply on a system-wide basis or to individual ACIDS. Model 204 works in all modes of operation.

Unless the ACIDs or the system are in FAIL or IMPL mode, access to Model 204 cannot be controlled, and access checks for data sets are ineffective. However, any WARN mode messages are issued to the user.

Unless ACIDs using Model 204 operate in FAIL or IMPL mode, users can log in and receive very high Model 204 privileges. Because privilege checks consist of asking CA-Top Secret if the user has read access to a pseudo data set name, CA-Top Secret indicates that access is authorized, and the user receives all privileges.

SECPLIST parameter

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

If the SECPLIST parameter is not in CCAIN, TOPSPARM is used as the default name of the argument set. If no match is found for this name and the name in the TOPSPARM module, the interface is initialized using the default parameters precoded in the CA-Top Secret Interface. In this case, Account and Priority validation are not performed.

The following TOPSPARM module contains two sets of CA-Top Secret arguments.

• In the first set, the name is LOG1, and account security is in effect.
• In the second set, the name is LOG2, and both account and priority security are in effect.

TITLE 'TOPSPARM MODULE' LOG1 TOPSGEN TYPE=CSECT, X ACID=M204PROD, X COMACID=M204TPS, X PRTY=H, X VALIDAT=ACCOUNT, X DEFACID=, X DEFPASS=, X LOG2 TOPSGEN TYPE=CSECT, X ACID=M204TEST, X COMACID=M204TPS, X PRTY=S, X VALIDAT=(ACCOUNT,PRIORITY), X DEFACID=M204ACID, X DEFPASS=DEFPASS, X TOPSGEN TYPE=END END

Preparing a TOPSPARM parameter module with TOPSGEN

The TOPSGEN macro of the TOPSPARM module lets the system manager, TSS administrator, or system programmer generate a set of arguments that govern login and other security processes. There can be multiple argument sets in a TOPSPARM module. The TOPSPARM parameter module can be linked with Model 204 or dynamically loaded when the CA-Top Secret Interface is initialized. Dynamic loading allows for more flexibility in making TOPSGEN changes, but TOPSPARM must always reside in an APF-authorized load library.

The following is a sample TOPSGEN macro:

TITLE 'GENERATE A TOP SECRET PARAMETER MODULE' NAME TOPSGEN ACID='M204TOPS', Control ACID X COMACID='M204TOPS', Common control ACID X PRTY=S, Priority X VALIDAT=, Validation items X DEFACID=, Default ACID X DEFPASS='M204PASS', Default ACID password X DLMCHECK/NODLMCHECK DLM= checking X TOPSGEN TYPE=END END

Where:

NAME	Defines the name of this set of CA-Top Secret arguments. Because there can be any number of argument sets in the TOPSPARM module, each set must be given a unique name. There is no default name, but Technical Support recommends that you name one TOPSPARM for jobs that do not specify a SECPLIST value in CCAIN.
ACID	Specifies the 1- to 8-character CA-Top Secret control ACID name selected by the installation. The rules for Model 204 privileges are defined and owned by this ACID and stored in CA-Top Secret. The ACID name must match the pseudo data set profile high-level qualifier defined to CA-Top Secret in the CREATE statements for the pseudo data sets, all of which take the form of acid.keyword.variable.data. The default is M204TOPS. This control ACID is used to create a separate set of privilege definitions for an individual copy of Model 204, allowing an installation to have differing privileges for a test and production version.
COMACID	Specifies the 1- to 8-character common ACID name selected by the installation. The rules for the VALIDATE ACCOUNT and PRIORITY options are defined and grouped by this ACID and stored in CA-Top Secret. The common ACID name must match the pseudo data set high-level qualifier defined to CA-Top Secret in the CREATE statements for the pseudo data sets, all of which take the form of comacid.keyword.variable.data. The default is M204TOPS, if an ACID name is not specified. Note: This option is used to create a common set of privilege definitions shared between copies of Model 204.
PRTY	Specifies a default priority for any user who successfully logs in through CA-Top Secret. Options are H (high), S (standard), L (low), or N (none). The default priority is S, if the PRIORITY keyword is not entered. For more information about the PRIORITY parameter, refer to Priority scheduling.
VALIDAT	Specifies validation options for execution at login time. Any operands supplied for this macro must be enclosed in parentheses and separated by commas. Multiple validation types can be specified for the interface. VALIDAT argument options are as follows: ACCOUNT specifies that any account entered by the user during the login process is validated by CA-Top Secret. The VALIDAT ACCOUNT option verifies with CA-Top Secret that the account value entered by the user is permitted. If so, the user is allowed in to Model 204. If not, the login fails. This validation uses the comacid.ACCOUNT.account# pseudo data set. PRIORITY verifies what priority the user has. 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 following pseudo data sets: comacid.PRIORITY.HIGH comacid.PRIORITY.STANDARD comacid.PRIORITY.LOW comacid.PRIORITY.NONE Validation is checked from highest to lowest priority. If a user is permitted read access to one of these priorities, the value is assigned. If no PERMIT is found and a standard priority is not specified, the user’s priority is set to standard.
DEFACID	Defines the default ACID to be used for users defined in CCASTAT but not defined to TopSecret. If this is a valid TopSecret ID then users defined in CCASTAT are allowed to log on. For more information about this default, see Defining the Model 204 default user ACID. If DEFACID=JOBNAME, then the user ID associated with the submitted job is used as the DEFACID and CCASTAT logons are allowed.
DEFPASS	Defines the default PASSWORD for the default ACID if the user is not directly logged in through CA-Top Secret.
DLMCHECK/NODLMCHECK	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 a job to be submitted that can itself submit other jobs. This is a potential security compromise. The DLMCHECK/NODLMCHECK argument lets you 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 publications; any other parameters supplied result in an error. If there is a job statement following the offending statement, Model 204 appends USER=...,PASSWORD= to the job statement set as if it is an independent job. 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 submission. DLMCHECK is the default.

The result of the TOPSGEN macro assembly 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 TOPSPARM as a separate load module, use the SECRLINK job in the JCL library. Modify the job according to the comments.

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

INCLUDE OBJLIB(TOPSPARM)

Model 204 link-editing requirements

To support multiple Model 204 logins for different ACIDs, Model 204 must be linked to an authorized library using the appropriate link-edit services. This means that any Online multiuser 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 or that the user ID exists on CCASTAT. Otherwise, the login fails.

Setting 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 since 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 list identifies the general tasks that must be completed to install and activate the CA-Top Secret Interface.

Attention: If other Rocket Software products are to be installed, it is essential that the default ACID be able to log in and have the appropriate access privileges to data sets that might be read or written during installation. For example, if the default user cannot log in, all installation JCL that is supplied must be modified to provide valid login statements for valid CA-Top Secret ACIDs.

Conversion checklist for CA-Top Secret

Step	Task
1.	Define Model 204 as a CA-Top Secret facility.
2.	Define the Model 204 control ACID (and common ACID if used).
3.	Define the Model 204 default user ACID if you allow CCASTAT IDs to log in.
4.	Define the Model 204 user privilege pseudo data sets.
5.	Permit users to use the Model 204 facility.
6.	Permit users to have appropriate Model 204 privileges.
7.	Use TOPSGEN to create a TOPSPARM parameter module.
8.	Link-edit TOPSPARM with SECRLINK for dynamic link with Model 204 during initialization. or Link-edit Model 204 with TOPSPARM.
9.	ADD the SECPLIST parameter in user zero input in CCAIN.
10.	Move the Model 204 facility to WARN mode for testing.
11.	Move the Model 204 facility to FAIL mode for execution.

See also

• Security interfaces overview