Offline Client - Setup and configuration

Publish

When setting up Offline publication, the publication will create a database based on the settings in server.config. The publisher will create a database with the same version as the instance in the settings file.

<SqlServerDatabaseSettings> <PublishToSqlServerLogin> <UseSqlServerUser>false</UseSqlServerUser> <SqlServerUser>Assert#User</SqlServerUser> <SqlServerPassword>Login#123!@$</SqlServerPassword> </PublishToSqlServerLogin> <PublishToInstanceName>MATTIAS-LAPTOP\SQLEXPRESS01</PublishToInstanceName> </SqlServerDatabaseSettings>

Profiling

When the Manger (in standalone mode) or the server (in SE mode) is installed, Offline Viewer is stored in a folder in a profile: C:\ProgramData\Signifikant\Assert\AnyTime.

Among other thing, it contains a profile information in folder: C:\ProgramData\Signifikant\Assert\AnyTime\Components\Profile.

Review the content of this folder, since it will be copied to Offline Viewer application data folder after the end user has installed the application. Target folder is: C:\ProgramData\Signifikant\Assert AnyTime\WWWRoot\App_Data.

Normally, WebViewer has several profiles available, for the server and for each connected site. With Offline Viewer, a simplification is made, providing one profile for the server (application) level. Regardless of the number of sites connected, the one and same profile is used for all sites. Normally this is not an issue since the installation will contain and refer a single site; the DVD publication created in the manager database. But technically, more than one site may be present in an offline installation package and all are potentially installed with the Offline Viewer installation application.

Common profile settings

The App_Data folder contains files read by the application to provide details of the customer profile; functions in JavaScript, images and style sheets. The profile.config file is the definition file where the profile is declared, referencing other profile files as well. Examples of profile files:

  • profile.config file: entry point for application profile definitions

  • customer CSS file: style sheet for the web application

  • customer JavaScript file: event handlers etc. contributing to web application functions

  • site logotype file: it will present on all web pages

  • custom-text.config file: custom translations and text definitions

  • settings.config: declare, i.e., default site

Note!

Note that browser built in PDF viewer is not functioning very well in Offline client. To avoid these problems, make sure to use pdf.js as PDF viewer and disable browser built in reader. This is done by setting the following properties:

<DefaultPdfJsReader>true</DefaultPdfJsReader> <BrowserPdfReaderEnabled>true</BrowserPdfReaderEnabled>

Synchronization

Note!

Offline synchronization should also be enabled in C:\inetpub\wwwroot\AssertWeb\App_Data\settings.config

<OfflineViewSynchronizationEnabled>true</OfflineViewSynchronizationEnabled>

Synchronization settings with credentials

If it is needed for end clients to enter username and password to start synchronization, this will have to be configured for the function to work properly. Two settings need to be applied: a resource permission and an authentication provider.

A resource permission “Synchronize” is needed to define which user groups shall have access to the sync function. A sample permission setting is:

Anytime will need to know how users trying to sync shall be authenticated. If Assert's authentication is used, an authentication provider needs to be defined. Note that this authentication provider is valid for the server and not for a site. This setting need to be placed in the profile.config.

Synchronization settings without credentials

If end clients shall not have to enter username and password to start synchronization, this will have to be configured for the function to work properly. In this case, profile.config of the sync site will have to include a NullAuthenticationProvider which allows users to sync without credentials.

Synchronization Authentication

Since the Synchronize API is in version 2, it now relies entirely on authentication tokens to authorize clients. In this case, JSON Web Tokens are used since it is a popular and well-adopted standard.

Version 2 also comes with the possibility to use X509 certificates for authentication. But, regardless whether basic authentication or certificate-based authentication is used, the underlying security layer relies on JSON Web Tokens.

 

1. Server setup: JSON Web Token

On the server, the JSON Web Token settings need to be configured. This is achieved in the settings.config file, and the following snippet needs to be added:

There are four important settings in <JsonWebTokenSettings>:

  • Issuer: The name for the entity which is responsible for issuing and validating tokens (unique name, ex: hostname)

  • Audience: Name of the entity by which the token is intended to be used. (unique name, ex: hostname)

  • DurationInMinutes: How long a token is considered valid. After it has expired, the client will need to authenticate again. This is done seamlessly in the background and requires no user interaction.

  • Secret: A Base64 randomly generated string. A length of 128 bytes is recommended. Make sure this is kept secret!

 

2. Server setup: Certificate-based authentication

In case certificate-based authentication is intended to be used on the synchronization server, you will have to set up the server so that it is able to validate user certificates.

To do so, the server must add the Root Certificate Authority responsible for issuing user certificates to its list of trusted authorities:

  1. Download the certificate of the Root CA. Either check with your certificate provider or get the service URLs from the user certificate.

  2. Install the Root CA on the server. You will likely be asked where to install the certificate, make sure to choose Local Machine and NOT Current User (Reason: IIS has its own current user and will not see the certificate if installed in the user store). For the location, pick “Trusted Root Certificate Authorities”.

  3. Double check that you got the right certificate and that you installed it at the right location

 

3. Client setup: Certificate-based authentication

The client does not need to be configured when it comes to JSON Web Tokens, but it needs to be configured if certificate-based authentication is intended to be used.

To do so, please add the following settings in anytime.setup.config:

Let’s go over the four different settings:

  • CertificateEnabled: If true, the configured certificate will be used for authentication, otherwise, it will use the default basic authentication method (username/password)

  • CertificateStoreName: Specific value used to find the certificate on the user’s machine. If it’s a personal certificate, then the store name will be “My”.

  • CertificateStoreLocation: This is also used to find the certificate. In case of a user certificate, the location will be “CurrentUser”.

  • CertificateIssuer: The Certificate Authority (CA) responsible for issuing the certificate.

Silent Installation

For customers who do not wish to do any kind of customization when installing, it is possible to skip the installation mode popup by adding the following setting in anytime.setup.config:

Windows programs list registration

It is possible to customize how the Offline Client appears in the Windows programs list. This can be achieved by configuring the <ProgramEntryDefinition> setting in anytime.setup.config. Below is an example of how it looks like for KLA:

Customization

When an offline publication is created, Manager will look in this folder to fetch the customizations to use in the offline installation package that is created by the offline publication process.

C:\ProgramData\Signifikant\Assert\AnyTime\Components\Customize

Currently, Assert Anytime customizations will have to be configured by Signifikant.