IBM Connect:Direct Secure Point-of-Entry

You need security on the local node because adjacent nodes need access to local nodes in order to transfer files. IBM® Connect:Direct® administrators have three options for security on transfers initiated at a remote node:

  • No security for either functional authority or data protection
  • Matching user ID/password combinations for all adjacent nodes
  • SNODEID/SNODE password overrides on incoming access requests

Point-of-entry security secures the entry of an outside user to your system. It works with your current security setup (including all current exits) to provide additional security that addresses concerns about users from other nodes knowing a user ID and password combination on your system. Both data protection and IBM Connect:Direct functional authority are accomplished with exits.

Point-of-Entry Processing is internal within IBM Connect:Direct, and happens prior to calling the security exit for validations.

The following figure illustrates the flow of security checking for secure point-of-entry:

Security checks are made automatically for every incoming Process, so no parameter is needed to activate point-of-entry security. To implement point-of-entry, add user ID and node name combinations to your Authorization file. For instructions on manipulating the IBM Connect:Direct Authorization file, see Authorization File.

The security exit determines if a secure point-of-entry translation was performed on a user ID by checking the bit SQIDXLAT of the SQCB control block (DGA$SQCB macro in the $CD.SDGAMAC library).

Point-of-Entry Concept

When a Process is submitted by another node, the receiving IBM Connect:Direct node has access to the user ID of the person who submitted the Process and the name of the node of the submitted Process.

For example, the local node is CD.HOUSTON, and a user SMITH submits a Process on CD.CHICAGO to copy a file to CD.HOUSTON. By placing an entry of SMITH/CD.CHICAGO into the local IBM Connect:Direct authorization file, the security administrator for CD.HOUSTON can associate this user with a valid user ID and password on the local system. The IBM Connect:Direct Authorization file has the following values:

USERID         = SMITH
NODE           = CD.CHICAGO
SECURITY ID    = JONES
SECURITY PSWD  = DALLAS

In this scenario, when user ID SMITH on node CD.CHICAGO submits a Process to run with node CD.HOUSTON, the functional authority and the data set validation for that Process are done under the authority of user ID JONES, which is a valid user ID on CD.HOUSTON. The user from the Chicago node never needs to know the related valid user ID and password on the CD.HOUSTON node.

USERID         = SMITH
NODE           = CD.HOUSTON
SECURITY ID    = JONES
SECURITY PSWD  = DALLAS

Secure Point of Entry Optional Variations

Note the following variations:

  • If the CD.HOUSTON node enables SNODEID overrides and user SMITH puts an SNODEID parameter in the Process, the Authorization file is not checked and the translation of the user ID and password is not done.
    Note: If the INVOKE.SPOE.ON.SNODEID initialization parameter is set to YES, then the Authorization file is checked and the user ID and password are translated.

    For example, if the incoming Process in the previous example is coded with SNODEID=(BROWN,PWB), even if it is submitted by SMITH from CD.CHICAGO, the CD.HOUSTON node will send the user ID BROWN, not user ID JONES to the security subsystem for validation.

    Note: To produce a completely secure point-of-entry security system, disable SNODEID overrides. To disable SNODEID overrides, specify SNODEID=NO in your stage 2 security exit.
  • Although the point-of-entry system requires some maintenance of the Security ID and Security Password fields in the Authorization file, you can assign the same user ID and password combination on your system to multiple incoming users.

    For instance, you can specify JONES/DALLAS as the user ID and password for all users coming into your node from CD.CHICAGO. In addition, if you are running a stage 1 signon exit, you can specify the security password for all users as IUI, BATCH, or STC, and avoid the need to update the Authorization file as the password changes.

  • IBM® IBM Connect:Direct® for OpenVMS is not able to pass an OpenVMS password with the OpenVMS user ID. If you are using secure point-of-entry with incoming OpenVMS nodes, you must leave the User Password field blank in your z/OS authorization file, or all incoming OpenVMS Processes will fail.