Securing iDempiere

From iDempiere en
Jump to navigation Jump to search

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


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


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

VPN (openvpn, cisco)

iDempiere Services on web



felix console

cxf webservices

rest webservices

There are webservices here that returns the database password



other external extensions (mobile)

server operating system (linux, windows, mac)

openssl to generate client certificates

idempiere-server folder

You must protect and some other files containing the database password, by default usually it have read permission from everybody

swing client

swing client is insecure, 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

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 do anything over the database, just install trusted reports

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


dba user

iDempiere configuration


  • configure access not menus (menus don't restrict access - user still can zoom)
  • db access (tables, columns)
  • private records
  • record access

org access

menu access (note zoom still allows user to navigate)

db access (table, column)

private record & record access


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


sensitive fields (like passwords)

hashed passwords


password rules

user locking

tracing possible attacks

Every trial to login with a wrong password is recorded in the file AuthFailure.log

external tools to deny service on attacks

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

initial steps

  • change encryption key
  • hash passwords (if not using hashed passwords, then encrypt AD_User.Password and AD_Password_History.Password)
  • encrypt all columns containing passwords (not required for AD_User.Password and AD_Password_History.Password if using hashed passwords)
  • setup password rules
  • change default passwords for SuperUser, System, GardenAdmin and GardenUser
  • change default passwords after creating a new client (in Initial Client Setup can select not to assign passwords by default for better security)