Release 9.0.1.0.1 for Sun Solaris
Part Number A90399-01
 Library |
 Product |
 Contents |
 Index |
| Oracle Transparent Gateway for IBM DRDA Installation and User's Guide Release 9.0.1.0.1 for Sun Solaris Part Number A90399-01 |
|
The gateway architecture involves multiple computer systems that have distinct security capabilities and limitations. This chapter provides information for planning and implementing your security system.
This chapter provides information that is specific to this release of the Oracle Transparent Gateway for IBM DRDA for Sun Solaris. It includes the following sections:
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.
An application must connect to an integrating Oracle 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:
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.
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 Oracle9i Installation Guide for Sun SPARC Solaris 2.x and Oracle Net documentation for Sun Solaris to determine the availability of this feature in Solaris.
For more information about authenticating application logons, refer to the Oracle9i Administrator's Guide.
The information here is specific to the gateway. For additional information on database links, refer to the Oracle9i Administrator's Guide.
The first point of control for a database link is simply whether it is accessible to a given user. A public database link can be used by any user ID. A private database link is usable 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 which remote objects can be accessed. These distinctions are the responsibility of the DRDA database that is accessed.
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 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 it to validate.
If a database link is created without a CONNECT clause, then the user's Oracle user ID and password are sent to the gateway when the connection is opened. If the user logs into the integrating Oracle Server with operating system authentication, then the gateway receives no user ID or password from the integrating Oracle Server. 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 Sun host can use the same DRDA database user ID.
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". See the discussion of this option below. 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.
When the database link request for the gateway begins, the gateway attempts to start an APPC conversation with the DRDA server. Before the conversation can begin, a session must start between the Sun host Logical Unit (LU) and the DRDA server LU.
SNA and its various access method implementations (including SunLink SNA Peer-to-Peer and VTAM) provide security validation at session initiation time, allowing each LU to authenticate its partner. This is carried out entirely by network software before the gateway and server application programs begin their conversation and process conversation-level security data. If session-level security is used, then correct password information must be established in the Sun host Connection Profile and in similar parameter structures in the DRDA server system that is to be accessed. Refer to the appropriate SunLink SNA Peer-to-Peer product documentation for detailed information.
SNA conversation security is determined by the setting of the gateway initialization parameter, DRDA_SECURITY_TYPE. This parameter determines whether SNA security option SECURITY is set to PROGRAM or to SAME. Generally, the gateway operates under SNA option SECURITY=PROGRAM, but it can also be set to operate under SNA option SECURITY=SAME.
If DRDA_SECURITY_TYPE=PROGRAM is specified, then the gateway allocates the conversation with SNA option SECURITY=PROGRAM and sends this information to the user ID:
In general, SECURITY=PROGRAM tells the DRDA server to authenticate the user ID/password combination using whatever authentication mechanisms are available. For example, if DB2/MVS is the DRDA server, then RACF can be used. This is not always the case, however, because each of the IBM DRDA servers can be configured to process inbound user IDs in other ways.
If DRDA_SECURITY_TYPE=SAME is specified, then the gateway allocates the conversation with SNA option SECURITY=SAME, and the following information is sent to the DRDA server:
For this option to function properly, SunLink SNA Peer-to-Peer requires that the effective user ID under which the gateway is executing must be a member of the system group. In Solaris terms, this means that the user ID must be defined with its primary group set to system. In addition, the owning user ID of the gateway driver executable must be set to the desired effective user ID, and the set-uid bit of the e executable file permissions must also be set. The ls -l command shows the owning user ID and the setting of the set-uid bit for the executable file. The owning user ID can be changed by the root user with the chown command, and the set-uid bit can be set using the chmod u+s command. The gateway driver executable, as installed by the Oracle Universal Installer, has its set-uid bit enabled.
The simplest way to cause the gateway to execute under an effective user ID that is a member of the system group is to change the owning user ID of the gateway driver executable to root. Another way is to change the primary group for the owning user ID of the gateway driver executable to system. However, be careful when choosing the user ID. Oracle Corporation recommends using root and recommends never changing the Oracle dba user ID primary group to system.
When the effective user ID is not a member of the system group, a failure is generated when the gateway attempts to allocate a conversation with the DRDA server, and an error message is sent to the gateway user.
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 "Documentation Requirements", for a list of IBM documentation.
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 installation does not have a uniform user ID structure across all systems and databases.
The DB2 DDF Communication Database (CDB) stores inbound DRDA session security options.
These tables, pertinent to inbound sessions, have a role in security processing:
The SYSIBM.SYSLUNAMES table controls inbound security conduct on an SNA LU basis, affecting all DRDA connections from a particular Sun host system. This table also controls whether inbound connection user IDs are subject to translation or mapping.
When translation is used, rows in the SYSIBM.SYSUSERNAMES table specify translated user IDs by LU name and inbound user ID. Default entries that pertain to all LUs 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 LU or from all LUs, whether or not they are mapped.
This implementation provides a flexible mapping structure. You can specify that all connections from a particular LU 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 LU name and inbound user ID can designate a single default DB2 user ID for all connections unless a more specific entry, by LU name, user ID, or both, exists.
The CDB tables can be updated by a user with update authority 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. Once the connection is established, all normal authorizations or GRANTs associated with the user ID are in effect. The user ID must have execute authority on the gateway DRDA package to process any SQL statements.
Under VM, DRDA sessions are managed by APPC VTAM Support (AVS), which runs as a disconnected GCS virtual machine. AVS retrieves incoming APPC connection requests (both DRDA and non-DRDA) and routes the connection to an appropriate server virtual machine.
AVS user ID mapping is controlled by internal AVS data structures that are updated with the AGW ADD USERID and AGW DELETE USERID commands.
A user ID mapping entry converts the inbound user ID before making the DB2/VM connection. The user ID mapping consists of:
You can create default entries that apply to any LU name and to any inbound user ID, and an entry can indicate that the inbound user ID is to be used without mapping.
AVS user ID mapping is functionally similar to the DB2 user ID translation mechanism and can be used to work around a variety of incongruities among user ids on different systems and databases.
Once any indicated user ID mapping has been done, inbound DRDA connection requests are forwarded to the specified DB2/VM server machine. DB2/VM confirms only that the user ID has CONNECT authority and, if so, that the connection is complete. At this point, the application's access to DB2/VM objects is controlled by the normal authorities and GRANTs for the connected user ID. The user ID must have execute authority on the gateway DRDA package to process any SQL statements.
DB2/400 does not provide a user ID mapping capability comparable to that in DB2/MVS and DB2/VM. Normally, the user ID in an incoming DRDA connection request must be a valid user ID on that AS/400.
The AS/400 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.
Once the application has completed the DRDA connection to the AS/400, 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.
DB2/Universal Database (DB2/UDB) does not provide a user ID mapping capability comparable to that in DB2/MVS and DB2/VM. Normally, the user ID in an incoming DRDA connection request must be a valid user ID on the DB2/UDB host.
Once 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.
|
 Copyright © 2001 Oracle Corporation. All Rights Reserved. |
|