| Oracle Procedural Gateway® for APPC Installation and Configuration Guide 10g Release 1 (10.1) for Microsoft Windows Part Number B13694-01 |
|
|
View PDF |
| Oracle Procedural Gateway® for APPC Installation and Configuration Guide 10g Release 1 (10.1) for Microsoft Windows Part Number B13694-01 |
|
|
View PDF |
The gateway architecture involves multiple systems, database servers, and communications facilities, each having distinct security capabilities and limitations. To effectively plan and implement your security scheme, you must understand these capabilities and limitations, in addition to knowing your installation's security requirements.
Read this chapter to learn about the capabilities and limitations of the Oracle Procedural Gateway for APPC. This chapter contains the following sections:
Before implementing your security scheme, you must understand the existing security requirements and expectations in your environment. Because you are enabling application access to different databases on different systems, you must merge multiple security cultures. When developing your security scheme, the most stringent security requirements prevail. When you connect several different systems into an operating whole, the system with the strictest security requirements generally dictates what the other systems can and cannot do.
Gateway security includes two main concerns:
users and applications that are permitted access to a particular gateway instance and OLTP
OLTP transactions that users and applications are able to execute
You can control access at several points in the gateway architecture. The primary options are discussed in the following sections. Control over remote transaction program access is provided by each OLTP with native authorization mechanisms based on user ID. These facilities are described in the product documentation for your OLTP. Information in this chapter includes how the gateway facilities determine the user ID that is in effect for a particular OLTP connection.
When the gateway is involved in an RPC request, security mechanisms are in effect for each system component encountered by the gateway. The first system component that is encountered is the application tool or 3GL program. The last system component that is encountered is the OLTP.
Each of the following sections identifies the component and the type of security processing that is available in that component. Each section offers a summary of key features and parameters. Refer to product-specific documentation for detailed information about the non-gateway components for Oracle and non-Oracle products.
An application must connect to an Oracle Integrating Server before using that gateway. The type of logon authentication that you use determines the resulting Oracle user ID and can affect gateway operation.
Two basic types of authentication are available:
With Oracle authentication, each Oracle user ID has an associated password that is known to Oracle. When an application connects to the server, it supplies a user ID and password. Oracle confirms that the user ID exists and that the password matches the one stored in the database.
For more information about authenticating application logons, refer to the Oracle Database Administrator's Guide.
The following sections discuss database links for users of the gateway employing either TCP/IP or SNA communications protocols.
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 can be used only by the user who created it. Database link usability is determined by its ability to open a session to the gateway. The Oracle Integrating Server makes no distinction as to 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 OLTP 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-specific options, the gateway might send that user ID and password to the OLTP to be validated.
If a database link is created without a CONNECT clause using Oracle authentication, then the user's Oracle user ID and password are sent to the gateway when the connection is opened. If the user logs on to the Oracle Integrating Server with operating system authentication, then the gateway receives no user ID or password from the Oracle Integrating Server. It is impossible for operating system-authenticated Oracle users to use a gateway database link defined without a CONNECT clause. However, if your OLTP provides user ID mapping facilities based on the gateway LU name from which the user is connecting, then such a connection is possible if all users on the same gateway instance can use the same OLTP user ID.
For more information about database links, refer to the Oracle Database Administrator's Guide.
The information in this section applies only to the security needs of gateway users employing the SNA communications protocol. When an RPC request to start a remote transaction program is received by the gateway, the gateway attempts to start an APPC conversation with the OLTP. Before the conversation can begin, a session must start between Windows' Logical Unit (LU) and the OLTP LU.
APPC support for your Windows platform is provided by the SNA Server (Microsoft Host Integration Server or IBM Communication Server v6.1.1 or higher).
SNA and its various access method implementations, including VTAM and the SNA Server, provide security validation at session initiation time, allowing each LU to authenticate its partner. This validation is carried out entirely by network software before the gateway and OLTP 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 Microsoft Windows' SNA profiles and in similar parameter structures in the OLTP to be accessed. Refer to the appropriate communications software product documentation for detailed information about this subject.
The PGA_SECURITY_TYPE parameter of the gateway initialization file allows you to specify either of three options that determine the security conduct of the LU6.2 conversation that is allocated with the OLTP. These options are part of the SNA LU6.2 architecture, but their precise behavior might vary depending on the particular OLTP system.
The security information in this section applies only to users of the Oracle Procedural Gateway for APPC using the TCP/IP for IMS Connect feature. When an RPC request to start a remote transaction program is received by the gateway, the gateway attempts to start the TCP/IP conversation with IMS Connect. IMS Connect would contact the OLTP (IMS) through OTMA and XCF. Refer to the IBM IMS Connect Guide and Reference for more information. The conversation between the gateway and IMS Connect occurs when the network uses the TCP/IP address or host name and port number to connect from the gateway to IMS Connect.
IMS Connect provides validation at session initiation time, allowing each connection to authenticate its partner. This validation is carried out entirely by network software before the gateway and OLTP application programs at IMS begin their conversation and process conversation-level security data. If session-level security is used, then correct password information must be established in Microsoft Windows and in similar parameter structures in the OLTP to be accessed.
The PGA_SECURITY_TYPE parameter of the gateway initialization file allows you to specify the security conduct for the conversation that is allocated by the gateway for OLTP. Refer to Appendix B, " Gateway Initialization Parameters for TCP/IP Communication Protocol ".
If you specify PGA_SECURITY_TYPE=NONE, then the gateway performs no processing of the client user ID and password.
If you specify PGA_SECURITY_TYPE=PROGRAM, then the following information is sent to the OLTP:
If the TIP user ID and password overrides are used, then the specified user ID and password are sent regardless of the database link specification.
If the database link has explicit CONNECT information, then the specified user ID and password are sent.
If the database link has no CONNECT clause, and if the application logged on to Oracle with an explicit user ID and password, then the Oracle user ID and password are sent.
If the application logs on to Oracle with operating system authentication, and if the database link lacks explicit CONNECT information, then no user ID and password are sent. If no user ID and password are sent, and if the OLTP is not configured to assign a default user ID, then the connection fails.
RACF is the only authentication mechanism available when the Oracle Procedural Gateway for APPC using TCP/IP for IMS Connect talks to IMS Connect.
The Oracle Procedural Gateway for APPC uses user IDs and passwords to access the information on the remote database on the gateway server.
For functions to be handled correctly, some user IDs and passwords must be defined in the gateway initialization file. (For an example, refer to the PGA_LOG_PASS parameter in Appendix A or PGA_TCP_PASS parameter in Appendix B.) Because it is not secure to have plain-text passwords accessible in the initialization file, a new encryption feature, pg4pwd, has been added to the gateway. With this feature, passwords are no longer stored in the initialization file but are stored instead in an encrypted form in the password file, making the information more secure. The pg4pwd utility is an optional feature, but Oracle strongly recommends that you use it. The following section describes how to use it.
This section applies to users of the gateway whether your communications protocol is TCP/IP or SNA. The pg4pwd utility encrypts passwords that are normally stored in the gateway initialization file. The pg4pwd utility searches the initialization file for parameters with an asterisk, *. The asterisk denotes that the parameter value is stored in encrypted form in another file. The following is a sample section of the initialization file with this value:
SET PRIVATE PGA_LOG_PASS=*
To use the pg4pwd utility:
Edit the initialization file to set the parameter value to *.
Run the pg4pwd utility, specifying the gateway SID on the command line. The utility reads the initialization file, and prompts you to enter the values to be encrypted.
The syntax of the command, where gateway_sid is the SID of the gateway, is:
C:\> pg4pwd gateway_sid
For example, if the gateway SID is "PGA", enter:
C:\> pg4pwd PGA ORACLE Gateway Password Utility (pg4appc) Constructing password file for Gateway SID PGA Enter the value for PGA_LOG_PASS pgaadmin
In the preceding example, the PGA_LOG_PASS parameter is identified as requiring encryption. The user enters the value, pgaadmin, and presses enter. If there are more parameters requiring encryption, they are prompted for in turn. The encrypted data is stored in the %ORACLE_HOME%\pg4appc\admin\initsid.pwd file.
|
Note: It is important that the ORACLE_HOME environment variable points to the gateway Oracle home directory to ensure that the correct gateway initialization file is read. |
