Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
For almost all services or APIs running in production, the requirement exists to secure access to the service. In the rest of this article, we will look at how to ensure the following security requirements:
- Authentication – Determine which individual/system is accessing the service. This involves comparing provided identity information with corresponding data stored about the individual in our system. The provided information is something only the individual can provide, for example, a password.
- Authorization – Ensure the individual can only access parts of the services she is allowed to use.
- Confidentiality – Ensure the information sent is kept secret. No surveillance by third-parties is possible. Usually, this is achieved by encrypting the information.
- Integrity – Confirm the information the service receives matches what was sent. No one is able to tamper with the information unnoticed. This may be achieved by signing the message, but encrypting the information also ensures no "man in the middle" modified the information.
This article shows you how to implement these concepts when running data services or Routes in the Talend Runtime. The focus is on the cloud runtime, but also applies to on-premises environments. Microservices are not handled in this article.
The attached security.zip file contains a Talend Studio v7.0 project with a sample service and Route to experiment with. It can be imported into any Talend Studio v7.x. In addition, it contains sample configuration files for the LDAP login module described later.
Authentication
For REST-based services, in a cloud environment, Talend provides support only for basic authentication, where the user name and password are sent in an HTTP header alongside the request in clear text. Therefore it is mandatory to use HTTPS instead of HTTP as the protocol to ensure that the password is encrypted. Contrary to on-premises, for cloud environments, SAML token and OAuth are not supported. If more sophisticated solutions are required, Talend recommends using an API Gateway to secure and control access to the services and APIs. Talend Help provides information on how to integrate with API Gateways and examples for deployment on AWS API Gateway and Azure API Management.
Enabling authentication for services and Routes
Activating basic authentication for a service or a Route is done in Talend Studio in the corresponding REST component (tRESTRequest in a data service, or cREST in a Route). A data service where authentication is enabled is shown below:
Figure 1: Authentication enabled data service
Validate identity
Enforcing authentication information when sending the request to the service is only half the story. The provided identity must be validated and compared to the set of accepted identities. Talend Runtime provides an authentication framework based on Java Authentication and Authorization Service (JAAS), which allows you to plug in different modules targeting a specific backend to validate identity information. Out of the box, Talend Runtime is configured to support a file-based backend, but among others LDAP can also be used to validate. For a complete list of supported backends, see the Apache Karaf documentation.
Properties file module
The PropertiesLoginModule login module is the one configured by default in the Talend Runtime. It is based on the ${Runtime_Home}/etc/users.properties file, which uses the properties file format. Each property represents an identity. The format of the property is as follows:
user=password[,role][,role]...
Several roles may also be grouped together and the group can be referenced in the user entry:
_g_\:group=role[,role]... user=password[,role][,_g_\:group]...
The figure below shows the users.properties file, which is part of the Talend Runtime installation. In addition to the standard users tadmin, tesb, and karaf, two users alice and bob were added.
Figure 2: Sample users file
Password Protection
Passwords in the properties file are in clear text by default, but can be hashed to ensure protection. To automatically hash passwords after restarting the runtime, open and edit the <Runtime_Home>/etc/org.apache.karaf.jaas.cfg file.
The encryption.enabled property must be set to true. Furthermore, the encryption algorithm in the property encryption.algorithm should be set to something like SHA-256. The configuration file should look like this:
Figure 3: org.apache.karaf.jaas.cfg
LDAP module
The properties file solution is fine to quickly get some identity information defined, for example, when testing, but does not scale well. Furthermore, in many cases, identity information is stored in some LDAP server or Active Directory. Talend runtime provides an LDAP module to validate identity information using the information stored in LDAP or Active Directory.
The security.zip file includes the OSGi Blueprint bundle file authentication/LDAP-login-config.xml, which activates the LDAP login module when deployed into the runtime, and the authentication/org.talend.esb.jaas.ldap.cfg file to configure the login module and adapt it to the specific environment.
Table 1: LDAP login parameters for authentication
|
Name |
Description |
|
connection.url |
The LDAP URL, for example, ldap://ldap-host.example.com:389 |
|
connection.username |
Username to connect to LDAP, for example, cn=admin,dc=example,dc=com. The user requires read access to the part of the Directory Information Tree (DIT) where the user information is stored. |
|
connection.password |
User password to connect to LDAP. |
|
user.base.dn |
The LDAP base DN used to look up users, for example, ou=users,dc=example,dc=com. |
|
user.filter |
The LDAP filter used to locate the user applied to the subtree specified in user.base.dn, for example, (uid=%u) where %u will be replaced by the username. |
|
user.search.subtree |
If “true”, the user lookup will be recursive (sub). If “false”, the user lookup will be performed only at the first level (one). |
|
authentication |
Specifies the authentication method used when binding to the LDAP server. The default is simple, where a username and password is required. To enable anonymous, set to none and leave username and password blank. |
-
Edit the configuration file and adapt the settings to your environment. Table 1 provides a list of the properties to be configured and their meaning. The configuration file also contains the description for each property. The sample values in Table 1 and in the configuration file correspond to the Directory Information Tree (DIT) structure shown in Figure 4.
-
When finished with editing, copy the configuration file to the directory <Runtime_Home>/etc.
-
Deploy the authentication/LDAP-login-config.xml file into the Talend Runtime. The easiest way to deploy it is to copy the file to the deploy folder of the Talend Runtime, <Runtime_Home>/deploy.
LDAPS
Often the LDAP server or Active Directory requires the use of Secure LDAP (LDAPS) to ensure the communication is encrypted. The LDAP login module also supports LDAPS, but in addition requires a keystore containing the X.509 certificate of the LDAP server. The location of the keystore and required passwords are specified in the OSGi Blueprint bundle file, which contains the specification of the LDAP login module.
security.zip includes an extended version of the OSGi Blueprint bundle file ldaps/LDAP-login-config.xml with an additional section for the keystore, and ldaps/org.talend.esb.jaas.ldap.cfg with additional properties to configure the keystore-related parameters. Table 2 provides a list of the additional properties that need to be configured.
|
Name |
Description |
|
truststore.path |
Absolute path to a trust store containing required Active Directory certificates, for example, /opt/talend/7.2.1/runtime/etc/keystores/ldaptruststore |
|
truststore.password |
Password for the specified trust store. |
Authorization
The article Authorization for REST service based routes with HTTP Basic Authentication describes how to enable authorization for a Route, and how to configure the user properties file. If LDAP is used for identity validation, the user information is stored in the roles for authorization. Figure 5 shows a container object groups and three child objects that represent the different groups or roles. Users belonging to a group are referenced through the member attribute, where the fully qualified distinguished name of the user is specified.
Figure 5: Sample LDAP for groups/roles
security.zip includes an extended version of the OSGi Blueprint bundle file authorization/LDAP-login-config.xml with additional configuration parameters to retrieve roles, and authorization/org.talend.esb.jaas.ldap.cfg with additional properties to configure the parameters. Table 3 provides a list of the additional properties that need to be configured.
Table 3: LDAP login parameters for authorization
|
Name |
Description |
|
role.base.dn |
The LDAP base DN used to looking for groups/roles, for example, ou=groups,dc=example,dc=com |
|
role.filter |
The LDAP filter used to look for user’s role, for example, (member=%fqdn) where %fqdn will be replaced by the user's full qualified distinguished name |
|
role.name.attribute |
The LDAP role attribute containing the group/role string used by Talend Runtime, for example, cn |
Currently, the sample Route provided in article Authorization for REST service based routes with HTTP Basic Authentication and also included in security.zip does not work for Talend version 7.1, 7.2, and 7.3.
HTTPS for Confidentiality
In the default configuration of the Talend Runtime, both HTTP and HTTPS are enabled, and the private key used for HTTPS is a well-known standard key provided by Talend. If you use HTTPS, replacing the key is a must.
- Install a keystore somewhere on the server with a secret private key and the corresponding certificate.
- Open the file <Runtime_Home>/etc/org.ops4j.pax.web.cfg and look for the property org.ops4j.pax.web.sslkeystore. Replace the entry with the path to your keystore.
- Update the properties org.ops4j.pax.web.ssl.password and org.ops4j.pax.web.ssl.keypassword with the correct passwords.
- If you want to disable access to your services using HTTP, add the following line to the file:
org.osgi.service.http.enabled=false
The file should now look like:
The Server HTTP Configuration section of the Talend ESB Container Administration Guide provides documentation for the HTTP settings in org.ops4j.pax.web.cfg.
