This section discusses the following topics:
Session-level security is controlled by the security acceptance (SECACPT) and VERIFY parameters, which are used when an LU is defined in the VTAM product. The type of session-level security that is specified determines the type of conversation-level security that is supported. If SECACPT is set to CONV, only PGM can be specified at the conversation level; if it is set to ALREADYV, both PGM and SAME can be specified. In addition, partner LU verification can be specified when conversation-level security is SAME (that is, SECACPT=ALREADYV).
| Note: | You cannot specify SECACPT=ALREADYV if you are using VTAM Version 3 Release 2. |
Partner LU verification is recommended for connections that the VTAM product routes through an AVS gateway and that specify SECURITY=SAME. These connections do not provide a user ID and password to be validated at the target site. (When partner LU verification occurs, the identity of each SNA LU is confirmed.) For more information on partner LU verification, see the Distributed Relational Database Connectivity Guide, and the VTAM Resource Definition Reference manuals.
Notes:
Conversation-level security can be specified by both DB2 Server for VM and non-DB2 Server for VM users connecting to a DB2 Server for VM application server. Non-DB2 Server for VM users are remote users by definition, and are routed to the server by the VTAM product through an AVS gateway. The DB2 Server for VM users, on the other hand, can access a DB2 Server for VM application server on the local system, and through an AVS gateway or TSAF collection. In all situations, the user can specify the level of conversation security. The type of conversation-level security that is supported depends on the session-level security that is specified for the underlying system. The DB2 Server for VM application server accepts a conversation-level security of either SAME or PGM, and either rejects or accepts the connection on that basis. The default used by the DB2 Server for VM application requester for the user is SAME.
Connections that specify SECURITY=SAME do not provide any security identification. Only a user ID is provided, which is validated by the source host by using CP, RACF, or an equivalent security manager product. Because the user ID is validated by the source host, it is considered to be already verified by the target host. The user ID that is sent is always the VM user ID. The value that is specified for the :userid tag in the CMS communications directory is not used for SECURITY=SAME connections. No password is sent.
The AGW ADD USERID command must be issued at the target AVS machine to authorize inbound SECURITY=SAME connections. If this command is not issued, these connections are rejected; if it has been used to map an inbound user ID at the target AVS machine, the target host does not validate that user ID. The connection is accepted, whether or not the mapped user ID exists on the target host. If the command
AGW ADD USERID remotelu * =
is issued, then the AVS machine will accept all already verified user IDs coming from remotelu. However, the command
AGW DELETE USERID remotelu remuser
cannot be used to delete remuser from the AVS user ID table because the table does not contain an entry for the remotelu/remuser pair. Instead, use
AGW DELETE USERID remotelu *
to delete all mappings corresponding to the remote LU remotelu.
| Note: | More than one user will be affected when AGW DELETE USERID remotelu * is issued. |
If the command AGW ADD USERID remotelu= is issued, then the command AGW DELETE USERID remotelu userid is issued, userid is not deleted from the AVS user ID table. The AVS machine will accept all user IDs coming from remotelu, including userid. To undo the AGW ADD USERID command, issue the AGW DELETE USERID command.
If the VTAM product is routing a connection through an AVS gateway, the AVS translation feature must be used to map an inbound user ID to a user ID that is locally defined. The mapped user ID is validated by the installed security manager product such as RACF or CP. A mapping is enabled and disabled with the AGW ADD USERID and AGW DELETE USERID commands.
| Note: | The AVS translation feature requires VTAM Version 3 Release 3 or later. You can only use this feature when SECURITY=SAME. |
Connections that are specified as SECURITY=PGM provide a user ID and a password to be validated by the installed security manager product (for example, CP, RACF, or an equivalent product). If the validation is successful, the connection is accepted; otherwise, it is rejected.
For more information about conversation-level security, see the Distributed Relational Database Connectivity Guide, and the VM/ESA: Connectivity Planning, Administration, and Operation manuals.
| Note: | Conversation-level security is supported by APPC/VM but not by IUCV. |
The VM operating system provides control statements that can be added to the directory entry of any virtual machine, both to enable functions and to restrict access on a particular processor.
Access to the database can be controlled by controlling access to the application server that manages it. Communications between an application requester and an application server can be enabled selectively with VM control statements that are added to the directory entries of one or both of the virtual machines. (The application server virtual machine is also referred to as the database machine.)
You can use either the user machine or the database machine to control access authority. If you want to allow all virtual machines on the same processor to connect to the application server, add the IUCV ALLOW control statement to the database machine directory entry. If you want to limit access to a particular application server to a small group of users, add the IUCV resid control statement to the directory entry of each user machine requiring access, and leave out the IUCV ALLOW control statement in the database machine directory entry.
In the VM/ESA operating systems, you can use the control statements IUCV ALLOW, IUCV ANY, and IUCV *IDENT to control the access that application requesters have to application servers.
When this statement is added to the directory entry of the database machine, all application requesters and communications servers (such as TSAF and AVS) on the same processor can connect to the application server.
When this statement is added to the directory entry of a virtual machine, the application requester can connect to all application servers and communications servers (such as TSAF and AVS) that are on the same processor. To limit access to specific users, use this statement in each user machine requiring access, instead of specifying IUCV ALLOW in the database machine.
You can further limit access to specific application servers by adding one or more IUCV resid statements to the directory entry.
Attention: If the VSE guest user machine directory entry contains the IUCV ANY statement, then anyone who knows the CIRB transaction password has database administrator (DBA) authority on all application servers.
All databases are identified as VM resources with either a local or global scope. A local resource can be accessed only by an application requester residing on the same processor. A global resource can be accessed by an application requester that is either local or remote.
The virtual machine where the application server resides (the database machine) uses the IUCV *IDENT control statement to identify which resources it manages, and whether the resources are local or global. For example, the statement IUCV *IDENT SALESDB GLOBAL identifies a global resource (database) named SALESDB, whereas the statement IUCV *IDENT SALESDB LOCAL identifies the same database as a local resource.
The database manager takes full advantage of the TSAF and AVS communications servers to make the application server accessible to both local and remote users. The latter can be either DB2 Server for VM or non-DB2 Server for VM users.
Neither AVS nor TSAF depends on the selected protocol (either SQLDS or DRDA), nor does the selected protocol depend on either AVS or TSAF. The contents of the data streams that the communications servers facilitate are independent of both TSAF and AVS.
If you want to use TSAF and AVS to route communications, you must do the required setup tasks, including the addition of the VM directory control statements, described above. In addition, you must define your database as a global resource if you intend to support distributed processing.
For more information about VM directory control statements, see the VM/ESA: Connectivity Planning, Administration, and Operation manual.
In a distributed environment, the role of the system administrator in authorizing and activating new user IDs, resource identifiers, and AVS gateway names is very important. You must enforce the following rules as strictly as possible:
| Note: | Resource identifiers and AVS gateway names must not be the same as a user ID (other than that of the resource manager), and they must not be specified as ALLOW, ANY, or SYSTEM. Also, an AVS gateway name must not be the same as any resource identifier. |
For more information on VM directory control statements and on setting up TSAF and AVS virtual machines, the see VM/ESA: Connectivity Planning, Administration, and Operation manual.
Each VM user ID is unique on a processor. However, in an environment of SNA networks and TSAF collections, in which many processors can be interconnected and user IDs are passed around for validation, the issues of duplication and ambiguity must be considered.
The application server cannot identify whether a user ID forwarded by the application requester belongs to a local or a remote user. For example, suppose that user ID STEVE is on a remote system that can access the application server through the AVS gateway; and that the same user ID exists locally and has a high level of authority. The application server cannot differentiate between the local and the remote users and treats them equally. This situation poses a risk to security, and must be eliminated.
The security risk is maximized if the VTAM product routes the remote user request through an AVS gateway, the remote user specifies SECURITY=SAME, and partner LU verification is not performed. In this situation, you should use AVS to translate the inbound user ID to one that is registered with the local security manager product. The translated user ID is validated by the local security manager product, which can be CP, RACF, or an equivalent product.
The situation described cannot happen if the remote user is using SECURITY=PGM. This user must obtain a user ID and password from the local system administrator before being able to specify SECURITY=PGM to access an application server.
| Note: | Do not allow remote users to use a user ID that already exists on the local system and that has been assigned to a local user. |
To help prevent unauthorized or malicious access to the database minidisks, do the following: