In order to protect the data (and the servers themselves) from unauthorised access, the server includes an Access Control Unit (ACU). The ACU enforces the access control policy defined in the server Access Control Policy file. The policy specifies the access control conditions that apply to each resource. Complex conditions can be defined relative to the kind of user, the purpose in using the data (commercial, research, etc.), the kind of operation required, and the legal conditions accepted by the users. On the base of this information the ACU can protect the resources and also "drive" the user in the process of acquiring the necessary rights (for example the user might be required to login, to agree to some conditions, etc.). The ACU can be customized by defining additional site-specific conditions and/or connections to the site user database.
The Default Access Control Policy
The Access Control Policy file installed by default defines a few basic types of users with the following rights:
- anonymous: can browse and search the studies metadata
- authorised and guest: can also perform statistical operations
- fully authorised: can also download and subset data
- publisher: can also publish data and metadata
- administrator: can perform any operation
Customising the Access Control Policy
The Nesstar ACU can be customised to implement different access control policies. For more information refer to the Nesstar ACU Customisation Guide.
Enabling SSL (Secure Socket Layer)
If you want your data to be password protected or you worry about third parties intercepting and modifying your http traffic, you'll need to enable Secure Sockets in your Nesstar configuration. Secure Sockets mean that the http traffic is encrypted using public key croptography. This will prevent man in the middle attacks.
To use Secure Sockets your server will need croptographic keys. These keys will be used together with the end users browser or Nesstar Publisher keys to encrypt the traffic. To add to the security it is possible to have a trusted third party vouch for your identity. These trusted third parties are companies like VeriSign and Thawte. They will not make the encyption more secure in it self, but they will guarantee to the end-user that you are who you claim to be.
When you use keys that have not been vouched for by a Certification Authorithy (CA), we say that you are using a self-signed certificate. When you've gotten a CA to vouch for your keys, you have a signed certificate.
Using a signed certificate in Nesstar
To get a signed certificate you must first generate a key pair and a certificate signing request (CSR). How this is done is outide the scope of this document. Refer to the certificate signing authority's documentation and come back here once you have received your signed certificate.
The following guide assumes that you have your public certificate and its corresponding private key in separate .pem files (these are base64 encoded X.509 certificates). It is also assumed that you have all the links in the certificate chain from your public key up to a widely known CA in one or several .pem files. If your keys are currently in a different format, you will need to convert them before continuing. The tools delivered with openssl (available for both Windows and Linux) is able to do this. Consult the openssl documentation for a description of how this is done for your certificate file format.
Once you have satisfied the demands listed above, these are the steps to install your keys in a Nesstar server:
- Create a temporary private key in pkcs#12format from your .pem formatted private key. This can be done using the openssl tool (openssl is not bundled with Nesstar, but can be downloaded for free). The command to do this is as follows (The filenames are examples only, and will vary):
$ openssl pkcs12 -export -in server-certificate.pem -inkey server-pricate-key.pem -out server-private-key.pkcs12
NB: Because of a bug in Java's keytool, you will have to create a password for this temporary pkcs#12 file (openssl will ask you to come up with one). Our SSL scripts assume that this password is "nesstar" (without the quotes), so give that password to avoid having to edit the scripts later on.
At this point it is very important that you have one and only one .pkcs12 file in your config/ssl folder.
- Delete the .pem formatted private key (you might want to keep a copy somewhere)
- Stop the Nesstar server
- Delete config/ssl/keystore.jks and config/ssl/truststore.jks if they exist
- Run "bin/install.bat apply" if on Windows or "bin/install.sh apply" if on Linux. This will apply the changes and start the server.
- Confirm that SSL is working. Opening WebView at this point, your web browser should indicate that it is using a secure connection, and it should not complain that the host cannot be trusted or anything like that.
- You are done! Delete the .pkcs12 file and - if you want - the .pem files. The keystore.jks file now contains your private key, and should therefore be protected from unauthorized access.
Using a self-signed certificate in Nesstar
Due to limitations in the java keytool, a fully qualified domain name or the ip address must be used in the "IP Address" field in the configuration tool if you want to use self signed certificates. Using settings like "localhost" or your servers name on the lan will create invalid certificates.
Other than setting a supported IP Address, no action is required to set up a self-signed certificate. It will automatically be created when the server is started if no certificate has been explcitly installed or has been genereated already.
Using self-signed certificates will make clients such as WebView and the Nesstar Publisher complain that the server cannot be trusted. This warning can be worked around by making an exception in the web browser, or installing the certificate in Nesstar Publisher. Refer to the Nesstar Publisher documentation for a description of how to do this.