Securing Matillion ETL
By default Matillion ETL users are authenticated against an internal user file however it is possible to authenticate users against an Active Directory or other LDAP directory server, turn on and off SSL including certificate management and add and remove users from the local directory using the Administration application.
Since version 1.21.5 security is administered from the administration application. Please see Administering Matillion ETL for more details.
The below documentation is legacy for older versions, for reference and troubleshooting.
Matillion ETL is delivered with security defined, but not enabled. This is to allow you to configure the application against several different authentication providers from a local file to Active Directory integration.
There are three tasks to configure in order to secure the application, described below. Authentication and Authorization go hand-in-hand and need to be done together. SSL is optional, but is recommended if passwords will be transferred over an non-secured network between the user's browser and the Matillion ETL server.
Authorization is based upon a user being in the Emerald role.
Simply edit the file /usr/share/emerald/WEB-INF/security.fragment and remove the two lines:
<!-- BEGIN SECURITY CONSTRAINTS >
< END SECURITY CONSTRAINTS →
Note: If you would like to use a role name other than Emerald, change all instances of that name inside the <role-name> tags to your preferred name. This is usually only worthwhile if you are integrating with an existing authentication provider - see the next section.
In order for your users to be authenticated with a username and password, you need to configure tomcat.
If you have enabled Authorization above, by default usernames and passwords are stored in the file /etc/tomcat8/tomcat-users.xml. You can add a role and some users to this file to get started, for example:
<?xml version='1.0' encoding='utf-8'?>
<user name="admin" password="admin" roles="Emerald"/>
<user name="email@example.com" password="mypassword" roles="Emerald"/>
The file above is used by the UserDatabaseRealm. For more advanced configuration, you can use an alternative Realm configuration, and there are many available. See http://tomcat.apache.org/tomcat-8.0-doc/realm-howto.html for details. The example below is a typical Active Directory domain configuration.
- connectionName - the fully qualified name of a user who can bind to and search the directory. Please contact your directory administrator.
- connectionPassword - the password for the above.
- connectionURL - the URL to your directory server.
- userBase - The subtree below which users are stored in the directory tree.
- userSearch - The LDAP attribute to use for identifying users.
- roleBase - The subtree below which groups are stored in the directory tree.
- roleName - The LDAP attribute used to identify a group or role
- roleSearch - The LDAP attribute to use to identify groups or roles
Enable SSL (optional)
Matillion ETL comes configured with a self-signed SSL certificate, which means that if you enable SSL web browsers will typically display a warning page. If you accept that warning however, all communication between the browser and the server will be encrypted.
In order to turn on SSL, use SSH to access the server running Matillion ETL, and edit the file /etc/tomcat8/server.xml with your favourite text editor. You will need root privileges to do this, so use sudo.
Comment out the default (non secure) connector listening on port 8080, so it looks like this:
<Connector port="8080" protocol="HTTP/1.1"
Un-comment the SSL connector that is already configured but was previously commented out:
<Connector port="8443" protocol="HTTP/1.1"
maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
Note: Ensure the protocol is HTTP/1.1 and not org.apache.coyote.http11.Http11NioProtocol!
To implement a fully working certificate you will need to generate an SSL certificate. This will be used to verify the host name that Matillion ETL will be accessed via. You will need to you generate or reuse your own organisation's certificates and create entries in your organisation's DNS servers.