Security guidelines

This document give some guidelines on how to improve security of your applications based on the Simplicité® platform.

Securing application endpoints

Introduction

There are 4 endpoints available on Simplicité® platform:

All of them are secured either by the standard authentication mechanisms (Java server's realm / JaaS/Jaspic modules, OAuth2/OpenIDConnect or SAML flows) you configure except the public features that you choose to expose on the UI endpoint's public components (see bellow)

Locally stored password must be encrypted/hashed (see the HASH_PASSWORD system parameter) accordingly to your local authentication configuration.

Note: When possible, using an external authentication mechanism is always a better and more secure approach than using loally stored passwords.

In particular the designer user's password must be hard to guess (this is also applicable to any user granted with advanced rights).

UI endpoint

The UI endpoint has some public (non authenticated) components that may be used for the purpose of explicitly exposing some features publicly. A particular attention must be put on what is granted to the public user (through its default PUBLC group or any other group that you grant him)

API endpoint

If you don't use the API endpoint you should disable it by setting the private system parameter USE_API to no. For more information on default API authentication mechanisms, see the IO command-line doc.

I/O endpoint

If you don't use the I/O endpoint you should disable it by setting the private system parameter USE_IO to no. For more information defaut on I/O authentication mechanisms, see the IO command-line doc.

Git endpoint

If you don't use the Git endpoint you should disable it by setting the private system parameter USE_GIT to no.

Note: for backward compatibility reasons (and for particular cases) the I/O and Git endpoints also use the legacy authentication method bases on private system parameters names EAI *. If you have no good reason to keep it, this authentication method should be inhibited by removing the corresponding system parammeters.

Securing your configuration and your specific code

Public rights

Be careful on what you grant to the public user (typicaly through the PUBLIC group or by additional resposnsibilities associated to this user) because everything granted to this user is made available on the public UI components

Private system parameters

Be sure to configure as Private type all system parameters that holds confidential data that you don't want to be available elsewhere than on the server side (e.g. services credentials, passwords, ...)

Business object filtering

If you have a business object with dynamic filtering rules (e.g. implemented in the postLoad hook based on rules on user's responsibilities and/or business obejct instance name), you should set 1=2 as default static filtering rule. As a metter of fact, if for any reason you code is not working well it will result in giving no access to any data instead of giving access to all data.

Forbidden fields

A invisible business object field is still visible if you inspect the HTML of the UI and is still available on the API calls. To be sure a field is only usable on the server side you must mark it Forbidden.

As above for filtering, if a field's visibility is dynamically set by code, be sure to configure it as Forbidden in your static configuration. If for any reason your code does not work the field will remain by default not avialable.

Cross site scripting vulnearbility

If you write a custom web page (e.g. via an external object) make sure to take into account the risk of cross site scripting vulnerabilities (passing <script> or <svg> with script in a HTTP parameter). Basic protection is to systematically display values got from HTTP parameter using Tool.toHTML/toJS/toSQL.

Low level tools

System users (such as designer) have access by default to low level tools on the generic UI (database and dbdoc browsers). These tools are standard external objects they should be inhibited by removing grants on them if you don't use them.

Data encryption

Use built-in (see the Data Encryption part in code examples) or third party data encryption especially when the database access is not limited to the application.

Securing your infrastructure

Introduction

Simplicité® platform run on a server infrastructure. You must secure it properly by:

Simplicité® has no particular requirement at this level, all usual good practices in securing server infrastructure applies.

Use SSL

Your application endpoints should always be exposed as HTTPS (SSL). This can be achieved directy in the Java application server that runs Simplicité® or at the reverse proxy level (if you have configured one).

SSH Access

The server infrastucture command line access should always use SSH (ideally key-based) authentication (and the keys should be secured by a robust passphrase).

System updates

Note the warranty is void on a non up-to-date platform, keeping your Simplicité® platform up-to-date is not just recommended it is mandatory.

Simplicité® Instance Manager (SIM)

These are specific guidelines for the Simplicité Instances Manager (SIM). See this document for details on the SIM.

SIM credentials

You must use strong password for your SIM users passwords (for UI and API access). Better, use SSL client certificates for authentication. When connecting over SSH, use only secured SSH keys.

Terminal access

Don't enable the web-based terminal access (ShellInABox) unless you do need it (keeping in mind it is a rather insecure feature).