This section discusses the following security features: Initialization Parameters, Logon Security, Security Practices for JOB Mode and Using SECLIST, Security User Exit SARSECUX, and Password Protection.
The SECURITY initialization parameter affects the operation of internal and external security.
For internal security, the SECURITY initialization parameter has three settings:
The SECURITY initialization parameter indicates whether to establish database security on the DEFMODE initialization parameter, user definition records, or external security calls.
If INIT is specified, a new user can access a database if the DEFMODE initialization parameter is not set to
NNNNNN; otherwise, the user name must be predefined to the database.
INTERNAL is similar to INIT except that the password for an existing user is verified with the predefined user definition.
LOGON uses your external security product to verify the USERID/PASSWORD, but no other security checks are performed.
The CA View security exit (SARSECUX) is still invoked. This allows you to write your own customized security model.
xUX user exits control CA View logon security. Internal and external logon security is provided as a standard feature. These user exits can, however, be customized for special security needs.
CA Roscoe/cross- memory
Security Practices for JOB Mode and Using SECLIST
JOB mode, an online mode, lets you collect and retain job information independent from archived reports. In JOB mode, you can select jobs (instead of reports) and perform several actions. For example, you can browse, print, or email either the jobs or the data sets in the jobs.
For details about JOB mode, see Using, the Release Notes, and Reference--Initialization, Database, and Batch Processing.
In JOB mode, the entire job is visible to users who have access to the job. However, if users do not have access to any DD's in the job, those DD’s are not displayed. Security administrators should account for this consideration when they assign users to JOB mode. For example, if an operator uses the CA View database to check logs or exceptions, first verify that they have access to the DD’s and jobs information that they need.
Next, if necessary, deny them access to potentially sensitive data that they do not need or should not access, for example, a payroll report from the job.
If denying users access to these kinds of reports and DD’s is problematic, then consider creating multiple data bases for different purposes, for example, one database for JOBLOG information and one or more databases for reports.
In a JOBLOG database, you typically store JOBLOG data for a short period and make the data available to all CA View users. Specify a maximum number of lines for files in this database, to limit the size of job logs that may contain a dump. For instructions to create and configure databases, see Maintain the Database (SARDBASE).
Also consider creating one or more data bases for reports, according to authorization level. For example, you can create a Finance database to store reports that only users in the Finance group can access. Similarly, you can create an HR database to store reports that only users in the Human Resources group can access, and so forth.
Consider using the SECLIST parameter of the SARINIT utility to specify whether a selection list shows all reports or only the reports that a user is authorized to access (view, email, print, and so forth). You use your external security product to specify which reports users can access, and you use SECLIST to specify which reports users can list. A request for a print of a job, or an email of a job, always includes only reports that are authorized for the requesting user.
If a user does not have access to any jobs that match the search criteria, then the following message displays:
No jobs selected
Creating multiple databases according to authorization levels helps you secure your data efficiently and effectively. Using SECLIST lets you specify which reports users can list.
Security User Exit SARSECUX
Use user exit SARSECUX to determine whether a user or job is authorized to access, update, or delete data within the CA View database.
SARSECUX is invoked for each individual entry that is being accessed, updated, or deleted. The Security Parameter List (mapped by the SARCPL macro) is passed to the exit. The list contains information about the authorization request such as the function being performed and the data being accessed.
Based on this information, access to the data can be granted, denied, or the product can be allowed to determine accessibility to the data. If the product is permitted to determine accessibility to the data, internal or external security can be performed based on the setting of the SECURITY initialization parameter.
For online retrieval, SARSECUX is invoked:
- For each entry to be displayed in a selection list
- When an entry in the selection list is selected for processing
For batch retrieval, SARSECUX is invoked:
- For each entry to be listed as a result of the LIST function
- When a SYSOUT group is selected for processing
For CA DRAS, SARSECUX is invoked:
- For each entry to be presented in a list
- When an entry in the list is selected for processing
CA View also provides security at the report level through user modes and private report viewing.
Authorization User Exit SARATHUX
Use user exit SARATHUX to determine whether a specified job is authorized to perform high-level database functions.
CA View passes the request type and request data that requires authorization to the exit. Based on this information, access to the data can be granted, denied, or the product can be allowed to determine accessibility to the database function. If SARATHUX it lets CA View determine accessibility to the database function, external security requests are issued to validate authorization.
The standard exit that is supplied with CA View authorizes all jobs to perform all database functions. If external security is wanted for database functions, install the SARATHU1 CVDEOPTN source member with CVDEJCL member BRMSATHX.
CA View provides batch and online facilities for defining user IDs and passwords to a database.
If you do not want external security, these user ID and password definitions can be used to verify user access to a database.
For internal user ID and password security, set the SECURITY initialization parameter to INTERNAL.