AllView security basics

Isolation of a customer's data in a hosting scenario

We call it licensedata, the data that users produce over time, owned by the licensee. (which in turn is most often the user's employing organization)

A set of licensedata can be stored as the only set of licensedata in a database, and the database may be installed on a computer without concurrent databases. That is, the licensee is the only company storing data on the computer. This approach has always been safe with "old style" applications, errors cannot cause systems to mix different companies' data.

Unfortunately, the "old approach" has been quite expensive, specially with Internet hosting, a quite unneccessarily high cost as you will read in the following. Our AllView products has a neat and cost/benefit effective design, with extreme safety built in.

License dataspace separation

AllView makes it possible for one single AllStore database to keep the data for several licenses, or companies. The rationale behind this is to enable a single database server or cluster to host the data for several licenses, thus keeping the cost of hosting AllView products such as ShipView low. This document explains how the system ensures that the data of two different licenses are never mixed, and that a user of one license can never see any data from another license unless explicitly permitted by an administrator of the other license.

The 2-layer storage security

2-layer security is accomplished by hierarchy and enitity isolation.

Hierarchy isolation

The license ID uniquely stored with your user login starts the hierarcy of the license datastore. The hierarchies of other dataspaces within the same datastore cannot be mixed, neither intentionally nor accidentally.

Enitity isolation

The smallest data storage entities in relational databases, the table records, are all by design tagged with the globally unique ID number of your license.

Login

All access to an AllView-system like ShipView is through a secure login screen. When a user logs on to the system, the user's session is given a secure token that holds the license id that the user belongs to. This token is passed to the system for every subsequent request, and if the token expires (which it does after a configured time) or is lost (for instance if the browser is closed) the user must log on again in order to access any data. The system redirects all requests that do not contain the secure token back to the login screen.

Data access

First, the only access to system data is through an application server that resides behind a firewall. After logging in, the user is allowed to select objects through the application's navigation system, and the available objects are restricted to the license in the secure token passed with the request. This restriction is carefully programmed and tested in the user interface and business layer, and can not be easily bypassed even by a skilled "hacker". But as yet another line of defense, all access to data in the database passes through a business layer that builds on a set of generated data access classes. For all the database tables that contain user data (i.e. licensed data as opposed to system tables like lists of country codes, currency types etc.) the system only allows access to clients that pass the secure token created during login. And, crucially, since the token contains the user's license id, the system can restrict access to data that is owned by the license that the user belongs to.