13 Security Considerations

13.1 Security Overview

When you connect several different systems, generally the system with the strictest security requirements dictates and rules the system.

Gateway security involves two groups:

• Users and applications that are permitted access to a given gateway instance and DRDA database server

• Server database objects that users and applications are able to query and update

You can control access in the gateway architecture at several points. Control over database object access is provided by each DRDA database server with GRANTs and related native authorization mechanisms based on user ID.

When the gateway is involved in a SQL request, security mechanisms are in effect for each DRDA system component encountered by the gateway. The first system component encountered is the application tool or 3GL program. The last system component encountered is the DRDA database.

13.2 Authenticating Application Logons

An application must connect to an Oracle integrating server before using the gateway. The type of logon authentication that you use determines the resulting Oracle user ID and can affect gateway operation. There are two basic types of authentication:

• Oracle authentication

  With Oracle authentication, each Oracle user ID has a password known to the Oracle server. When an application connects to the server, it supplies a user ID and password. The Oracle server confirms that the user ID exists and that the password matches the one kept in the database.

• Operating system authentication

  With operating system authentication, the server's underlying operating system is responsible for authentication. An Oracle user ID that is created with the IDENTIFIED EXTERNALLY attribute, instead of a password, is accessed with operating system authentication. To log into such a user ID, the application supplies a forward slash ( / ) for a user ID and does not supply a password.

  To perform operating system authentication, the server determines the requester's operating system user ID, optionally adds a fixed prefix to it, and uses the result as the Oracle user ID. The server confirms that the user ID exists and is IDENTIFIED EXTERNALLY, but no password checking is done. The underlying assumption is that users were authenticated when they logged into the operating system.

  Operating system authentication is not available on all platforms and is not available in some Oracle Net (client-server) and multi-threaded server configurations. Refer to the Oracle Database Installation Guide for Windows and Oracle Net documentation to determine the availability of this feature in Microsoft Windows.

For more information about authenticating application logons, refer to the Oracle Database Reference.

13.3 Defining and Controlling Database Links

The information here is specific to the gateway. For additional information on database links, refer to the Oracle Database Administrator's Guide.

13.4 TCP/IP Security

TCP/IP does not have any additional configurable security mechanism. The gateway supports a validation mechanism which requires a user ID and a valid password. The security information is passed to the DRDA Server for validation. This type of validation is equivalent to the "SNA Security Option SECURITY=PROGRAM" or "SNA Security Option SECURITY=PROGRAM", which is discussed in Chapter 6, " Configuring Microsoft SNA Server or Host Integration Server" and Chapter 7, " Configuring IBM Communication Server". The difference between the two methods is that in the SNA configuration, the security validation is performed by the SNA network facilities, while in the TCP/IP configuration, the DRDA Server manually performs the validation.

13.5 Processing Inbound Connections

Current DRDA Servers provide options for manipulating the security conduct of an inbound (client) DRDA session request. Refer to the appropriate IBM documentation for detailed information about the security options discussed in this section. Refer to the section, "Documentation Requirements", for a list of IBM documentation.

13.6 Passwords in the Gateway Initialization File

The gateway uses userids and passwords to access the information in the remote database on the DRDA Server. Some userids and passwords must be defined in the Gateway Initialization File to handle functions such as resource recovery. Refer to the parameters DRDA_RECOVERY_USERID and DRDA_RECOVERY_PASSWORD in Appendix C as examples. In today's security conscious environment, having plain-text passwords that are accessible in the Initialization File is deemed insecure. A new encryption feature has been added to the gateway to help make this more secure. The g4drpwd utility can be used to encrypt passwords that would normally be stored in the Initialization File. Using this feature is optional, but it is highly recommended by Oracle Corporation. With this feature, passwords are no longer stored in the Initialization File, but instead are stored in a password file in an encrypted form, thus making the information more secure. Read the next section to learn how to use this feature.

13.7 Using the g4drpwd Utility

The g4drpwd utility is used to encrypt passwords that would normally be stored in the Gateway Initialization File. The utility works by reading the Initialization File and looking for parameters with a special value. The specific value is the asterisk ("*"). This designates that the value of this parameter is stored in an encrypted form in another file. The following is a sample section of the Initialization File with this value ("*"):

# DRDA_RECOVERY_PASSWORD: Default: none, must be a valid MVS password.
# The recovery user connects to the IBM database if a distributed transaction
# is in doubt.
DRDA_RECOVERY_PASSWORD=*

The Initialization File is first edited to set the value of the parameter to "*". Then the g4drpwd utility is run, specifying the gateway SID on the command line. The utility will read the Initialization File and will prompt the user to enter the values that are to be encrypted.

The syntax of the command is: g4drpwd [gateway_sid]

Where [gateway_sid] is the SID of the gateway.

The following is an example run, assuming a gateway sid of DB2:

> g4drpwd DB2
ORACLE Gateway Password Utility (tg4drda)
Constructing password file for Gateway SID DB2
Enter the value for DRDA_RECOVERY_PASSWORD
ORADRDA

In the example above, the parameter "DRDA_RECOVERY_PASSWORD" is identified as requiring encryption. The user enters the value (in other words, "ORADRDA") and presses enter. If more parameters require encryption, then they will be prompted for in turn. The encrypted data is stored in the tg4drda\admin directory.