Access Control

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:

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:

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.