Application Security

Authentication

Important

Toucan Toco can authenticate users in two manners:
  • using its own list of accounts
  • leveraging the SSO (Single Sign On) of your organization

The second one needs your SSO to respect the SAML2 standard.

Local Accounts

Toucan Toco has its own database of users. Basic administrative and viewer accounts are provided when the server is installed.

For each of our clients, Toucan Toco uses a dedicated database, which ensures that no user account is shared across our different customers.

Local Password Storage

Toucan Toco server never stores the password in plain text! We use the PBDFK2 algorithm to hash them, which consists of a thousand iterations of a salted SHA2.

Local Password Policy

We force users to respect the following rules when creating or modifying their passwords:

  • a password’s length must be more than 8 characters
  • a password mustn’t contain a user’s login
  • a password mustn’t be in a list of basic keywords (based on the list of the worst passwords, e.g. 1233456789 or quertyuiop)

Anti-bruteforce Mechanism

We use crowdsec to prevent SSH or HTTP brute-force attacks on all our servers. When a malicious IP address is detected, a ban is applied all over our infrastructure.

We have further mechanisms in our infrastructure to prevent denial of service attacks.

Administrative Account

We provide an administrative account that has access to a panel allowing:

  • review of the authorized accounts and their privileges
  • deletion of accounts
  • modification of accounts

We enforce reinforced password security for these accounts with the following rules on top of the basic policy:

  • 12 characters minimum
  • a mix of lowercase or uppercase letters, special characters and digits

Single Sign On (SSO)

Toucan Toco can act as a Service Provider, allowing users to connect using your Identity Provider.

We support the standard SAML2. Specific connectors to other authentication systems could be developed and therefore purchased separately.

SAML 2.0 Web Browser SSO

SAML 2.0 Web Browser SSO

We need the following configuration fields to be able to use your IdP:

  • entityId
  • singleSignOnService url
  • x509cert

We’ll then provide a metadata XML file or a URL with the information to be whitelisted in your IdP.

Session Management

The backend exposes its endpoints following the REST conventions, meaning it’s stateless. The frontend (consuming the API) therefore sends its authentication token at each request for validation.

Authentication Tokens

We provide an endpoint to generate these tokens when a user logs in.

Tokens are JSON Web Tokens. They replace the session information usually stored in cookies.

The token is signed server-side using the HMAC-SHA256 algorithm with a highly secured secret of 40 characters. This secret is specific for each of our clients. This ensures that if the secret of one of our clients is compromised, the rest of our clients remain safe.

This token is valid for 30 days by default, at the end of which users must enter their credentials again. This is particularly adapted to mobile and tablet use. This duration can be modified if requested to match other security policies.

Access Control

Permissions are defined by user group, per small-app. These permissions act like masks on the data rows available in the small-app: it’s a query that will be executed along with each query that users execute:

Example: If user group ‘A’ has the permission:

permissions:
  data:
    entity: 'A'

and a user belonging to that group tries to execute the following query:

query:
  domain: 'my_data'

the resulting query will be:

query:
  $and: [
    domain: 'my_data'
  ,
    entity: 'A'
  ]

If a user belongs to multiple user groups, the masks are joined by an $or operator, meaning that they can query the union of data available to these groups.

Example: if the previous user also belongs to a user group ‘B’, the resulting query will be:

query:
  $and: [
    domain: 'my_data'
  ,
    $or: [
      entity: 'A'
    ,
      entity: 'B'
    ]
  ]

Log Events

Every user’s actions on the Toucan Toco application are logged such as:

  • loading of new data
  • processing of data
  • releasing new versions of data to users
  • successful and failed login attempts

Logs are available in JSON format and stamped with the date and time.

Persistent Storage Segmentation

Toucan’s server stores its objects in MongoDB. It uses:

  • a database for users and small-apps list
  • a database for each small-app to store its configuration, styles, etc.

The server needs to be authenticated by MongoDB with the readWriteAnyDatabase role.

Each of our clients have a dedicated MongoDB instance for the storage of their small-apps. See the DB infrastructure description for further information.