Native JWT Token Validation in Talend 8.0.1 R2024-07: A Long-Awaited Feature

In Patch Release 8.0.1 R2024-07 Talend introduced native product support for JWT (JSON Web Token) validation, fulfilling a long-standing feature request. This new functionality significantly enhances security by enabling OIDC (OpenID Connect) / OAuth2 integration with REST services developed in Talend Studio. Prior to this update, Talend only supported outdated or non-interoperable authentication mechanisms:

• Basic Authentication: Known for its weak security, as credentials are sent in an easily decodable format.
• Proprietary SAML Token Authentication: While secure, it lacked interoperability with common standards and external identity providers.
• Misleading "Open ID Connect" Support: Despite the name, Talend's OIDC support was actually a custom OAuth2 implementation using the outdated "Resource Owner Password Credentials" (ROPC) grant type. ROPC is no longer recommended due to inherent security vulnerabilities, as it requires direct handling of user credentials.

With the introduction of JWT token validation, Talend now supports modern, robust security integrations. This allows for seamless authentication using external identity providers like Azure Entra ID or Keycloak, empowering users to authenticate against these providers and retrieve a signed JWT token tied to a specific service.

How-to enable Certificate revocation List (CRL) validation with Talend ESB Runtime

When certificates are issued they usually have a lifetime of a few years. In some cases it is necessary to terminate the validity of a certificate before the planned end of life. For example if a private key was compromised a certificate should not be valid, as soon as possible.

X.509 certificates (the most common certificate type, used for most internet services) support two different types of certificate revocation:

1. Online Certificate Status Protocol (OCSP) RFC-6960
   The application that wants to validate a certificate sends a certificate identifier to the OCSP Server for revocation checking. The response tells the client if the certificate was revoked or is still OK to use.
2. Certificate Revocation List (CRL) RFC-5280
   The application downloads a file that contains a list of revoked certificates and checks if the current certificate is listed in that file.

As you can see already from the RFC number CRL is the older standard which is usually less performant and less up-to-date compared with OCSP. However in this bog post, I will only focus on the CRL approach.

By default most Java applications will not check for certificate revocations as not every certificate contains a revocation URI and it also has a negative performance impact. The same applies to the Talend runtime. However if you need to check for revocations it is easy to activate. All you need to do is to set two system properties:

com.sun.net.ssl.checkRevocation=true
com.sun.security.enableCRLDP=true

You can add these two lines at the end of the runtime/etc/system.properties configuration file.

If you are interested in the complete logging output you can add some debug system properties in the same file as well:

javax.net.debug=all
java.security.debug=all

In the rest of this article I will show you how to create your own certificates that contain a CRL URL to test and validate this setup.

Using camel json schema validation in Talend Studio

Schema validation is well known for XML content. Since JSON has become very popular in combination with REST services the need for JSON schema validation has also increased.

JSON schema validation is available since Camel 2.20.0 matching Talend Studio version 7.0.1.

This article describes how JSON schema validation can be used for Talend Studio route development.

Username/Password Authentication with Talend ESB WebService

In this Blog post I'll show you how to use Username/Password authentication with a Talend ESB WebService (based on CXF) running inside a Karaf runtime. First with a UsernameToken inside the SOAP Header and second by using BasicAuthentication.

Karaf JDBC JAAS Module

Karaf relys on JAAS for user authentication. JAAS makes it possible to plugin multiple modules for this purpose. By default Karaf will use the karaf realm with a JAAS module getting its user and role information from a property file: runtime/etc/users.properties

In this blog post I will show you how to use the Karaf JAAS console commands and how to setup a JDBC module to authenticate against a database.

Using the Talend PDP ouside of an OSGi Container

In a previous post I've explained how to setup a demo application using SAML token for authentication and XACML for authorization in context of REST services.
In this blog I'm going to explain how to setup the Talend PDP ouside of the OSGi container in which it is usually located, so that you are able to use the PDP co-located to your demo application in any JavaEE container. This is especially helpful if your application cannot easily being deployed into the Talend runtime, but requires lots of authorization requests. In these cases it will be best to have the PDP co-located with your app, completely avoiding expensive network calls.

REST Security - SAML Authentication & XACML Authorization

REST is very successful because it is simple and efficient. SOAP on the other hand usually comes with a high overhead but is also well standardized. In respect to security SOAP provides many well defined ways to exchange security token, whereas REST leaves everything up to the service owner/caller.
This becomes a problem regarding interoperability, if every vendor provides its own custom solution. The same is true for CXF. CXF provides three different ways to exchange a SAML token within a REST call, none of them are standardized. The only standard I could find related to REST Services was the SAML ECP Profile, which is not yet implemented for CXF.

In this post, I'm going to write how to setup a demo application to enable SAML user authentication and XACML user authorization. Both can be used best with Talend STS & PDP.