Secure > Enhance site security
Initialize KLF in WebSphere Commerce Payments
The encryption key providers are defined in a keys configuration file. For an attended start-up Payments instance, an attribute KeysConfigFile in the Payments instance XML file points to the keys configuration file. This attribute will be used to initialize the KLF when starting, stopping, updating or deleting the instance. For an unattended start-up Payments instance, a custom property wpm.keysConfigFile in the JVM setting of the corresponding WebSphere Application Server instance also points to the keys configuration file. It is used to initialize the KLF when starting the instance. The KeysConfigFile attribute will be used when updating or deleting an unattended start-up instance.
The KeysConfigFile attribute and the wpm. keysConfigFile property must specify a relative path to the Payments instance XML directory:
Attended start-up means that instance password is required when starting the Payments instance. Unattended start-up means that instance password is not required when starting the Payments instance. For more information, refer to Checking the WebSphere Commerce Payments instance password requirements. WC_INSTALL/instances/ payments_instance/xml
For example, KeysConfigFile ="config/CustomKeys.xml"
If the KeysConfigFile attribute is not present in the instance XML file, a hard-coded location of the keys configuration file will be used: WC_INSTALL/payments/xml/config/WCKeys.xml
For an unattended start-up Payments instance, if the wpm.keysConfigFile property is not present in the JVM setting of its corresponding WebSphere Application Server instance, the Payments instance password will not be retrieved through the Key Locator Framework but from the wpm.pip property, an encrypted version of the Payments instance password.
The default WCKeys.xml should not be customized by the customer. The custom keys configuration file that is specified using the KeysConfigFile attribute and the wpm.keysConfigFile property should use a different name instead of WCKeys.xml, to avoid it from being overwritten during migration to 6.0.
The default WCKeys.xml applies to all Payments instances. This default WCKeys.xml file will contain a WCPaymentsInstancePasswordImpl provider, which will continue to read the Payments instance password from the Payments instance XML file.
However, if the customer wants to store the Payments instance password in another location, such as in an external file or hardware device, they must manually add the KeysConfigFile attribute to the Payments instance.xml file, which specifies the location of their customized keys configuration file. For an unattended start-up instance, they also need to add the wpm.keysConfigFile property to the JVM setting of the corresponding WebSphere Application Server instance, which also specifies the location of their customized keys configuration file. This customized keys configuration file will register the new Payments instance password provider class, which will manage the Payments instance password that is going to be stored in a new location.
If you are using iSeries, use an unattended start-up instance to be PCI compliant. This is due to the iSeries platform limitation that the Payments instance password cannot be masked in the command line when issuing the IBMPayServer command to start the payment instance. This does not comply with the PCI criteria of "Split knowledge and dual control of keys". For an unattended start-up Payments instance, you can start it by starting the corresponding WebSphere Application Server instance.
To change the start-up mode of the Payments instance, refer to Changing the WebSphere Commerce Payments instance password requirements.
- Key Provider Implementations for Payments instance password
The most secure solution is to store the Payments instance password in a hardware device. A hardware solution takes care of matters such as secure storage and split knowledge of the merchant key. However, it is also possible to store an encryption key in a file, as long as proper file permissions are in place, file integrity monitoring is in place, and access to the file is audited.