CONNECT security checks for AORs

The security checks performed at CONNECT time provide two levels of security, bind security and file security.

  • Bind security allows an FOR that runs without CICS® file security to be able to restrict shared access to selected AORs. (Running without file security minimizes runtime overheads and the number of security definitions.)
  • File security can be activated in the FOR if you want SDT to implement those checks that apply to the AOR as a whole.

Note that SDT provides no way of implementing those security checks that an FOR makes at the transaction level when ATTACHSEC(IDENTIFY) or ATTACHSEC(VERIFY) is used with function shipping.

Bind security

To be allowed shared access to any of an FOR's data tables, an AOR's user ID needs READ (or higher) access to the FOR's DFHAPPL.applid in the FACILITY class.

This check is never bypassed, even when SEC=NO is specified at system initialization. In the following example definitions, three CICS AORs (user IDs are CICSAOR1, CICSAOR2, and CICSAOR3) all require SDT access to the FOR represented by the DFHAPPL.CICSHF01 profile: 
PERMIT DFHAPPL.CICSHF01 CLASS(FACILITY) ID(CICSAOR1 CICSAOR2 CICSAOR3)
       ACCESS(UPDATE)

Cases when SAF neither grants nor refuses access are resolved in the same way as for server LOGON (see If SAF neither grants nor refuses an access request). If the result is a refusal, CICS does not permit shared access by the AOR to the FOR's APPLID.

Note that controlling SDT server authorization security and bind security by using different (but hierarchical) levels of access to the same resource has the following consequences:
  • Any region with the same user ID as a server can always bind to that server.
  • It is impossible to control which user IDs can bind to a given APPLID without also controlling which user IDs can log on as servers for that APPLID.

SDT bind-time security uses different definitions from those employed by IPIC, ISC, and (if using preset sessions) MRO. Therefore, unless you make them consistent, SDT access might be granted when function shipping attempts are rejected, or vice versa. Both MRO and SDT use the same class and so, with ISC only, SDT CONNECT security might react to changes in security definitions either earlier or later than function shipping.

If file security is not in force in the FOR (that is, if SEC=NO or XFCT=NO was specified at system initialization), an AOR that is allowed to bind to an FOR is also allowed to access all that FOR's shared data tables.

If file security is in force, an AOR that is allowed to bind is still allowed free access if the user IDs of the AOR and FOR are the same (undefined user IDs are not considered to be the same).

File security

After the bind-security check, and when file security is in force in the FOR, the FOR checks whether the AOR is authorized to sign on to the FOR.

This security check is optional, and applies only when the user ID of the AOR is different from that of the FOR. It is the equivalent of ATTACHSEC(LOCAL) in an MRO environment (see MRO user security). The AOR also requires READ authorization to the file it is trying to access in the FOR.

To implement file security checking by the FOR:
  • Initialize the FOR with system initialization parameter SEC=YES
  • Authorize the AOR with READ access to the FOR's APPLID profile in the APPL general resource class
  • Specify the appropriate value on the XFCT system initialization parameter
  • Authorize the AOR's region user ID with READ access to the required files in the file resource profiles named on the XFCT system initialization parameter.

For example, define the APPL profile for an FOR with APPLID CICSHF01, and the PERMIT command to enable the AORs with user IDs CICSAOR1 and CICSAOR2 to sign on to CICSHF01, as follows:

RDEFINE APPL CICSHF01 UACC(NONE) NOTIFY(sys_admin_userid)
PERMIT CICSHF01 CLASS(APPL) ID(CICSAOR1 CICSAOR2) ACCESS(READ)

Cases when SAF neither grants nor refuses the request are resolved in the same way as for server LOGON (see If SAF neither grants nor refuses an access request).

If the user ID is allowed to sign on to the FOR's application, the CONNECT request succeeds unless the AOR's user ID is not allowed to read the specified file. Otherwise, the CONNECT request is treated in the same way as when the AOR's user ID is undefined.

When file security is in force in an FOR, and the user ID of the AOR is undefined, a CONNECT request fails unless the FOR's default user ID (specified by the DFLTUSER system initialization parameter) is allowed to read the specified file.

Function shipping detects that an AOR's access to a file has been revoked when a rebuild of the file control resource class is completed in the FOR. However, if a valid connection exists, SDT continues to allow access until something causes the connection to be broken. See Caching of RACF classes and their profiles.

CAUTION:
If you use ISC instead of MRO for function shipping, ensure that the value of the SECURITYNAME parameter in the FOR is the same as the user ID of the AOR. If you use IPIC instead of MRO for function shipping, ensure that the value of the IPCONN SECURITYNAME parameter or, if applicable, the AOR's certificate's user ID in the FOR is the same as the user ID of the AOR. Otherwise, the SDT CONNECT, and function shipping security checks are inconsistent.