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.

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.

Fediz with OpenID Connect Support and WS-Federation Bridge (2/2)

Setup a Demonstrator

In this article I'll explain how to setup a demonstrator for the use case described in my previous post.

Setup Fediz IDP & OIDC

First you need to setup the Fediz IDP as usual. To get the OIDC Service working you also need to do the following:

1. Install Fediz Plugin for the Fediz IDP Server (usually you would do this for the client application only)
   For the fediz_config.xml you can use the sample provided with the OIDC Service.
2. Download or build the OIDC service and then deploy the fediz-oidc.war file to your webapps folder (same place where you deployed STS & IDP)

Fediz with OpenID Connect Support and WS-Federation Bridge (1/2)

I'm currently engaged for a big company to provide a solution that allows this company to offer various (REST) services to their partners while these services are hosted and maintained by the company but users can login to these services with accounts managed within their own partner network.

This solution should work for Web-Portals, Mobile Apps & Desktop Applications.

First I was skeptical if it will be possible to find one solution fitting all theses different use cases. But I think I actually did find a very interesting solution. In this post I'll explain the overall architecture of this solution. In my next posts I'll tell you how to get a Liferay Web-Portal integrated as well as a mobile App based on Android.

WS-Federation normally uses SAML Tokens for user authentication. This is fine for container based security solutions, when the user wants to login to a web-portal. But modern web applications (e.g. AJAX based) tend to be executed primarily in the Browser, invoking REST backend services directly from within the Browser.
Handling XML based tokens (incl. XML signature validation) is just a too heavy burden for this type of applications. Also handling lifetime issues with SAML Token could require a Token exchange with an STS. But an STS only provides a SOAP interface according to WS-Trust. It is not feasible for a AJAX Web Application to handle SOAP communication including XML security. Browser based applications should be light-weight and thus they prefer talking to REST services.

Integration Testing for STS Extensions with Jetty

Recently I had to develop some extensions (ClaimHandler, Validator) to the CXF STS. My problem at first was, how to write an integration test that proves the correct implementation of my extensions.

At first I placed my Mockup classes and web config in the src/main folder from my maven project and added the jetty plugin to my pom.xml file. This way I was able to start my REST MockupService simply by typing mvn jetty:run on the console. After starting the service I was able to execute my test classes directly from Eclipse. But this approach did not satisfy me at all, because now I had lots of files in my main project folder, which would not be needed once I build and deploy my STS extensions to another STS installation. Somehow I needed to move all files (Mockup Service, Spring beans.xml, web.xml, etc.) to the test project folder.

In this post I'll explain how to setup you maven pom file so that you can use Jetty in your integration test phase if your packaging goal is not a war file but a simple jar file instead and all your web configuration and classes are located in your test folder.

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.