Skip to main content

Common requirements

The requirements described on this page are dependencies of the QuickCase software. They are relevant and must be considered regardless of the platform selected as the target for the deployment. Additional requirements may be requested in the platform-specific part of the documentation.

The requirements are:

PostgreSQL databases​

QuickCase uses relational databases to store all of its structured non-binary data. At a high-level, 2 types of data are stored:

  • Definition data: Client-specific configuration of QuickCase including schemas, workflows, layouts and permissions.
  • Case data: Current and historical data of all the cases recorded, as per defined schemas.

For QuickCase Self-Hosted deployment, the databases are not provided as part of the software. Instead, they must be provisioned separately and passed to QuickCase via configuration.

note

Keeping the databases separate from QuickCase software ensures that you stay in control of your data and that you can use the most suitable database offering provided by your Cloud provider.

Vendor​

QuickCase relies on PostgreSQL-native features such as the jsonb data type and the associated JSON functions and operators. As a consequence, PostgreSQL is the only relational database which can be used to store QuickCase data.

Version​

QuickCase commitment is to support the 3 latest major versions of PostgreSQL, in accordance with PostgreSQL versioning policy.

At this time, QuickCase officially supports the following major versions of PostgreSQL:

  • 11
  • 12
  • 13

Instances​

Single database deployment​

As a minimum, a single instance of a PostgreSQL database is required. With that approach, both definition and case data will be co-located.

caution

While that configuration may be suitable to reduce costs in lower/test environments, it is not recommended for live environments. Instead, a split databases deployment should be preferred.

Split databases deployment​

With that approach, distinct database instances are used to store definition and case data.

This is the recommended configuration for live environments as this allows for more accurate management of the database resources as well as backup and retention policies.

Database resources profiles​

To help you profile and size the resources required by your database, it is useful to know how the database will be used.

Definition data​
  • Volume of data is not correlated with user activity: Volume of data stored is independent of user activity, it only increases when definitions are updated
  • Database load is not strongly correlated with user activity: Definition data is static and cached, user activity has little impact on database load
Case data​
  • Volume of data is strongly correlated with user activity: Volume of data grows with user activity: more cases created or progressed means more data needs to be stored
  • Database load is strongly correlated with user activity: Both read and write operations on cases add to the database load, the most expensive operations are search queries

Schema management​

QuickCase uses Liquibase to self-manage its database schema. As such, it needs only to be given empty databases and it will take of creating the types, tables and indexes it needs to operate. Same applies for updates, when QuickCase is updated any schema change required will be automatically applied as part of the software deployment.

Permissions​

Because QuickCase is managing its own schema, it not only needs privileges to read/write in existing objects (DML) but also permissions to create, alter and drop objects (DDL).

Required DDL privileges​

  • CONNECT
  • CREATE: On schema, to create new objects within the schema

Permissions to alter and drop objects within the schema are implicitly inherited from the ownership of the objects.

Required DML privileges​

  • SELECT
  • INSERT
  • UPDATE
  • DELETE

OpenID Connect provider​

Identity and access management (IDAM), the ability to authenticate and authorise users, is a cornerstone of any IT portfolio. Often, companies already have established policies and infrastructures satisfying their needs and security requirements regarding authentication of end-users. As such, QuickCase is designed to leverage your existing IDAM solution by integrating directly with it using the OpenID Connect standard.

OpenID Connect is an authentication protocol that has been widely accepted as an industry standard and is now supported by most identity providers on the market. If your existing identity provider supports OpenID Connect, then it can act as the OpenID Connect provider for QuickCase which will ensure:

  • Enforcement of existing security requirements when authenticating to QuickCase (MFA, password policy)
  • No duplication of user accounts
  • Single Sign-On

Alternatively, if you do not have an OpenID-compatible identity provider or if you have requirements which makes it not suitable, then you will need to provision a dedicated OpenID Connect provider for QuickCase to use.

Requirements​

While QuickCase endeavours to be compatible with all OpenID Connect providers, it currently requires the following minimum specifications to successfully integrate:

  • Non-opaque, JWT access token with scope claim
  • JSON Web Key Set (JWKS) exposed by a public URL, used to verify access and ID tokens
  • User Info endpoint
  • Support for custom, private user claims exposed in both ID token and User Info endpoint

Tested providers​

In theory, any OpenID Connect provider complying to the requirements previously listed should be compatible with QuickCase.

In practice, to date the following providers have been successfully used with QuickCase:

Public user claims​

QuickCase uses public OpenID Connect claims to record the identity of users as part of its internal audit.

The following public claims are consumed:

  • sub: required, unique user identifier, usually a UUID
  • name: name of the user, defaults to sub if not provided
  • email: email address of the user, left blank if not provided
Custom claim names

If needed, the names of the public user claims consumed by QuickCase can be modified through configuration. Please refer to the detailed QuickCase configuration for the platform of your choice to learn how.

Private user claims​

QuickCase relies on each users having private claims exposed through OpenID Connect by the identity provider as part of both the ID token and the User Info endpoint. These claims are required for QuickCase to enforce access control when reading or progressing cases.

Roles​

  • Name: app.quickcase.claims/roles
  • Required: Yes
  • Type: String, comma-separated
  • Example value: role-1,role-2,role-3

Comma-separated list of user roles used by QuickCase to enforce role-based ACLs.

Organisations​

  • Name: app.quickcase.claims/organisations
  • Required: Yes
  • Type: JSON string

A JSON object containing the one or many organisations a user is granted access to. For each organisation identifier is defined:

  • access: one of individual (default), group or organisation
  • classification: one of public (default), private or restricted
  • group: optional string, group identifier, only required if access is group

For example, given 2 organisations 'org-1' and 'org-2':

{
  "org-1": {"access": "organisation", "classification": "private"},
  "org-2": {"access": "group", "classification": "public", "group": "group-1"}
}
Custom claim names

QuickCase-specific private claims are namespaced with app.quickcase.claims/ to ensure uniqueness and avoid conflicts. However, in some OIDC providers this can lead to claim names exceeding the maximum authorised length. Additionally, some OIDC providers also mandate prefixes such as custom: in front of private claim names.

In any such case, QuickCase allows for custom claim names to be defined through configuration. Please refer to the detailed QuickCase configuration for the platform of your choice to learn how.

As a best practice, some form of namespace should be retained for private claim names. Shorter alternatives to the namespace includes quickcase/ and qc/.

Blob storage provider​

QuickCase uses external blob stores to store binary attachments such as images or PDF files.

Optional requirement

If you are not planning on storing attachments, then this requirement can be ignored.

QuickCase relies on the use of pre-signed URLs to grant time-limited permissions to upload or download attachments. This approach strikes a balance where QuickCase strong, configurable security model remains in full control of attachments permissions while leveraging efficient cloud storage services provided as a service. Like for PostgreSQL databases, this also ensure you remain fully in control of your data as it is stored in a dedicated infrastructure that you control.

The following blob stores are currently supported:

Amazon S3​

With Amazon S3, attachments are stored in a S3 bucket. Access control is enforced by QuickCase using permissions described by the definitions and object metadata stored in S3. Upload and download of attachments is done directly from the user's web browser using presigned URLs.

Azure Blob Storage​

With Azure, attachments are stored in an Azure Blob Storage container. Access control is enforced by QuickCase using permissions described by the definitions and blob metadata stored in Azure Blob Storage. Upload and download of attachments is done directly from the user's web browser using Shared Access Signatures.

Google Cloud Storage​

With Google Cloud, attachments are stored in a Storage bucket. Access control is enforced by QuickCase using permissions described by the definitions and blob metadata stored in Google Cloud Storage. Upload and download of attachments is done directly from the user's web browser using signed URLs.

Configuration

Time-to-live of upload/download URLs as well as provider-specific settings can be define through configuration. Please refer to the detailed QuickCase configuration for the platform of your choice to learn how.