|
MSO can be used with or without an external security package such as RACF, CA-TOP SECRET, or CA-ACF2. If no security package is being used, all the users in a given MSO region inherit whatever security is in effect for the MSO job or started task. Thus, if the MSO job cannot access any file, neither can any MSO user; if the MSO job can access all files, so too can all the users under MSO. |
In this section: |
MSO supports user-level security via IBM's System Authorization Facility, or SAF. MSO issues a SAF macro that creates an ACEE control block for each user task as the user logs onto MSO. The userid of the user is inserted into this ACEE, and it is this userid that dictates which resources the FOCUS task can access. After this ACEE is created, whenever the user's FOCUS task attempts to access system resources (usually data sets), SAF issues a call to whatever security package is installed at the site.
The userid inserted into the ACEE is actually the security ID that results when the MSIDTR userid translation exit is called. A site can thus have different security IDs from logon userids using MSIDTR. If a site does not use MSIDTR, then the logon userid is used for the security ID as well.
For VTAM access into MSO, two security checks may be done: first, a check is made that the logon userid and password are authorized, and once this is done, the security ID (SECID) may be changed via MSIDTR mentioned above. This new SECID must then be checked again. The first check can be bypassed if a site chooses to implement the MSIDVER user exit. More information on the MSIDVER exit is available in MSO Features and Components.
In order for user-level security to work, the following must be true:
The FOCLIB.LOAD library must be APF authorized.
The external security package must be aware that SAF calls are being made and must correctly process them. Also, depending on the security package, the MSO address-space-level security must either have no access to any system resources, or must have full access to all resources. What this means is that the MSO job's security must not interfere with user-level security.
Every userid that accesses MSO must be defined to the security package.
MSO issues three distinct types of SAF calls:
VERIFY. The verify SAF call occurs when a user logs on from all the MSO terminal environments: CICS, TSO, and VTAM. A verify is done for the SECID and an ACEE is created. For VTAM access, the password is checked along with the userid.
APPL. When a VTAM user logs on, MSO issues a SAF call for the APPLID (LU2 applid) of MSO along with the SECID. If MSO receives a return code of 0 or 4, the user is permitted to log on.
For VTAM access, the password and userid are both checked, an APPL of "MSO" and the LU2 terminal are passed.
PROGRAM. When a VTAM MSO user logs on, MSO also issues a program SAF call, where the program name is FOCUS, for the SECID.
The following flow chart shows how these security calls are made for a FOCUS MSO user:
A TSO or CICS A VTAM user
Logon Userid |
| Is MSIDVER present? -------> yes
| no |
| | |
| Issue VERIFY call for Call
| userid and password MSIDVER
| | |
| |<-------------------+
| |
+------------------> <------------------------------+
|
Is MSIDTR present? ---------------> yes
no |
| Call
| MSIDTR
| |
|<-------------------------------+
|
Issue VERIFY call for SECID
(may not be needed for VTAM users)
Issue APPL call for applid for VTAM users
Issue PROGRAM call for VTAM users for FOCUS
| Information Builders |