Skip Headers
Oracle® Database Gateway Installation and Configuration Guide
11g Release 2 (11.2) for AIX 5L Based Systems (64-Bit), HP-UX Itanium, Solaris Operating System (SPARC 64-Bit), Linux x86, and Linux x86-64

Part Number E12013-01
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

15 Security Considerations

The gateway architecture involves multiple computer setups that have distinct security capabilities and limitations. This chapter provides information for planning and implementing your security system.

It contains the following sections:

15.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:

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.

15.2 Authenticating Application Logons

An application must connect to an Oracle database 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:

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

15.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 Reference.

15.3.1 Link Accessibility

The database link should be accessible to a given user. A public database link can be used by any user ID. A private database link can be used only by the user who created it. The server makes no distinction regarding the type of use (such as read-only versus update or write) or accessibility of remote objects. The DRDA database, which is accessed, is responsible for these distinctions.

15.3.2 Links and CONNECT Clauses

The CONNECT clause is another security-related attribute of a database link. You can use the CONNECT clause to specify an explicit user ID and password, which can differ from the user's Oracle database user ID and password. This CONNECT user ID and password combination is sent to the gateway when the database link connection is first opened. Depending on gateway options, the gateway might send that user ID and password to the DRDA Server for validation.

If a database link is created without a CONNECT clause, then the user's Oracle database user ID and password are sent to the gateway when the connection is opened. If the user logs into the Oracle database with operating system authentication, then the gateway does not receive any user ID or password from the Oracle database. In this case, user ID mapping facilities at the DRDA Server can be used to make such a connection possible if all users on the same host can use the same DRDA database user ID.

15.4 Processing Inbound Connections

Current DRDA Servers provide options for manipulating the security conduct of an inbound (client) DRDA session request.

15.4.1 User ID Mapping

The most useful DRDA Server security capability is user ID mapping. User ID mapping refers to changing the user ID associated with an incoming DRDA request to some other user ID known to that server. This is a useful feature if your Oracle Database Gateway installation does not have a uniform user ID structure across all systems and databases.

15.4.1.1 DB2 UDB for z/OS

The DB2 DDF Communication Database (CDB) stores inbound DRDA session security options.

These tables, pertinent to inbound sessions, have a role in security processing:

  • SYSIBM.IPNAMES table

    The SYSIBM.IPNAMES table controls inbound security conducted for TCP/IP based sessions, affecting all DRDA connections from a particular host system. This table also controls whether inbound connection user IDs are subject to translation or mapping.

  • SYSIBM.SYSUSERNAMES table

    When translation is used, rows in the SYSIBM.SYSUSERNAMES table specify translated user IDs by IP name and inbound user ID. Default entries that pertain to all IPs and to all inbound user IDs can be made in both tables. The mapping table can also be used simply to indicate which inbound user IDs are permitted from a particular IP or from all IPs, whether or not they are mapped.

This implementation provides a flexible mapping structure. You can specify that all connections from a particular IP use a single DB2 user ID, or that a particular inbound user ID always be mapped to a particular DB2 user ID regardless of origin. A SYSUSERNAMES entry with blank IP name and inbound user ID can designate a single default DB2 user ID for all connections unless a more specific entry, by IP name, user ID, or both, exists.

The CDB tables can be updated by a user with update privilege using a SQL tool such as the DB2 SPUFI utility. For example, most database administrators, systems programmers, and security officers can update CDB tables. The DB2 DDF component must be stopped and restarted for CDB changes to take effect.

The DB2 non-DRDA-specific security features are also involved in DRDA connections. User IDs are subject to normal DB2 or SAF/RACF validation in addition to connection or sign-on exit processing. Passwords are also subject to validation. After the connection is established, all normal authorizations or GRANTs associated with the user ID are in effect. The user ID must have execute privilege on the gateway DRDA package to process any SQL statements.

15.4.1.2 DB2 UDB for iSeries

DB2 UDB for iSeries does not provide a user ID mapping capability comparable to that in DB2 UDB for z/OS. Normally, the user ID in an incoming DRDA connection request must be a valid user ID on that DB2 UDB for iSeries.

The DB2 UDB for iSeries subsystem communications entry for the gateway should specify that the gateway is not a secure location and should include a default user ID of *NONE.

After the application has completed the DRDA connection to the DB2 UDB for iSeries, it is subject to all authorities and GRANTs associated with the user ID in use.

The user ID must have execute authority on the gateway DRDA package to execute any SQL statements.

15.4.1.3 DB2 UDB for Linux, Unix, and Windows

DB2 UDB for Linux, Unix, and Windows does not provide a user ID mapping capability comparable to that in DB2 UDB for z/OS. Normally, the user ID in an incoming DRDA connection request must be a valid user ID on the DB2 UDB for Linux, Unix, and Windows host.

After the application has completed the DRDA connection to the DB2 host, it is subject to all authorities and GRANTs associated with the user ID in use. The user ID must have execute authority on the gateway DRDA package to execute any SQL statements.

15.5 Passwords in the Gateway Initialization File

The gateway uses user IDs and passwords to access the information in the remote database on the DRDA Server. Some user IDs and passwords must be defined in the gateway initialization file to handle functions such as resource recovery. In the current security conscious environment, having plainEtext passwords that are accessible in the Initialization File is deemed insecure. An encryption feature has been added as part of Heterogeneous Services' generic connectivity to help make this more secure. This feature is accessible by this gateway. With it Initialization parameters which contain sensitive values might be stored in an encrypted form. Refer to Section 4.2.3, 'Encrypting Initialization parameters' in the Oracle Database Heterogeneous Connectivity User's Guide for more information about how to use the feature.

See Also:

the parameters HS_FDS_RECOVERY_ACCOUNT and HS_FDS_RECOVERY_PWD in Appendix C as examples, for more information.