Seed Contributor: Carlos Ruiz - GlobalQSS - please feel free to improve.

2015 Conference Talk

During the 2015 iDempiere conference there was a presentation from Carlos about security, you can find the video of this talk at https://www.youtube.com/watch?v=mhjA1B4PHFs

Initial Steps

See below for more detailed explanation of each of these steps:

When coming from an old version take a look to the Migration Notes
Install an http server to be used a proxy for iDempiere - most used are nginx or apache. See Proxy iDempiere Through Nginx
- Configure your proxy to publish just /webui - iDempiere by default has several other services published, and some publishing security-sensitive information (like DB password)
- if you plan to use webservices externally you must publish also /ADInterface
- if you plan to use REST webservices externally you would need to publish also /api/v1, however, in this case is recommended to use an API gateway, like the example provided with Krakend
Close ports on your server using a firewall, it's recommended to open just port https/443, and maybe in a protected way the other ports you may need for administration (i.e. ssh/22)
Another usual option is to install your server behind a VPN
Change the default passwords for the 5 default users (SuperUser / System / GardenAdmin / GardenUser / WebService)
Enable hashed passwords
change encryption key
- if not using hashed passwords (not recommended), then encrypt AD_User.Password and AD_Password_History.Password
setup password rules
encrypt all columns containing passwords (not required for AD_User.Password and AD_Password_History.Password if using hashed passwords)
change default passwords after creating a new tenant (in Initial Tenant Setup can select not to assign passwords by default for better security)
SysConfig ZK_ROOT_FOLDER_BROWSER
configure the following System Configurator keys in System, this is to avoid disclosing unnecessarily technical information of the server:
- APPLICATION_DATABASE_VERSION_SHOWN=N
- APPLICATION_JVM_VERSION_SHOWN=N
- APPLICATION_MAIN_VERSION_SHOWN=N
- APPLICATION_OS_INFO_SHOWN=N

Browsers (chrome, firefox, safari, ie, opera)

https

Don't use http, always use SSL encrypted https

client certificates

You can provide client certificates to your users to restrict who can connect

Proxy Web Server (nginx, apache)

Set up a proxy web server and publish JUST the services required by the users, most of the times is just webui.

recommended way to set up a proxy

See for example Proxy iDempiere Through Nginx, and for apache you can check mail thread

VPN (openvpn, cisco)

Some companies run iDempiere behind a VPN, that makes it more secure, and in this case sometimes companies don't care about DNS or proxy with nginx.

iDempiere Services on Web

zkwebui

This is the UI front-end that users needs access, so it's OK to proxy and publish.

idempiereMonitor

This is a website intended for administrative and monitoring tasks, is better to hide it from public access, via the proxy or via just VPN.

Felix Console

This is another website intended for administrative tasks, like start/stop plugins, is better to hide it from public access, via the proxy or via just VPN.

REST WebServices

There is a widely used REST plugin that enables REST WebServices on top of iDempiere, opening this publicly is not recommended as it is too powerful, the REST WebServices depends on the role and user configuration and it can do ad-hoc queries and CRUD operations and all the tables that have access.

The recommended approach to expose REST WebServices is using an API gateway in the middle. There is an example provided in the page Proxy iDempiere-Rest Through KrakenD

CXF WebServices

If you plan to expose the SOAP/XML webservice layer, it is recommended to configure carefully their security layer, check Web Services Security for more information.

old deprecated rest webservices

Old versions of iDempiere can have some REST webservices that returned the database password, these webservices were dropped after version 7.1

WebStore

There is an external plugin that provides a webstore, available at https://github.com/idempiere/idempiere-webstore

This webstore uses old technology and is mostly unmaintained, if you plan to expose it in production please review carefully the security impact.

Fitnesse

This is an external plugin and webserver provided for conducting test scenarios, it is available at https://github.com/idempiere/idempiere-fitnesse

It is intended for usage in test servers, not for production.

Other external extensions (mobile)

There are plugins that publish also other services, like the deprecated ADAXA_Mobile or the BX Service Vaadin Mobile.

As with every external piece of code, it is recommended to do a security check and audit to use them in production.

Server Operating System (Linux, Windows, Mac)

Linux

NEVER install iDempiere with root, this is a common advice for any software that exposes services to the internet. If somebody - for any reason - could exploit iDempiere to gain access to the operating system, they'll have the permissions from the user that runs iDempiere, so if you run it with root, they'll have complete access to the server. For the same reason it is recommended that you consider carefully which permissions and access to give to the operating system user that is running iDempiere.

Windows

Many developers use iDempiere in Windows for development, but very few people run iDempiere in production using Windows, some of the support scripts (f.e. applying migration scripts) are just developed for Linux, so you would need to do some tasks manually.

Linux is the preferred option.

openssl to generate client certificates

nginx, apache can be configured to allow access to clients that are authenticated with a client certificate

idempiere-server folder

You must protect the files idempiereEnv.properties, idempiere.properties and .idpass and some other files containing the database password.

in windows by default usually it has read permission from everybody
in linux the file is protected by default and the password is obfuscated using base64
- There is a provision to customize the way to obfuscate/encrypt the password, or externalize it (avoid to save it on the server). Note externalizing the password protect against physical access (like stolen hard drive), but these passwords CANNOT be protected against a hacker accessing the live server, unless you sacrifice the ability to automate many things requiring manual intervention from an operator to provide some credentials.

swing client (deprecated)

the swing client is deprecated because it is insecure, it is not recommended

database password encrypted in properties file

The database password on swing client is "encrypted" in a properties file, the problem is that the encryption algorithm is usually common and easy to decrypt, and even if you change it can be easily extracted from the jar files. There is the possibility of implementing alternative keys, algorithm or even classes to encrypt better the strings.

terminal server approach (nx, citrix, ts)

if definitely you are needing to use swing client is better to use it via a terminal server where you have control of the machines

jasper reports

Be careful, jasper can read anything over the database, just install trusted reports.
Consider including in your jasper queries the security layer of iDempiere, like is included by MRole.addAccessSQL, like:
- Restrict the query to the running tenant, this is adding WHERE AD_Client_ID=...
- Restrict to the organizations the user has access to
- Take into account AD_Private_Access and AD_Record_Access

external tools

If you need to give direct SQL access to other tools like jasper, odbc/jdbc connections to libreoffice, datawarehouses, ETL, talend, etc - better consider creating a read-only user with access to preconfigured views. The views can contain the security filter for AD_Client_ID

database

iDempiere supports postgresql and oracle. Most implementations run on postgresql, however oracle support is good and permanently maintained.

dba user

By default the installers create a database user (usually named adempiere) with complete DBA/SUPERUSER permissions, this is, this user have ability to do everything on your database. It is possible to install iDempiere with a less powerful user, but you need to configure it manually

iDempiere configuration

New Tenant

When creating a new tenant, by default iDempiere assign a weak password which is the same as the user name. It is recommended better to disable the flag "Set Initial Password" and assign secure passwords to the new users manually after the tenant is created.

roles

it is recommended to configure the security using access, not menus (menus don't restrict access - user still can zoom)

org access

You can configure organization access in the role window.

menu access

You can configure specific menus for roles, however it is important to note that the menu is just visual, the users can still navigate to the windows they have permissions using the zoom function.

db access (table, column)

You can configure / restrict access for roles using the Role Data Access window

private record & record access

To configure record access you must use the "Lock" button on the toolbar. This button can make a record:

private: just visible for the user who locked it and the roles allowed to see locked records
restricted: just visible for certain roles

NOTE ON ADVANCED ROLES

The advanced roles are intended for IT on tenant side - do not give an advanced role to an end user. You must consider advanced roles as SuperUser, they have access to all security holes.

Also you must consider SuperUser as if it has access to the operating system user used to install iDempiere on the server.

In other words, the advanced roles have access to iDempiere features that can be easily exploited to gain access to SuperUser in the application, to the database as a DBA, and to the operating system as the user that run iDempiere server.

users

iDempiere comes with 5 users by default with very easy and insecure passwords. It is a mandatory first step to change these passwords on: SuperUser, System, GardenAdmin, GardenUser, WebService

sensitive fields (like passwords)

It is recommended to encrypt sensitive data, iDempiere has a mechanism to encrypt that can be easily enabled/disabled per column.

encryption

To encrypt data in the database, iDempiere uses an algorithm and a key that is exposed in the open source code. So, is not very secure.

In order to encrypt sensitive data - as recommended - it is better to configure a proper keystore, this can be achieved setting idempiere.ks and idempiere-ks.properties in the server. This was implemented with ticket IDEMPIERE-613. As of today, there is no documentation about how to use this feature, check the class DefaultKeyStore for more defaults about the implementation.

hashed passwords

It is absolutely recommended as one of the first steps of your installation to use the hashed passwords feature, you can find more information at NF1.0 HashedPasswords. These passwords are very secure as they are not encrypted, but hashed, so it can be seen as a one-way encryption, for example even if somebody obtain the hashed passwords with direct access to the database, they cannot go back and figure out the password.

password rules

It is recommended to setup a set of password rules for your users. You can find more information at NF1.0 PasswordRules

user locking

iDempiere provides features to manage automatic user locking on certain events. It is recommended to setup these features. You can find more information at NF1.0 User_Locking

ZK_ROOT_FOLDER_BROWSER

The SysConfig key ZK_ROOT_FOLDER_BROWSER defines the folder that is shown when clicking on a Folder type field.

As this folder can be exploited to get information from the server, it is recommended to set this SysConfig key to a secure folder in your server that does not contain any sensitive information.

Multi-factor Authentication

Since version 8.2.2021-06-09 iDempiere is able to manage Multi-factor Authentication on login time. Refer to Configure MFA for details about how to setup and use this feature.

You can trace MFA failures in the file AuthFailure.log, it is recommended to setup a mechanism to inform users when MFA failures happen, it can mean that their password was leaked.

tracing possible attacks

Every trial to login with a wrong password, or an MFA failure is recorded in the file AuthFailure.log

external tools to deny service on attacks

You can use tools like denyhosts or fail2ban to ban IP addresses that are testing passwords based on the AuthFailure.log file

Securing iDempiere