Identifying online security requirements

Security in an online system means protecting the data from unauthorized use through terminals. It also means preventing unauthorized use of both the IMS system and the application programs that access the database. For example, you do not want a program that processes paychecks to be available to everyone who can access the system.

The security mechanisms that IMS provides are signon, terminal, and password security.

Related reading: For an explanation of how to establish these types of security, see IMS Version 15.3 System Administration.

Limiting access to specific individuals: signon security

Signon security is available through Resource Access Control Facility (RACF®) or a user-written security exit routine. With signon security, individuals who want to use IMS must be defined to RACF or its equivalent before they are allowed access.

When a person signs on to IMS, RACF or security exits verify that the person is authorized to use IMS before access to IMS-controlled resources is allowed. This signon security is provided by the /SIGN ON command. You can also limit the transaction codes and commands that individuals are allowed to enter. You do this by associating an individual's user identification (USERID) with the transaction codes and commands.

LU 6.2 transactions contain the USERID.

Related reading: For more information on security, see IMS Version 15.3 Communications and Connections.

Limiting access for specific terminals: terminal security

Use terminal security to limit the entry of a transaction code to a particular terminal or group of terminals in the system. How you do this depends on how many programs you want to protect.

To protect a particular program, you can either authorize a transaction code to be entered from a list of logical terminals, or you can associate each logical terminal with a list of the transaction codes that a user can enter from that logical terminal. For example, you could protect the paycheck application program by defining the transaction code associated with it as valid only when entered from the terminals in the payroll department. If you wanted to restrict access to this application even more, you could associate the paycheck transaction code with only one logical terminal. To enter that transaction code, a user needs to be at a physical terminal that is associated with that logical terminal.

Restriction: If you are using the shared-queues option, static control blocks representing the resources needed for the security check need to be available in the IMS system where the security check is being made. Otherwise, the security check is bypassed.

Related reading: For more information on shared queues, see IMS Version 15.3 System Administration.

Limiting access to the program: password security

Another way you can protect the application program is to require a password when a person enters the transaction code that is associated with the application program you want to protect. If you use only password security, the person entering a particular transaction code must also enter the password of the transaction before IMS processes the transaction.

If you use password security with terminal security, you can restrict access to the program even more. In the paycheck example, using password security and terminal security means that you can restrict unauthorized individuals within the payroll department from executing the program.

Restriction: Password security for transactions is only supported if the transactions that are needed for the security check are defined in the IMS system where the security check is being made. Otherwise, the security check is bypassed.

Allowing access to security data: authorization security

RACF has a data set that you can use to store user-unique information. The AUTH call gives application programs access to the RACF data set security data, and a way to control access to application-defined resources. Thus, application programs can obtain the security information about a particular user.

How IMS security relates to Db2 for z/OS security

An important part of Db2 for z/OS® security is the authorization ID. The authorization ID that IMS uses for a program or a user at a terminal depends on the kind of security that is used and the kind of program that is running.

For MPPs, IFPs, and transaction-oriented BMPs, the authorization ID depends on the type of IMS security:

  • If signon is required, IMS passes the USERID and group name that are signed-on to Db2 for z/OS.
  • If signon is not required, Db2 for z/OS uses the name of the originating logical terminal as the authorization ID.

For batch-oriented BMPs, the authorization ID is dependent on the value specified for the BMPUSID= keyword in the DFSDCxxx PROCLIB member:

  • If BMPUSID=USERID is specified, the value from the USER= keyword on the JOB statement is used.
  • If USER= is not specified on the JOB statement, the program's PSB name is used.
  • If BMPUSID=PSBNAME is specified, or if BMPUSID= is not specified at all, the program's PSB name is used. If PSBNAME is not defined to RACF, the Userid of the current Address Space will be used; this will be the Home Dependent Region one, or the Control Region one if LSO=Y or if PARDLI=1 has been specified for the BMP. Userid of the current Address Space will be used also if DFSBSEX0 has returned RC08.

Supplying security information

When you evaluate your application in terms of its security requirements, you need to look at each program individually. When you have done this, you can supply the following information to your security personnel.

  • For programs that require signon security:
    • List the individuals who should be able to access IMS.
  • For programs that require terminal security:
    • List the transaction codes that must be secured.
    • List the terminals that should be allowed to enter each of these transaction codes. If the terminals you are listing are already installed and being used, identify the terminals by their logical terminal names. If not, identify them by the department that will use them (for example, the accounting department).
  • For programs that require password security:
    • List the transaction codes that require passwords.
  • For commands that require security:
    • List the commands that require signon or password security.