Security › How to Prevent Unauthorized Access in Applications › Design Transaction Security › Code Security Logic

Code Security Logic

In environments without a teleprocessing monitor, such as UNIX and Linux, application logic must be coded for transaction security. To build logic for transaction security, the first thing a server must do is validate a user's authorization.

There are two ways an application can validate transaction security:

• Automatic transaction security checking can be simulated by using CA Gen TIRSECR user exit.
  • The server manager automatically calls this exit, and it can be customized to verify that the user who is logged on can execute the transaction. Both the user ID and trancode are supplied as input to the exit.
  • After the TIRSECR exit completes, the server manager checks the return code exported.
  • A space in this code indicates the user has authority to execute the transaction.
  • A non-blank value indicates a security violation.
  • The exit also exports a message field, a COBOL (z/OS only) or C variable that contains the error message to be displayed to the user. If a security violation is detected by the server manager (a non-blank value in the return code field), CA Gen abnormal termination routines are invoked, and the message exported by the TIRSECR exit is displayed to the user.
  • The TIRSECR routine is automatically linked into every load module during installation.
  • The COBOL (z/OS only) or C code skeletons for the TIRSECR user exit routine are supplied with the implementation toolset. Any code can be placed in the exit routine to validate security. However, the code added to the skeletons must be written in COBOL (z/OS only) or C. Typically the code does the following:
  • A read of a file or database is done to determine if the user has access to the transaction.
  • If the user does not have authority the return code and message fields are set. These fields can be set to any value. A non-blank character in the return code causes the server manager to stop the execution of the transaction and display the exported message field to the user.
  • If the user does have authority to execute the transaction, the return code and message are blanked.
  • Calls to CA Gen-generated action blocks, such as the Security Template action block, can be placed within this exit. However, the calls to these action blocks must be written in COBOL (z/OS only) or C, not in CA Gen action diagram logic.
  • Modifications to the TIRSECR user exit can be made once. All transactions using the Implementation Toolset automatically link in the modified exit.
  • If you use the TIRSECR user exit is used, you do not have to build any action diagram logic for security. All transactions receive the security logic as part of the installation of the load module. As a result, transaction security is obtained in a way similar to using an external security package.
• Transaction security can also be accomplished by invoking a common or external action block within the procedure.
  • This action block call should be one of the first statements in the procedure.
  • The called/used action block first needs to import the user ID and transaction code. Then the logic should read a file or a database table to determine the transaction authority for the imported information:
  • If the user has the appropriate transaction authority, the action diagram returns an exit state or return code that allows further processing.
  • If a user does not have the appropriate transaction authority, the execution of the transaction is terminated, and a message is returned to the client procedure.

  This approach is similar to the way CA Gen Security Template implements security.

  By placing the transaction authorization check within the procedure, an application has control over what information is available to check authorization and what information is returned from the check. Using the TIRSECR user exit, the information imported and exported is fixed and cannot be changed. An example of some additional information that may be required is a password. If the information imported and exported by the TIRSECR user exit is not sufficient to meet the application's security requirements, then using a common or external action block may be necessary. The disadvantage of this approach is that transaction security is not automatic, and application logic must be coded in every procedure. This disadvantage makes maintenance of security logic costlier.

Note: For information about the TIRSECR exit, see the User Exit Reference Guide.