Configuring a connection between the signature verification service and an SAG

For each business OU that employs the signature verification service (DNF_V_REQ) for a particular message transfer service (for example, SIPN FIN) or the signature verification API (DNF_V_API), there must be a connection between DNF_V_REQ (respectively DNF_V_API) and the SAG that is to verify the message signatures. Each connection specifies:
  • Which message partner is the source of the LAU key that is to be used to authenticate the messages passed to and from the SAG
  • Which authoriser DN is to be used to authorize VerifyDecrypt requests in the SAG.
Regardless of how many message partners are on an SAG, only one connection is required for each combination of OU, SAG, and message transfer service.
You configure such a connection by setting the attributes of a CO of type DnfVerifConn. To help you do this, FTM SWIFT generates, during customization, for each business OU, scripts with names of the form:
deployment_dir/instance/admin/ou_dnfcvcsc.cli
where:
deployment_dir
Directory specified in the CDP initialization file.
instance
Name of the instance.
ou
Name of the OU.
This script contains the following commands:
add -ou DNIvOU -ct DnfVerifConn -co <service><number> -attr enabled
add -ou DNIvOU -ct DnfVerifConn -co <service><number> -attr SAGRequestQueue -val <queue>
add -ou DNIvOU -ct DnfVerifConn -co <service><number> -attr SAGQMgr         -val <queue_manager>
add -ou DNIvOU -ct DnfVerifConn -co <service><number> -attr AuthoriserDN    -val <DN>
add -ou DNIvOU -ct DnfVerifConn -co <service><number> -attr MessagePartner  -val <message_partner>
add -ou DNIvOU -ct DnfVerifConn -co <service><number> -attr SAGName         -val <sag_name>
com -ou DNIvOU

The customization process substitutes the placeholder DNIvOU in the scripts with the name of the OU. To modify and run these scripts:

  1. Copy the script into your home directory.
  2. In each copy of ou_dnfcvcsc.cli, copy the set of commands once for each SWIFT service that is to be used (for example, for SWIFTNet FIN) and once for the signature verification API.
  3. Replace the following items as appropriate:
    <service>
    A character string that indicates the service for which the connection applies:
    DnfFIN
    The SIPN FIN service.
    DnfAPI
    The signature verification API addressed via flow DNF_V_API.
    <number>
    A two-digit number used to make the name of each connection unique.
    enabled
    This pseudo attribute indicates whether the connection is active. To prepare a connection but keep it inactive until it is ready to be used, configure all its attributes except this one.
    SAGRequestQueue <queue>
    The queue to which VerifyDecrypt requests are to be sent.
    SAGQMgr <queue_manager>
    The queue manager of the queue to which VerifyDecrypt requests are to be sent.
    AuthoriserDN <DN>
    The authoriser DN that is used to authorize the VerifyDecrypt requests in the SAG.
    MessagePartner <message_partner>
    The message partner to which the LAU key that is to be used to encrypt message traffic belongs. This message partner can be either a special message partner that is used exclusively to provide this LAU key, or it can be any of the message partners that are already defined for the SAG, if its LAU key can be used for this purpose. The LAU key must be configured both on the SAG and in FTM SWIFT, that is, it must correspond to a CO of type DnfLAUKeyMP.
    SAGName <sag_name>
    The name of the SAG that is to verify the message signatures.
  4. Run each copy of the ou_dnfcvcsc.cli script. To do this, you must have the system configuration administrator (DniSA) role. For example, to run the scripts for the OU BANKA in instance INST1, enter the following command:
    dnicli -i INST1 -ou SYSOU -s DNI_SYSADM -cft BANKA_dnfcvcsc.cli
  5. Commit, approve, and deploy the changes:
    dnicli -i INST1 -ou SYSOU -s DNI_SYSADM 
    app -ou BANKA
    dep -ou BANKA

    If dual authorization is enabled, another user with the appropriate access rights must approve the changes before they can be deployed. If dual authorization is disabled, you can skip approving the changes and immediately deploy them.