Chapter 3   Configuration



Configuration Overview

---

The following configurations need to take place:

· Certificates and Bank Back End Authorisation

· Database checkpoints that allow you gain access to information about the cause of error during runtime

· Screen Services

· Payments Screens

· Customers Authorisation Services

Certificate Configuration

---

Before testing your installation is complete you will need to configure the system with the appropriate certificates.

Buyers Bank Certificates

You'll need a signing certificate issued to you by your Bank and containing a Trusted Identrus Root. This is a certificate hierarchy and contains a PKCS12 signing chain containing private key for signing information.

Sellers Website Tooled Up Certificates

This is dealt with in the Install procedure for tooledup.

iPlanet Trustbase Transaction Manager Certificates

Certificates need to be configured as described in the Identrus four corner model. See http://docs.iplanet.com/docs/manuals/trustbase/221/install/ittm22cb.htm#157035

iPlanet Trustbase Payment Services Certificates

None required

BiaB Certificates

Please refer to "Installing Bank in a Box back office simulator" and "Installing Bank in a Box Admin Tool" for details about this

CPI certificates

Please refer to "Installing the CPI API" for details of how to install certificates

Database Check Points

---

This data flow checkpoint diagram and list of points will be used during a transaction and can be used to help locate where an event or error occurs in the system. This is only applicable to synchronous messages. When messages are sent from the Seller web site, messages can be traced at the following points, illustrated using the three corner model in Figure 3-1 "Data Checkpoint List for the three corner model":

Checkpoint	Action/Step/Entry	Table/Location to view data/Message
1	Buyer posts a request to the seller's web site.	Web server log (web server): Iws/logs/access
2	Message (transaction) is sent from CPI to iTTM/iTPS (TC). The message is logged.	Kxs access is written with a timestamp: ias/logs/kxs Kjs jvm log file with system.out text: ias/logs/kjs iTTM Oracle table: RAW_DATA
	Initially message is validated. If error in validation, log to audit. If error in system, log to error	iTTM Oracle table: AUDITDATA iTTM Oracle table: ERROR
3	TC performs validation check using OCSP to check the status of the Seller's (Tooled Up) signing certificate.	OCSP log (See OCSP vendor logs)
4	CSC request to Identrus root (freshness).	iTTM Oracle table: RAW_DATA
5	CSC response from Identrus root	iTTM Oracle table: RAW_DATA
6	TC sends message to BiaB.	iTTM Oracle table: PAYMENTS_RAW_OUT
7	BiaB receives message and logs to BiaB Oracle	BiaB Oracle table: BIAB_REQUESTS. Note this message is identical to the message in PAYMENTS_RAW_OUT (step 6). BiaB terminal shows that a message is received.
8	BiaB processes message and logs response to TC in BiaB Oracle.	BiaB terminal shows that a message is ready. BiaB Oracle table: BIAB_RESPONSES
9	TC receives message from BiaB and logs incoming message.	iTTM Oracle table: PAYMENTS_RAW_IN. Note the message is identical to the message in BIAB_RESPONSES (step 8).
10	TC sends message to web server and logs the outgoing message.	iTTM Oracle table: RAW_DATA
11	Seller (tooled up) logs payment message and status.	Seller Oracle table: PAYMENTS

Figure 3-1    Data Checkpoint List for the three corner model

Configuration Pre-requisites

---

iTTM and iTPS, and all their associated components such as iAS and iWS, should be running while configuring services within iTTM.Thus, you must make sure the following software is up and running in the order specified

1. Oracle 8i

2. nCipher HSMs on all machines

3. iMQ for Java 2.0 on both the Buyer and Seller Bank machines

4. Bank in a Box and iWS 6.0 on the Buyer and Seller Bank machines

5. Bank in a Box administration tool server and iWS 6.0 on the Buyer and Seller Bank machines

6. iTPS on the Buyer and Seller machines
   1. iWS 4.1 on both the Buyer and Seller Bank machines

   2. iAS 6.0 on both the Buyer and Seller Bank machines

   3. iTTM 2.2.1 on both the Buyer and Seller Bank machines

7. JMQ Proxy on both the Buyer and Seller Bank machines

8. Buyer web site (BFI) web server

9. Tooledup Seller web site web server

System Configuration

---

iPlanet Payment Services Configuration can be accessed from the following menu

Figure 3-2    Payment Main Menu

Payment Gateway Preferences

The system administrator may configure

· The JMS queue identifiers used to communicate with the payment gateway.

· The timeout to be used when communicating with the payment gateway.

Figure 3-3    Payment Gateway Preferences Screen

This is already configured from the original installation and is set here as the default.

· · Outbound Queue may not be empty

· Timeout is how long you are prepared to wait for a response when you send a message to your JMS queue. 0 is the default and this means it waits indefinitely until it gets a response.

· Number of Timeouts is the number of times you send a message to a queue to get a response. When the timeout is set to 0 it does not matter what you enter here.

Scheme Membership List

The system administrator may add, modify or delete entries from the Scheme Membership List.

Figure 3-4    Scheme Membership List Screen

When the user clicks on a bank name, the Scheme Member Details screen is shown.

When the user clicks the <delete> link, a confirmation dialog is displayed and, if confirmation is given, the corresponding entry is removed from the list.

When the user clicks on the <add a new entry> link, the same Scheme Member Details screen is shown with empty fields.

On submission, the Scheme Member Details form is validated according to the following rules:

· Bank Name needs to be present

· Comment is optional

· FI Code needs to be present. FI Code needs to be 11 digits.

· CUG ID needs to be the membership scheme e.g. Eleanor.

· Routing URI needs to be present and a valid URI according to RFC 2396.

· Bank Distinguished Name and Issuer Distinguished Name needs to be present and have a valid distinguished name according to RFC 2253.

· Date is checked.

Note that this does not need to be applied if you are doing 3 corner models. If the node acts in the four corner model then the other SFI's and BFI's that you will communicate with need to be registered.

Figure 3-5    Member Details

Membership Status can be one of

· Active

· Pending

· Suspended

· Terminated

Service Status determines whether the member is still operating within the scheme. Members can be:

· Available

· Unavailable

To enable membership checking for this iTPS, a modification is required to the file

<ittm_install_directory>/<hostname_directory>/identrus.properties

Membership.Check=true

This has the effect of only allowing payments for financial institutions that are listed within this screen.

Inter-Participant Timeouts

The system administrator may configure the timeout values used when communicating with other Scheme participants.

Figure 3-6    Inter-Participant Timeouts Screen

These parameters determine how often you need to retry sending an interbank message. there are two values: (a) Timeout value: the length of time one waits before sending an interbank message again (b) Number of timeouts: the number of times one keeps retrying to send the interbank message. The Timeout value can be greater than 0. If set to 0, then Timeout is considered infinite. This can be left as the default and under normal circumstances does not need to be changed.

Settlement Chain

Before making payments, a currency settlement chain needs to be established. This requires, in the first instance, deciding which financial institution you want to use to accept payments in a particular currency. You can then

1. select a currency

2. assign it to the financial institution (provided the financial institution can trade in that currency)

3. finally add it to your currency settlement chain.

In some instances you may want payment initiation messages to be settled in many different currencies. Under such circumstances, iPlanet Trustbase Payment Services needs to be configured to accept a number of financial institutions that are used to settle payments in a variety of currencies.

1. Select <Services><Payments><Settlement Chain>

Figure 3-7    Settlement Chain Main Menu

Settlement chains are used by the SFI to inform the BFI of the SFI details of where to make payment, or if the currency supplied in the transaction cannot be accepted at the SFI, a chain of F.I> that can convert the payment into a currency that the SFI can accept.

2. There are    four steps for adding a currency to the payment settlement chain:
   1. First select <Financial Institution Administration> assign the account number of the institution that is to settle your currency

   Financial Institution Administration
   
   

   The SFI settlement role is always set to the Beneficiary Institution. Each financial Institution entered may be entered several times for different currencies and associated accounts into which to place the payment.

   1. Second, define the currencies that can be accepted through this SFI. Select <Currency Code Administration>. Each currency code must have at least the SFI associated with the currency, effectively making a settlement chain of one financial Institution, itself.

Figure 3-8    Currency Code Administration

1. Third select a currency that you want to assign a financial institution to. Select <Add Chain>

2. Fourth select a currency, from the screen on the previous page, by double clicking on it and match the currency to the financial institution by selecting <Add Link> as illustrated below:

Figure 3-9    Adding a currency code to the Settlement Chain

If a SFI can accept a currency directly, then it alone has to be associated with that currency. If the SFI cannot directly accept a payment in a specific currency then a settlement chain of additional financial institutions has to be created in order to convert the payment into a currency that can be accepted by the SFI.

3. Adjusting some of the data that appears in some of the tables can be done via the Oracle tables that are installed via the SQL script

   <Trustbase_install_directory>/TTM/V2.2/Config/sql/Payments.sql

The following table may need to be reconfigured:

· SC_CURRENCY_CODE_LIST - This contains all the possible currency codes that a user can select from when forming a chain or creating a transaction currency code.

Payment Recovery

iTPS provides the facility to re-present a payment request in the event that it failed on the first attempt. This can occur for example, if the buyers financial institution is not contactable at the time of the payment request.

By select the <List Recoverable messages> from the payments menu, any transactions that started but failed to complete will be listed, as shown below.

Figure 3-10    Recoverable Messages

To initiate a recovery, select the <Start recovery process> option from the payments menu. This may take some time as it re-presents any recoverable payment requests through the system. Upon completion a list of recovered transactions is displayed, as shown below.

Figure 3-11    Recovered messages

Customer Authorisation Service for iTPS

---

Authorising Customers to the payment services is achieved by matching certificate name details. Upon successful match it assigns the customer with a customer ID. This is different from iPlanet Trustbase Transaction Manager's authorisation facility as iTPS has individual authorisation rather than generic corporate authorisation.

1. Using SQLPlus go into your iPlanet Trustbase Transaction Manager Server

   SQL> describe cust_dn_mapping;

   
   

   Figure 3-12    cust_dn_mapping
   

   
   

   Name	Null	Type
   DN	NOT NULL VARCHAR2	(1024)
   CUST_ID	NOT NULL VARCHAR2	(36)

   SQL> insert into cust_dn_mapping values ('CN=RC from IP;O=IP;OU=IP Bank;','1');

   1 row created.

   SQL> commit;

   Commit complete.

   SQL>

2. Modify the properties file identrus.properties by changing the following to

   customer.auth.checking = true

3. The DN column accepts the customers signing certificate subject name as its input.