First Steps

After the installation is completed, you will find the installed VisShare directory in the given path and four running services:

If any of these services do not run, you can expect an error. To ensure a smooth behavior for the end user, you should set these services to restart on service failure and on server restart (you can do this via the Windows Services properties).

A common approach is to change the model repository from the default path (inside the VisShare installation folder).

To do this, there are a few settings that need to be updated to point to the new location:

Debugging

If you encounter any errors, there are multiple directories to look for log files:

Security Considerations

This chapter will cover some security considerations you should keep in mind.

Service Account Rights

We recommend to run the services mentioned above with special service accounts. You should restrict access to the model repository and to the VisShare folder only to this service account, so that other users on the systems can't read the model or configuration files (there are clear text access informations in the configuration files).

Model Repository

To emphasize the last recommendation, the model repository should always be secured against access from non-permitted users/services/applications. If the model repository is located outside of the VisShare server system, you may need to implement a new service account on the VisShare machine, that has access to the remote model repository and set this account for the VisShare services.

VisShare User Access

The VisShare user access is layered in multiple access controls. The default installation tries to use the highest security regarding the user access limitation.

Access control can be managed by following layers:

1.Registration

User accounts on the VisShare can be created via registration (email + password). It is possible to define the way, registrations can be done via settings:

2.Access to the VisShare itself

The VisShare is by default only accessible with a valid login (email + password) from a confirmed user mail (a newly registered user must click on a confirmation link send to this email).

New user accounts can be further restricted by following settings:

There are two ways to bypass the login, the first (and recommended) is by accessing file links that were created by VisShare users and the other way would be to enable the RemotePublic flag.

This will allow the access to public projects via the link <server-url>/remote-public/<ID-of-the-public-project>. This setting should only be set to true if there really is a need for this kind of access.

3.User pools

The next layer of user access (or user separation) are the user pools. Administrators are allowed to create these and map user accounts to them.

User accounts are only allowed to see (e.g. during the mapping of users to a new project) other users that are in one of their user pools and a project must be mapped to a user pool to enforce a separation of users per project.

User pools do not limit the access to the projects or files, this must be done on project level itself, they are solely used to limit the visible users for normal accounts.

4.Project access

The project access should be seen as the main feature to limit the access to the important data (the files). These access rules are applied at the project level and will be inherited down to all files and folders inside the project.

Projects can be set to one of the following types:

Additionally, every project has different kinds of user roles for the users that can access the project:

5. Account roles

There are three roles a user account can have:

There are additional settings to limit features (such as the download) on the VisShare, please refer to the Admin Settings Documentation for a complete list.

CSP and Other HTTP Header

It is recommended to set some HTTP header to improve the security.

These headers need to be set either on the Proxy Server or in the index.html (installation folder/www):

The Proxy headers have not much impact on the execution of the VisShare service and are therefore implemented in the default Nginx configuration. If a different proxy is used, it is recommended to enable at least the following headers in the proxy configuration:

▪Content-Security-Policy: "frame-ancestors 'self';"

▪Access-Control-Allow-Origin: <VisShare FQN>

The headers set in the client index.html may have some impact on the execution of the VisShare service and are therefore only described here and should be tested further before deploying them to the live installation.

Moreover, a dynamic hash has to be generated for every release version. This header can be taken from the browser development tools after loading the VisShare in the browser (it will be logged as a missing hash in the console tab).

Following header should be written in a meta tag in the index.html:

▪Content-Security-Policy:

▪default-src: 'none'

▪style-src: 'self' 'unsafe-inline'

▪script-src: <version depending SHA hash>

▪img-src: 'self' data:

▪font-src 'self'

▪script-src-elem: 'self' <version depending SHA hash>

▪object-src: 'none'

▪connect-src: 'self'

▪form-action: 'self'

▪base-uri: 'self'

▪worker-src: blob:

▪block-all-mixed-content

For example like this: