Communication security

Note

Communication security is only really essential for the communication to site-business as that component should only process requests containing compound identifiers arriving from the client component (or any other suitably secured “client”, e.g. a Perl script) which is expected to have an appropriate authentication mechanism configured. See here for further information on generic client authentication options.
For app-manager and dose-response-manager component WS’s, these could be kept as “open” resources for any potential “client” application, e.g. a command-line script, as the WS message content will never contain any data which identifies a compound.

HTTPS

All inter-component WS communication uses WSS and so all such communication should be encrypted HTTP, e.g. using X.509 certificates (self-signed or otherwise).

An example configuration of such a setup is available for Tomcat.

WSS

All inter-component WS communication uses WSS (description here) of the User ID/Password variety. For this to be effective the passwords used should be :

1. Stored in an encrypted format
2. Communicated in an encrypted format, i.e. HTTPS.
3. In access-controlled files

WS IP access control

Access to any component’s WS, e.g. app-manager, site-business and dose-response-manager, can be restricted to specified IP origin addresses by, for example, the inclusion of a Remote Address Filter in Tomcat’s web.xml configuration file.

WWW/Internet communication

Once installed, AP-Portal’s generic portal components have no need to access the internet – the portal could operate unhindered within corporate firewalls. Having said that, ApPredict on the other hand will attempt to retrieve variability lookup tables if they cannot be found locally (see variability configuration).

Having said that, there would be nothing preventing site-specific component implementations or extensions, e.g. for client or site-business, from communicating through corporate firewalls if requirements necessitate doing so.