Establishing remote trusted connections to Db2 for z/OS servers

The authentication token can be a password, a RACF® passticket, or a Kerberos ticket. The requester goes through the standard authorization processing at the server. If the authorization is successful, Db2 invokes the connection exit routine, which associates the primary authorization ID, possibly one or more secondary authorization IDs, and an SQL ID with the remote request. Db2 searches for a matching trusted context. If Db2 finds a matching trusted context, it validates the following attributes:

• If the SERVAUTH attribute is defined for the identified trusted context and TCP/IP provides a RACF SERVAUTH profile name to Db2 during the establishment of the connection, Db2 matches the SERVAUTH profile name with the SERVAUTH attribute value.
• If the SERVAUTH attribute is not defined or the SERVAUTH name does not match the SERVAUTH that is defined for the identified trusted context, Db2 matches the remote client's TCP/IP address with the ADDRESS attribute that is defined for the identified trusted context.
• If the ENCRYPTION attribute is defined, Db2 validates whether the connection is using the proper encryption as specified in the value of the ENCRYPTION attribute.
• If the DEFAULT SECURITY LABEL attribute is defined for the system authorization ID, Db2 verifies the security label with RACF. This security label is used for verifying multilevel security for the system authorization ID. However, if the system authorization ID is also in the ALLOW USER clause with SECURITY LABEL, then that one is used.

If the validation is successful, Db2 establishes the connection as trusted. If the validation is not successful, the connection is established as a normal connection without any additional privileges, Db2 returns a warning, and SQLWARN8 is set.