Protecting FOCUS Databases: the FOCUS/SU Security Interface (SUSI)

In this section:

The FOCUS/SU Security Interface ensures that FOCUS databases controlled by FOCUS Database Servers will be properly protected by third-party security packages, such as RACF®, CA-ACF2®, or CA-TOP SECRET®. The Interface uses the external security package to check authorization for specific source user IDs and specific data sets, as if the source user ID requested the data set locally.

The FOCUS/SU Security Interface augments existing FOCUS DBA security for FOCUS applications. It does not affect local users or non-SU files.

The FOCUS/SU Security Interface is included on the FOCUS distribution tape. For installation instructions, see the z/OS Installation Guide.


Top of page

x
Using the SU Security Interface

To use the FOCUS/SU interface, insert the following command in the SU profile:

SET SUSI=ON

The SU profile is member HLIPROF of a PDS allocated to ddname FOCEXEC in the server startup JCL.

Once the Interface is installed, you must change all FOCUS Database Server jobs to execute the program HLISECUR, rather than HLISNK, as on the following EXEC card:

//SINK EXEC PGM=HLISECUR,PARM='parameters'

You can use the same password and ECHO or STAT parameters for HLISECUR as for HLISNK.


Top of page

x
How the FOCUS Database Server Invokes the Security Interface

The FOCUS Database Server invokes the FOCUS/SU Security interface (SUSI) when a user executes a request against a shared database on the server. When a user opens a database, the FOCUS Database Server asks the security system if the user is authorized to read and/or write to that database.

For MODIFY/Maintain requests, users must have both read and write access. Authorization is checked twice: first for read access and then for write access. Both authorization checks are done for all MODIFY/Maintain requests, including read-only MODIFY/Maintain requests. Cross-referenced flies are also checked for read access.

For TABLE requests, a read-access authorization check is done each time FOCUS reads page 1 of a database. This includes cross-referenced files and files linked with JOIN. HLI/SU users are checked for read and write authorization at the time that the OPN command is issued.


Top of page

x
How the FOCUS Database Server Checks Access Rules

The FOCUS/SU Security Interface accesses z/OS security packages using the RACINIT and RACHECK variants of the RACROUTE macro. These functions trigger security routine execution through the System Authorization Facility (SAF), rather than by native RACF. Since security packages, such as RACF, CA-ACF2, and CA-TOP SECRET, all interface to SAF in the same way, the FOCUS/SU Security Interface operates transparently with any of these packages.

The FOCUS Database Server may discover data sets that are not protected by the external security system (that is, no specific security rule has been written for that data set). In this case, the server next checks to determine if the source user has security access to the high-level qualifier of the data set. If no rule was written for the high-level qualifier, the server rejects the request from the source user.

In addition to observing the rules protecting databases from source user access, the FOCUS Database Server must itself be authorized to open the databases under its control.


Top of page

x
How the FOCUS Database Server Manages the Number of Users

How to:

When users first access a database controlled by the FOCUS Database Server, the server issues an authorization request to the external security package as if it were the source user. It then keeps a list of active users known to the external security system in a table that has a fixed number of slots. The default is 32 users. The user ID stays in the list until the last user has logged off.

When the user table is filled, the server removes the oldest user from the list and adds a new user. This enables more than 32 users to use the server concurrently, but only the most recent 32 remain on the active list for the external security system at one time. This benefits those making frequent requests against server databases. If a user was removed from the list (because 32 other users made more recent requests), a subsequent request from the inactive user causes the FOCUS Database Server to issue a new authorization request to the external security package.

Since each authorized user slot requires approximately 256 bytes of common storage area (CSA), you may choose to limit the number of entries the table. You can control the number of entries in the user table through the command SET SUTABSIZE.



x
Syntax: How to Set the Maximum Number of Entries in the User Authorization Table
SET SUTABSIZE={nnn|32}

where:

nnn

Is a number from 2 to 256. The default value is 32.

Place this command in the profile for the FOCUS Database Server, which is member HLIPROF in a PDS allocated to ddname FOCEXEC by the server job.

Note that the use of this command does not affect the number of users who can simultaneously access the server. SUTABSIZE simply provides a way to put a ceiling on the amount of CSA used by the Interface.

If you increase the size of the user table above the default size of 32, CSA utilization will increase by approximately 256 bytes for each slot being used. Note that the 256 bytes of CSA per user is only used if a user occupies that slot in the table. If the value of SUTABSIZE is larger than the number of active users, the amount of CSA used is not affected by changing the setting of SUTABSIZE.


Top of page

x
Authorization Error Messages

The following error will occur when a source user ID attempts to access a file to which it does not have access:

(F0C517) SU.ACCESS DENIED BY EXTERNAL SECURITY SYSTEM:

This message indicates that the external security system (CA-ACF2, RACF, or CA-TOP SECRET) determined that the user has no access rights to a file controlled by the FOCUS Database Server.

If the FOCUS Database Server was started with the ECHO or STAT parameter, status code 777 appears in HLIPRINT. HLI/SU users get status code 777 in word 24 of the File Communications Block when they issue an OPN command for a file for which they do not have access.

Rejected security requests are logged in the FOCUS Database Server job output stream. In addition, rejected SU security requests are logged on the operating system operator console, as with other attempted operating system security violations. Return and reason codes also appear in the error log allocated to ddname HLIERROR (or HLIPRINT if HLIERROR is not allocated), but for security purposes, they are not displayed at the user terminal.

If the Interface is activated by placing SET SUSI=ON in the SU profile, but the FOCUS Database Server is started by invoking HLISNK instead of HLISECUR, a 047 System ABEND occurs when the first user accesses the server.

If HLISECUR is invoked but the exit was not activated with the SET SUSI=ON command, no indication is given and the FOCUS Database Server provides no access checking.


Information Builders