A distributed relational database administrator needs to protect the resources of the application servers in the network without unnecessarily restricting access to data by application requesters (ARs) in the network.
An AR secures its objects and relational database to ensure only authorized users have access to distributed relational database programs. This is done using normal iSeries™ server object authorization to identify users and specify what each user (or group of users) is allowed to do with an object. Alternatively, authority to tables, views, and SQL packages can be granted or revoked using the SQL GRANT and REVOKE statements. Providing levels of authority to SQL objects on the AR helps ensure that only authorized users have access to an SQL application that accesses data on another system.
The level of system security in effect on the application server (AS) determines whether a request from an AR is accepted and whether the remote user is authorized to objects on the AS.
Some aspects of security planning for iSeries server in a distributed relational database network include:
Location, user-related, and object-related security are only possible if the system security level is set at level 20 or above.
For Advanced Program-to-Program Communication (APPC) conversations, when the system is using level 10 security, an iSeries server connects to the network as a nonsecure system. The server does not validate the identity of a remote system during session establishment and does not require conversation security on incoming program start requests. For level 10, security information configured for the APPC remote location is ignored and is not used during session or conversation establishment. If a user profile does not exist on the server, one is created.
When the system is using security level 20 or above, an iSeries server connects to the network as a secure system. The iSeries system can then provide conversation-level security functions and, in the case of APPC, session level security as well.
Having system security set at the same level across the systems in your network makes the task of security administration easier. An AS controls whether the session and conversation can be established by specifying what is expected from the AR to establish a session. For example, if the security level on the AR is set at 10 and the security level on the AS is above 10, the appropriate information might not be sent and the session might not be established without changing security elements on one of the systems.
The most common method of authorizing a remote user for database access is by flowing a user ID and password at connection-time. One method an application programmer can use to do this is to code the USER/USING clause on an embedded SQL CONNECT statement. For example:
EXEC SQL CONNECT TO :locn USER :userid USING :pw
For Distributed Relational Database Architecture™ (DRDA) access to remote relational databases, once a conversation is established, you do not need to enter a password again. If you end a connection with either a RELEASE, DISCONNECT, or CONNECT statements when running with the remote unit of work (RUW) connection management method, your conversation with the first application server (AS) might or might not be dropped, depending on the kind of AS you are connected to and your application requester (AR) job attributes (for the specific rules, see Control DDM conversations). If the conversation to the first AS is not dropped, it remains unused while you are connected to the second AS. If you connect again to the first AS and the conversation is unused, the conversation becomes active again without you needing to enter your user ID and password. On this second use of the conversation, your password is also not validated again.