The application server support in DB2 for MVS/ESA allows DB2 for MVS/ESA to act as a server for DRDA application requesters. The Application Requester connected to a DB2 for MVS/ESA Application Server can be:
For any Application Requester connected to a DB2 for MVS/ESA Application Server, the DB2 for MVS/ESA Application Server supports database access as follows:
For the DB2 for MVS/ESA Application Server to properly process distributed database requests, you must take the following steps:
For the Application Server to receive distributed database requests, it must be defined to the local Communications Manager and have a unique RDB_NAME. You must take the following steps to properly define the Application Server:
See Setting RU Sizes and Pacing about how to review your VTAM network.
For example, you can allow the DALLAS system (another DB2 for MVS/ESA system) to send already-verified distributed database requests (LU 6.2 SECURITY=SAME), while requiring database manager systems to send passwords. Furthermore, you might not want to record an entry in the CDB for each database manager system, especially if there is a large number of these systems. Figure 10 shows how the CDB can be used to specify SECURITY=SAME for the DALLAS system, while enforcing SECURITY=PGM for all other requesters.
Figure 10. Establishing Defaults for Application Requester Connections
INSERT INTO SYSIBM.SYSLUNAMES
(LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS, MODESELECT, USERNAMES)
VALUES ('LUDALLAS', ' ', 'A', 'N', 'N', ' ');
INSERT INTO SYSIBM.SYSLUNAMES
(LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS, MODESELECT, USERNAMES)
VALUES (' ', ' ', 'C', 'N', 'N', ' ');
|
In Figure 11, no row contains blanks in the LUNAME column, so DB2 for MVS/ESA denies access to any LU other than LUDALLAS or LUNYC.
Figure 11. Identifying Individual Application Requester Connections
INSERT INTO SYSIBM.SYSLUNAMES
(LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS, MODESELECT, USERNAMES)
VALUES ('LUDALLAS', ' ', 'A', 'N', 'N', ' ');
INSERT INTO SYSIBM.SYSLUNAMES
(LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS, MODESELECT, USERNAMES)
VALUES ('LUNYC', ' ', 'A', 'N', 'N', ' ');
|
DB2 for MVS/ESA does not implement a database server as defined in DRDA. Instead, DB2 for MVS/ESA provides secondary servers that provide access to multiple DB2 for MVS/ESA systems in a single unit of work using system-directed access.
SQL differences: The SQL supported by system-directed access differs significantly from DRDA remote unit of work:
SELECT * FROM CHICAGO.USER.TABLE;
SQL object names: When the DB2 for MVS/ESA Application Server receives an SQL request, it examines the SQL object name to determine where the object resides in the network. DB2 for MVS/ESA accepts either one-, two-, or three-part SQL object names, where the name takes one of the following forms:
objectname specifies the name of a DB2 for MVS/ESA table, view, synonym, or alias.
authid.objectname specifies the owner of the object and the object name.
location.authid.objectname specifies the owning system, the owning user, and the name of the object.
If the location name (the first part of the three-part object name) matches the local DB2 for MVS/ESA system's RDB_NAME, the request identifies a local DB2 for MVS/ESA object.
If the location name does not match the local DB2 for MVS/ESA system's RDB_NAME, the DB2 for MVS/ESA Application Server reroutes the request to the system identified by the location name using system-directed access. The target system must be another DB2 for MVS/ESA system, because system-directed access is only supported between DB2 for MVS/ESA systems. System-directed access does not support any remote bind functions, so the application does not have to be bound at the server before executing the application. Figure 12 summarizes the process used by DB2 for MVS/ESA to resolve SQL object names.
Figure 12. DB2 for MVS/ESA SQL Object Name Resolution
|
Server definition: If the DB2 for MVS/ESA Application Server is to reroute SQL requests, you must define each secondary server in the CDB and VTAM. Most of the definition process is similar to the process described in Defining the Remote Systems. To connect secondary servers, do the following:
As the owner of the database resources, the secondary server controls database security for SQL objects residing at the server. However, this responsibility is shared with the DB2 for MVS/ESA Application Server making the request. The server controls access to SQL objects as follows:
When an Application Requester routes a distributed database request to the DB2 for MVS/ESA Application Server, the following security considerations can be involved:
When the DB2 for MVS/ESA Application Server receives an end user name from the Application Requester, the Application Server can restrict the end user names received from a given Application Requester. This is accomplished through the use of come-from checking. Come-from checking allows the Application Server to specify that a given user ID is only allowed to be used by particular partners. For example, the Application Server can restrict JONES to "come from" DALLAS. If another Application Requester (other than DALLAS) attempts to send the name JONES to the Application Server, the Application Server can reject the request because the name did not come from the correct network location.
DB2 for MVS/ESA implements come-from checking as part of inbound end user name translation, which is described in the next section.
The user ID passed by the Application Requester might not be unique throughout the entire SNA network. The DB2 for MVS/ESA Application Server might need to perform inbound name translation to create unique end user names throughout the SNA network. Similarly, the DB2 for MVS/ESA Application Server might need to perform outbound name translation to provide a unique end user name to the secondary servers involved in the application (see Provide Security for information concerning outbound end user name translation).
Inbound name translation is enabled by setting the USERNAMES column of the SYSIBM.SYSLUNAMES table to 'I' (inbound translation) or 'B' (both inbound and outbound translation). When inbound name translation is in effect, DB2 for MVS/ESA translates the user ID sent by the Application Requester and the DB2 for MVS/ESA plan owner's name (if the Application Requester is another DB2 for MVS/ESA system).
If the Application Requester sends both a user ID and a password on the APPC ALLOCATE verb, the user ID and password are validated before the user ID is translated. The PASSWORD column in SYSIBM.SYSUSERNAMES is not used for password validation. Instead, the user ID and password are presented to the external security system (RACF or a RACF-equivalent product) for validation.
When the incoming user ID on the ALLOCATE verb is verified, DB2 for MVS/ESA has authorization exits you can use to provide a list of secondary AUTHIDs and perform additional security checks. See the DB2 Administration Guide, for details.
The inbound name translation process searches for a row in the SYSIBM.SYSUSERNAMES table, which must fit one of the patterns shown in the following precedence list (TYPE.AUTHID.LUNAME):
If no row is found, remote access is denied. If a row is found, remote access is allowed and the end user's name is changed to the value provided in the NEWAUTHID column, with a blank NEWAUTHID value indicating that the name is unchanged. Any DB2 for MVS/ESA resource authorization checks (for example, SQL table privileges) made by DB2 for MVS/ESA are performed on the translated end user names, rather than on the original user names.
When the DB2 for MVS/ESA Application Server receives an end user name from the Application Requester, several objectives can be accomplished by using the DB2 for MVS/ESA inbound name translation capability:
INSERT INTO SYSIBM.SYSLUNAMES
(LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS,
MODESELECT, USERNAMES)
VALUES ('LUNYC', ' ', 'A', 'N', 'N', 'I');
INSERT INTO SYSIBM.SYSUSERNAMES
(TYPE, AUTHID, LUNAME, NEWAUTHID, PASSWORD)
VALUES ('I', 'JONES', 'LUNYC', 'NYJONES', ' ');
INSERT INTO SYSIBM.SYSLUNAMES
(LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS,
MODESELECT, USERNAMES)
VALUES ('LUNYC', ' ', 'A', 'N', 'N', 'I');
INSERT INTO SYSIBM.SYSUSERNAMES
(TYPE, AUTHID, LUNAME, NEWAUTHID, PASSWORD)
VALUES ('I', ' ', 'LUNYC', 'NYUSER', ' ');
INSERT INTO SYSIBM.SYSLUNAMES
(LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS,
MODESELECT, USERNAMES)
VALUES ('LUNYC', ' ', 'A', 'N', 'N', 'I');
INSERT INTO SYSIBM.SYSUSERNAMES
(TYPE, AUTHID, LUNAME, NEWAUTHID, PASSWORD)
VALUES ('I', 'SMITH', 'LUNYC', ' ', ' ');
INSERT INTO SYSIBM.SYSUSERNAMES
(TYPE, AUTHID, LUNAME, NEWAUTHID, PASSWORD)
VALUES ('I', 'JONES', 'LUNYC', ' ', ' ');
INSERT INTO SYSIBM.SYSLUNAMES
(LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS,
MODESELECT, USERNAMES)
VALUES (' ', ' ', 'A', 'N', 'N', 'I');
INSERT INTO SYSIBM.SYSUSERNAMES
(TYPE, AUTHID, LUNAME, NEWAUTHID, PASSWORD)
VALUES ('I', ' ', 'LUNYC', ' ', ' ');
INSERT INTO SYSIBM.SYSUSERNAMES
(TYPE, AUTHID, LUNAME, NEWAUTHID, PASSWORD)
VALUES ('I', ' ', 'LUCHI', ' ', ' ');
LU 6.2 provides three major network security features:
Network Security discusses how to specify session-level security and encryption with DB2 for MVS/ESA. The DB2 for MVS/ESA Application Server uses session-level security and encryption in exactly the same manner as the DB2 for MVS/ESA Application Requester.
The only remaining network security consideration is SNA conversation-level security. Some aspects of conversation-level security are unique for a DB2 for MVS/ESA Application Server. The DB2 for MVS/ESA Application Server plays two distinct roles in network security:
If a security violation is discovered, LU 6.2 requires the DB2 for MVS/ESA Application Server to return the SNA security failure sense code ('080F6051'X) to the Application Requester. Because this sense code does not describe the cause of the failure, DB2 for MVS/ESA provides two methods for recording the cause of distributed security violations:
As the owner of database resources, the DB2 for MVS/ESA Application Server controls the database security functions for SQL objects residing at the DB2 for MVS/ESA Application Server. Access to DB2 for MVS/ESA-managed objects is controlled by privileges, which are granted to users by the DB2 for MVS/ESA administrator or the owners of individual objects. The two basic classes of objects that the DB2 for MVS/ESA Application Server controls are:
When an application is bound to DB2 for MVS/ESA, the package contains the SQL statements contained in the application program. These SQL statements are classified as:
When end users are granted authority to execute a package, they automatically have authority to execute each of the static SQL statements contained in the package. Thus, end users do not need any DB2 for MVS/ESA table privileges if the package they execute contains only static SQL statements.
When you create a package, the DISABLE/ENABLE option allows you to control which DB2 for MVS/ESA connection types can run the package. You can use RACF and DB2 for MVS/ESA security exit routines to selectively allow end users to use DDF. You can use RLF to specify limits on processor time for remote binds and dynamic SQL executions.
Consider a DB2 for MVS/ESA package named MYPKG, which is owned by JOE. JOE can allow SAL to execute the package by issuing the DB2 for MVS/ESA GRANT USE statement. When SAL executes the package, the following occurs:
The DB2 for MVS/ESA Application Server use of the security subsystem (RACF or a RACF-equivalent product) is dependent on how you define the inbound name translation function in the SYSIBM.SYSLUNAMES table:
If the request from the Application Requester contains only a user ID (SECURITY=SAME), the external security system is not called at all, because the inbound name translation rules define which users are allowed to connect to the DB2 for MVS/ESA Application Server.
You must ensure that your DB2 for MVS/ESA subsystem has the ability to convert from each application requester's CCSID to your DB2 for MVS/ESA subsystem's installation CCSID. Refer to Represent Data for more information.