Processing of remote attachment requests

The Db2 server completes a specific sequence of authentication process before accepting a remote attachment request that uses the SNA protocol.

  1. As the following diagram shows, if the remote request has no authentication token, Db2 checks the security acceptance option in the SECURITY_IN column of table SYSIBM.LUNAMES. No password is sent or checked for the plan or package owner that is sent from a Db2 subsystem.
    Figure 1. Db2 processing of remote attachment requests
    Begin figure description. DB2 processing of remote attachment requests. End figure description.
  2. If the acceptance option is verify (SECURITY_IN = V), a security token is required to authenticate the user. Db2 rejects the request if the token missing.
  3. If the USERNAMES column of SYSIBM.LUNAMES contains I or B, the authorization ID, and the plan or package owner that is sent by a Db2 subsystem, are subject to translation under control of the SYSIBM.USERNAMES table. If the request is allowed, it eventually goes through sign-on processing. If USERNAMES does not contain I or B, the authorization ID is not translated.
  4. Db2 calls RACF® by the RACROUTE macro with REQUEST=VERIFY to check the ID. Db2 uses the PASSCHK=NO option if no password is specified and ENCRYPT=YES if the ENCRYPTPSWDS column of SYSIBM.LUNAMES contains Y. If the ID, password, or PassTicket cannot be verified, Db2 rejects the request.

    In addition, depending on your RACF environment, the following RACF checks may also be performed:

    • If the RACF APPL class is active, RACF verifies that the ID has been given access to the Db2 APPL. The APPL resource that is checked is the LU name that the requester used when the attachment request was issued. This is either the local Db2 LU name or the generic LU name.
    • If the RACF APPCPORT class is active, RACF verifies that the ID is authorized to access z/OS® from the Port of Entry (POE). The POE that RACF uses in the verify call is the requesting LU name.
  5. The remote request is now treated like a local connection request with a DIST environment for the DSNR resource class. Db2 calls RACF by the RACROUTE macro with REQUEST=AUTH, to check whether the authorization ID is allowed to use Db2 resources that are defined to RACF.

    The RACROUTE macro call also verifies that the user is authorized to use Db2 resources from the requesting system, known as the port of entry (POE).

  6. Db2 invokes the connection exit routine. The parameter list that is passed to the routine describes where a remote request originated.
  7. If no password exists, RACF is not called. The ID is checked in SYSIBM.USERNAMES.
  8. If a password exists, Db2 calls RACF through the RACROUTE macro with REQUEST=VERIFY to verify that the ID is known with the password. ENCRYPT=YES is used if the ENCRYPTPSWDS column of SYSIBM.LUNAMES contains Y. If Db2 cannot verify the ID or password, the request is rejected.
  9. Db2 searches SYSIBM.USERNAMES for a row that indicates how to translate the ID. The need for a row that applies to a particular ID and sending location imposes a come-from check on the ID: If no such row exists, Db2 rejects the request.
  10. If an appropriate row is found, Db2 translates the ID as follows:
    • If a nonblank value of NEWAUTHID exists in the row, that value becomes the primary authorization ID.
    • If NEWAUTHID is blank, the primary authorization ID remains unchanged.
  11. The remote request is now treated like a local sign-on request. Db2 invokes the sign-on exit routine. The parameter list that is passed to the routine describes where a remote request originated.
  12. The remote request now has a primary authorization ID, possibly one or more secondary IDs, and an SQL ID. A request from a remote Db2 is also known by a plan or package owner. Privileges and authorities that are granted to those IDs at the Db2 server govern the actions that the request can take.