This page outlines the security aspects to be considered when developing with Caplin products or carrying out security testing assessments when testing against your Caplin client and server stacks. The provided information is intended for use by developers who wish to implement a secure environment as they develop with Caplin product(s). See further down for the recommended security practices that are currently applicable.
Recommended security practices when integrating with Caplin server-side components:
|Ensure server-side validation for sensitive trade data sent from the client (e.g. deal execution)||
Note: Caplin Platform server-side components do not, out-the-box, perform validation on the authenticity of the trade data sent from the client. This responsibility is to be handled by your existing trading systems.
In the case of authenticating trade prices for deal execution, there are several ways to handle this from past observations by Caplin.
Some of which are:
We recommend you ensure that these test cases are covered in your UAT environments prior to deployment in a production environment.
|When implementing your own DataSources/Adapters, all data from an untrusted source should be encoded||
Any user submitted input at the client side that is to be to sent to the server and be persisted somewhere will need to be encoded
Reinforce permissions for Trading on Behalf of (TOBO) trade messages
With TOBO, a sales user can trade FX on behalf of others, such as clients. In the FX Sales Motif, specific trade messages send a TOBOUser field to Liberator whenever a sales user submits or executes a trade - see RFS Submit and RFS Execute messages. This TOBOUser field is used for specifying the client that the sales user is permissioned to trade on behalf of. If the sales user is not permissioned to trade on behalf of the client specified, then the trade message should be rejected by Liberator.
If there are no checks to validate sales user/client permissioning, then it is possible for the trading system to proceed booking the trade as normal as it would have expected the value for TOBOUser to have been validated prior to booking.
Reinforcing the permissions behind TOBO related trade messages is something that can be done either programmatically (generated) or configured via XML configuration. You can find useful information on permissioning concepts and configuration options in the following documentation:
KeyMaster Servlet Authentication
KeyMaster is a servlet that facilitates the process of logging into Liberator via StreamLink as you access financial data through the Caplin FX Professional web app. KeyMaster integrates with your existing single sign-on (SSO) system to maintain secure access to financial data contained within Liberator. If you have configured FX Professional front-end systems to use KeyMaster (more information on this page), please see the following security recommendations:
|KeyMaster servlet implementation guideline||
KeyMaster is an API shipped with several implementation examples to help you get started. When it comes to deploying FX Professional into a production environment, it is strongly recommended that you use the JndiKeyMasterServlet implementation as a basis for your own SSO integration.
An example JndiKeyMasterSerlvet implementation is shipped by default within FX Professional. Caplin recommends that you write your own implementation based on the example provided for the JndiKeyMasterServlet in your KeyMaster <version> deployment package.
Important: Do not use the UnsecureUrlParameterCredentialsProvider class in the provided example servlets outside of development or in a production environment for authentication testing.
|Encode any additional sensitive data sent with an authentication token to Liberator||
The KeyMaster process of authentication when logging into Liberator allows for extra data to be appended to the creation of a valid authentication token that will be verified by Liberator.
If you are creating a KeyMaster implementation which makes use of these additional parameters as part of a single sign-on, it is recommended that you encrypt any extra data to prevent this data being sent in plain-text. If you have any technical queries regarding this - please contact Caplin Support.