This section explains how to use additional CA Top Secret FACILITY suboptions.
Use the MAXUSER= suboption to limit the amount of storage allocated by CA Top Secret CICS for session related tokens (SRTs), which are GETMAINed at CICS initialization time. The MAXUSER value is used to calculate the number of SRTs CA Top Secret CICS allocates to maintain a reference point for each signed‑on user. If, during the life of the CICS region, the MAXUSER value is exceeded, additional SRTs are dynamically allocated to handle the new signon requests.
Note: The count for MAXUSER also includes MRO/ISC link signons and ATS (Automatic Terminal Signon) events. When setting this value, make sure you include MRO/ISC links and ATS terminal signons with the number of signed on users per CICS region.
For example, to limit the number of users (via User Control Blocks) via the CICS Payroll region to 500, you can use the TSS MODIFY command like this:
TSS MODIFY (FACILITY(CICS=MAXUSER=500))
The MAXUSER= suboption allocates the ACEEXREF cross reference table. This table:
Note: After changing the MAXUSER FACILITY suboption, you must recycle your CICS region for the changes to take effect.
Use the MAXSIGN= suboption to restrict the number of signons (or signoffs) that are made simultaneously by users. This suboption lets you set a threshold for the number of user signons that can be made concurrently, and controls the action taken if the threshold is exceeded. The default threshold is 10 (ten users can sign on/sign off concurrently). You can change the default threshold; valid values are 5 to 100, inclusive. For example, to change the threshold so 15 users can sign on concurrently, enter the following command. Note that the parentheses around the value are required.
TSS MODIFY FACILITY(CICSPROD=MAXSIGN=(15))
The action for MAXSIGN= can be set to KILL or RETRY. When KILL is set and the threshold of the queue is reached, all additional attempts to sign on or off are abended. For example, if you set the threshold for a CICS facility called CICSPAY at 15 and specify KILL as shown below, if 18 users try to sign on to CICSPAY concurrently, the first 15 users in the queue are signed on and the last three users receive a message and their attempt is abended.
TSS MODIFY (FACILITY(CICSPAY=MAXSIGN=(15,KILL))
When RETRY is set and the threshold of the queue is reached, all additional attempts to sign on are requeued to CICS. For example, if you set the threshold of a CICS facility called CICSPROD at 50 and specify RETRY as shown below, if 60 users try to sign on to CICSPROD concurrently, the first 50 users in the queue are signed on and the last 10 are sent back to CICS to be requeued.
TSS MODIFY FACILITY(CICSPROD=MAXSIGN=(50,RETRY))
The MASTFAC facility control suboption SIGN(M) might be set to allow concurrent signons by an ACID within a CICS region from multiple nodes or terminals. The CICS administrator should be careful that the SIT parameter SNSCOPE=CICS or NONE is set with this setting.
The MASTFAC facility control suboption SIGN(S) might be set to disallow concurrent signons by an ACID within a CICS region from multiple nodes or terminals. The CICS administrator should be careful that the SIT parameter SNSCOPE=CICS or NONE is set with this setting.
The SIGNMULTI attribute allows an administrator to provide for multiple concurrent signon by an ACID in spite of the facility sub‑option SIGN(S). The SIGNMULTI attribute might only be provided through an individual facility. If a user already has access to the facility, it must first be removed:
TSS REMOVE(acid) FACILITY(cicsfac)
To provide SIGNMULTI access to the facility, use the following command:
TSS ADD(acid) FACILITY(cicsfac)
SIGNMULTI
The SIGNMULTI feature will only be honored when SIT parameters SNSCOPE=CICS or SNSCOPE=NONE are set. CA Top Secret will update the SIT SNSCOPE definition as follows, only if SIGN(S) is specified on the FACILITY:
SNSCOPE is a CICS SIT parameter which controls the scope in which duplicate signons are allowed at local terminals, or signing on after using the CRTE transaction to connect to another system. At CICS startup, CA Top Secret will honor the values SNSCOPE=MVSIMAGE or SYSPLEX: these values must only be used with facility sub‑option SIGN(M); when these values are selected, SIGNMULTI is overridden by CICS. When SNSCOPE=CICS or NONE, CA Top Secret forces the SNSCOPE=NONE: in this case, duplicate signon processing is controlled entirely by CA Top Secret.
The signon scope (SNSCOPE) is enforced with the MVS ENQ macro where there is a limit on the number of outstanding MVS ENQs per address space. If this limit is exceeded, the MVS ENQ is rejected and CICS is unable to detect if the user is already signed on. When this happens, the signon request is rejected with message DFHCE3587. See the OS/390: MVS Programming: Authorized Assembler Services Guide for guidance on increasing the MVS ENQ limit.
Use the DSNCHECK(YES|NO) suboption to perform CA Top Secret security checking on the FCT name or the DSN facility name.
The RESOURCE FACILITY suboption is required for DSNAME name protection. The RESOURCE suboption brings the user's DSNAME and VOLUME permissions into storage and increases CA Top Secret memory requirements.
To indicate that security checking should be performed on all DSNAME names in the CICS Production 1 region, you can enter a command like this:
F TSS,FACILITY(CICSP1=DSNCHECK=YES,RES)
If only FCT checking is required, then the command would look like this:
F TSS FACILITY(CICSP1=DSNCHECK=NO,NORES)
For security checking on all data set names in the CICS Production 2 region, you can enter a command like this:
TSS MODIFY FACILITY(CICSP2=DSNCHECK=YES,RES)
Note: To provide protection for remote DSNAMEs, you must remove the CSMI transaction from the FACILITY TRANID Bypass List of the remote region. Security checking is performed in the region where the FCT resides.
CICS data set protection (DSNCHECK=YES) does not protect DL1 databases. CICS resources PSB and DBD are used in the CICS environment for this purpose.
A surrogate user is a user who has the authority to start work on behalf of another user. A surrogate user is authorized to act for that user without knowing the other user's password. There are two ways to enable surrogate user checking:
If surrogate user checking is employed, it applies to:
If a userid is specified on the EXEC CICS START command, then this user is the one who is associated with the started non‑terminal (background) transaction.
If the userid in the START command is not the current user, then the current user must be authorized to the userid specified on the START command.
For example, if the signed on userid is CURRUSER and the following command is issued:
EXEC CICS START TRANID('ABC') USERID('STARUSER')
You must permit authority for the SURROGAT resource by issuing the following commands:
TSS ADD(cicdept) SURROGAT(STARUSER)
TSS PER(CURRUSER) SURROGAT(STARUSER.DFHSTART)
ACC(UPDATE)
If the signed on user issues the command without USERID:
exec cics start tranid('ABC')
Then transaction ABC is started under the authority of the initiating user CURRUSER and no surrogate checking is performed.
To activate surrogate checking on background transactions, XUSER=YES and RES must be set in the CICS facility. For example:
TSS MODIFY FACILITY(CICSPROD=RES,XUSER=YES,FACMATRX=YES)
In the case that FACMATRX=NO, RES must still be set in the facility, but XUSER=YES must be set in the CICS SIT, for example:
TSS MODIFY FACILITY(FACMATRX=NO,RES)
There are two ways you can use the PCTCMDSEC= suboption:
To perform security checking for all commands enter:
TSS MODIFY FACILITY(PAYACCT1=PCTCMDSEC=OVERRIDE)
To selectively perform security checking for specific commands (and honor the TRANSACTION CMDSEC setting) enter:
TSS MODIFY FACILITY(PAYACCT1=PCTCMDSEC=HONOR)
You can use the PCTRESSEC= suboption to perform security checking for the program, file, transient data, and temporary storage resources.
There are two ways you can use the PCTRESSEC= suboption:
To override native CICS transaction RESSEC security checking with CA Top Secret for all resources, enter:
TSS MODIFY FACILITY(PAYACCT1=PCTRESSEC=OVERRIDE)
To selectively perform security checking for specific transactions (and honor the DFHPCT RESSEC setting) enter:
TSS MODIFY FACILITY(PAYACCT1=PCTRESSEC=HONOR)
The data for Record Level Protection (RLP) and Screen Level Protection (SLP) is stored in the Static Data Table (SDT). Before you can enable RLP and SLP you must first initialize the SDT using the SDTBLOCKS parameter of TSSMAINT. You must then extend your old SECFILE into your new SECFILE using TSSXTEND.
The RLP=NO and SLP=NO suboptions are set by default in the CICS facilities. SLP can be dynamically modified during CICS execution. However, RLP cannot be activated dynamically because it requires file exits that are only installed by CA Common Services for z/OS during CICS initialization
RLP can be deactivated dynamically because CA Top Secret reviews the caller's RLP facility setting on every RACROUTE call.
You can use the PCLOCK= suboption to control whether TSS LOCKTIME processing operates conversationally (PCLOCK=NO, default) or pseudo‑conversationally (PCLOCK=YES). You cannot set this option dynamically while a CICS region is running and it takes effect only during CICS initialization.
To enable pseudo‑conversational locktime, set the PCLOCK facility suboption to YES.
TSS MODIFY FACILITY(CICSPROD=PCLOCK=YES)
To disable pseudo‑conversational locktime, set the PCLOCK facility suboption to NO.
TSS MODIFY FACILITY(CICSPROD=PCLOCK=NO)
Note: If you are using the TSSPGM02 password prompt exit, be aware that this interface has been modified to support use in pseudo‑conversational mode. Installations that use this exit program will need to modify their code. A new flag has been added in the incoming COMMAREA to indicate to the program whether it should issue a SEND or RECEIVE or a conversational prompt. A sample program is supplied in CAI.CAISRCS (member TSSPGM02).
The PCLOCK=NO suboption is set by default in CICS facilities. It cannot be activated dynamically during CICS execution. This option sets LOCKTIME processing to conversational mode.
The PCLOCK=YES subopotion sets CA Top Secret LOCKTIME processing to pseudo‑conversational processing. Users might prefer the efficiency of this option.
Note: PCLOCK=NO is preferred in non‑TOR MRO regions.
You can use the RLP= suboption to perform security checking for records within a CICS file (FCT). To enable Record Level Protection (RLP), you must take the following steps:
For example:
TSS MODIFY FACILITY(CICSPROD=XFCT=YES,RLP=YES)
You can use the SLP=suboption to perform security checking for terminal screen input data.
To enable Screen Level Protection (SLP), you must take the following steps:
For example:
TSS MODIFY FACILITY(CICSPROD=XTRAN=YES,SLP=YES)
To enable Enterprise Java Bean (EJB) Role Based Security, you must set XEJB to YES in FACILITY suboption or in CICS SIT Table. For example:
TSS MODIFY FACILITY(CICSPROD=XEJB=YES)
To use EJB Role Prefixing:
or
For example:
TSS MODIFY FACILITY(CICSPROD=EJBRPRFX=CICSPROD)
CICS session cache is now allocated according to the CICSCACHE facility sub-option. Allowed resources encountered during the life of the cache will be placed into the cache so that later accesses to the same resource will not result in I/O to the security file. This cache was once controlled by OPTIONS(28), the user may now enter the following commands:
TSS MODIFY FACILITY(cics_facility=CICSCACHE({TASKLIFE},{NOAUDIT},{512})
{SESSLIFE}{ AUDIT }{1024} 2048}{4096}
The CICS cache is allocated in the CICS region DSA. Use of persistent large cache size may require alteration in the DSA allocation and in the CICS region size. The default is designed to minimize the effects on storage requirements.
Keywords for this control sub-option are defined as follows:
Indicates that the cache will be allocated at the beginning of a CICS task and freed at the end of the task. This is the default.
Indicates that the cache will be allocated at signon and will persist without being cleared until the user signs off implicitly or explicitly or until the user is REFRESHed.
Indicates that allowed resources will not be audited if they are present in the cache. This is the default.
Indicates that allowed resources will be audited even if they are present in the cache.
Indicates the size (in bytes) of the cache to be allocated for users in this CICS facility. This parameter may be altered while a related CICS region is executing, but the change will not take effect until the region is recycled.
Using SESSLIFE can reduce I/O to the security file by allowing the product to check validity of previously validated resources in cache, rather than consulting the security file. Particularly for complex transactions with many resources access checks, SESSLIFE can improve the performance of CICS. On the other hand, changes to the security file, which normally would have prevented access, may be ignored for sessions, which overlap the changes.
Persistent SESSLIFE large caches for many simultaneous users may require changes to the DSA allocation and to the CICS Region size.
Using NOAUDIT can reduce I/O to SMF or ATF.
|
Copyright © 2014 CA Technologies.
All rights reserved.
|
|