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.

Custom Claim Handler in Fediz Plugin

Apache Fediz plugin provides now a support for custom claim processing since version 1.4.5. This allows fine grained claim control on application side, which is very useful if you are not in control of the IDP/STS claim creation itself. Or if you want to do some local claim value mapping that is very application specific.

In this blog post, I will show you how to leverage this new Fediz feature.

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.

Kerberos Debugging in Java

Working with Kerberos can easily cause a lot of trouble. Troubleshooting can take several hours.
In this blog I'll show you what will help you best when using Kerberos with Java for example to secure a Hadoop cluster.

When Kerberos is not working as expected it is important to understand why. Enabling Kerberos debug logging is a very valuable resource to understand what is happening.
To enable Kerberos debugging you need to set the following JVM property:

-Dsun.security.krb5.debug=true

Now read your log file very carefully. This will help you to understand what is missing.

Usually you will define your Kerberos configuration within your C:\Windows\krb5.ini or /etc/krb5.conf file. Make sure that your hostname mapping to your Kerberos realm is correct in here.
There are also a few other JVM properties that are usually not required, but can be useful to override/define your configuration at application startup:

-Djava.security.krb5.kdc=hostname.of-your.kerberos.server
-Djava.security.krb5.realm=YOUR.KERBEROS.REALM
-Djava.security.auth.login.config=file:/C:/Programme/Tomcat-IDP/conf/kerberos.jaas

Kerberos is very sensitive to DNS configuration.

Here are some more shell commands that are very helpful to test if Kerberos is working in general (outside of your Java application):

# Login with a specific keytab file
kinit -k -t /path/to/your/keytab

# List all local available tokens. After kinit there should be at least your tgt token.
klist

# Request a ticket for a specific service. Check if the service is registered correctly at your Kerberos server.
kvno service/hostname@domain

https://web.mit.edu/kerberos/krb5-1.12/doc/user/user_commands/kvno.html

Custom JSSE Truststore to enable XKMS Certificate Validation

Recently I was involved in a project which uses a central XKMS Server for certificate and trust management. This was all working fine within the Talend runtime with a custom wss4j crypto provider. However the need raised to perform client certificate validations (mutal SSL) with Apache Fediz running inside an Apache Tomcat server.


Usually I would use a JKS truststore for Tomcat to add trusted certificates (CAs). However this was not possible for this project, because all certificates will be managed inside an LDAP accessible via a XKMS service. Searching for a solution to extend Tomcat to support XKMS based certificate validation I came across the JSSE Standard.

Reading throw the documentation was not so straightforward and clear. But searching through the internet finally helped me to achieve my goal. In this blog post, I'll show you what I had to do, to enabled XKMS based SSL certificate validation in Tomcat.

Apache Fediz with Client Certificate Authentication (X.509)

In this blog post I will explain how to generate your own SSL key-pair to perform certificate based authentication for SSO purposes with Apache Fediz IDP.

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.

Apache Fediz installation in production

In this article I'll explain to you what to do and what to be aware of, when you want to user Fediz IDP in production.

Basically you need to change all default passwords and certificates.

If you will use Tomcat as user Servlet container I'll also give you some tips how to secure tomcat best, so that an attacker will have a hard time breaking into your system.

Understanding Spring Web-Flow in Apache Fediz - Part 2

After explaining in Part 1 of this topic how the Spring Web-Flow will be initiated I'm going to review the actual flow in some more detail in this post.

The flow registry knows three flows:

1. Federation Validate Request Flow
2. Federation Signin Request Flow
3. Federation Signin Response Flow

The first flow is linked to the fediz-idp/federation URL within the idp-servlet.xml file which is the usual entry point for the IDP. The two other flows are sub-flows which will be executed from within the first flow.

<webflow:flow-registry id="flowRegistry" flow-builder-services="builder">
    <webflow:flow-location path="/WEB-INF/flows/federation-validate-request.xml" id="federation" />
    <webflow:flow-location path="/WEB-INF/flows/federation-validate-request.xml" id="federation/up" />
    <webflow:flow-location path="/WEB-INF/flows/federation-validate-request.xml" id="federation/krb" />
    <webflow:flow-location path="/WEB-INF/flows/federation-validate-request.xml" id="federation/clientcert" />
    <webflow:flow-location path="/WEB-INF/flows/federation-signin-request.xml" id="signinRequest" />
    <webflow:flow-location path="/WEB-INF/flows/federation-signin-response.xml" id="signinResponse" />
</webflow:flow-registry>

Validate Request Flow

The main federation flow can be customized within the WEB-INF/flows/federation-validate-request.xml file. The standard flow looks like this:

Understanding Spring Web-Flow in Apache Fediz - Part 1

When I started to work with Apache Fediz, most of the actions looked like magic to me, because I was not able to understand how Spring Security and Spring Web Flow have been used in Apache Fediz. After several hours of learning and investigation I finally understood how all this works together.

In this post I would like to share with you from what I understood of how Fediz works internally.

Register trusted 3rd party IDP with SAML Web Browser SSO Profile

In this Post I'll explain how to configure Apache Fediz IDP so that it can be used with a trusted 3rd party IDP based on SAML Web Browser SSO Profile.

In my previous posts about Apache Fediz I focused on the WS-Federation passive protocol only since it is the successor standard for the SAML Web Browser SSO Profile. But in some cases you will have to establish a federated trust relation with an IDP how does not support the WS-Federation Standard yet, but only the older SAML Web Browser SSO Profile.

I'll explain how to register a SAML trusted IDP at the IDP as well as how to setup a demonstrator. Please also take a look at Colms post about this topic.

Liferay Portal Integration with Fediz OpenID Connect

I was given the task to provide a security solution to enable SSO in a Liferay portal based on OpenID Connect with the Apache Fediz OIDC Service. In this post I'll explain how to get this done.

You will need Apache Fediz version 1.3.0 or higher, if you want to setup this use case by yourself

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.

Single Logout with Fediz - WS-Federation

WS-Federation is primarily used to achieve Single Sing On (SSO). This raises the challenge how to securely logout from multiple applications once the user is done with his work. To navigate to each application previously used to hit the logout button would be quite inconvenient. Fortunately the WS-Federation standard does not only define how to do single sign on, but also how to do single logout.

In this blog I'll explain how to setup a demonstrator to show single sing-on as well as single sing-off. Since single sing-off is implemented in CXF Fediz version 1.2, I'm going to use a snapshot build since 1.2 is not yet released.

Understanding WS-Federation - Passive Requestor Profile

WS-Federation  is an identity federation specification which makes it possible to setup a SSO federation including multiple security realms. A realm (sometimes also called domain) represents a single unit under security administration or a part in a trust relationship.

Entities

Within the WS-Federation standard the following entities are defined:

• Relying Party (RP)
  The relying party is a resource (web application or service) which consumes security tokens issued by the Security Token Service.
• Requestor
  A requestor is a user who wants to access a resource (relying party).
• Identity Provider (IDP)
  An Identity Provider can act as an authentication service to a requestor (in this case it is also called “Requestor IDP” or “Home-Realm IDP”) as well as an authentication service to a service provider (also called “Relying Party IDP”). If a user tries to access a relying party within his own security domain, the “Requestor IDP” and the “RP-IDP” can be the same IDP instance. An IDP can also be seen as an Web-Frontend (Extension) of an STS.
• Security Token Service (STS)
  A Security Token Service is a web service that validates user credentials and issues security tokens which can include user attributes (also called claims). The security token can be used at the Relying Party to authenticate the requestor’s identity.

Passive Requestor Profile

The “Passive Requestor Protocol”  of the WS-Federation standard deals with web-browser based access of a resource like a web portal or a web application.

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.

Identity Federation - Identity Mapping vs. Claim Mapping

Identity and claim mapping become important, when the target realm (A) of a web application is not equal to the home realm (B) of the user. In this case a SAML token from the user (issuer B) cannot directly be validated at the web application (trusting issuer A only). The relaying party IDP of the web application (in realm A) is able to exchange the SAML token from the (trusted) home realm (B) into a SAML token applicable for the target realm (A). This exchange can be based either on identity mapping or on claim mapping. In this post I'm going to explain what's the difference between these two mapping styles and when to use which alternative.

SSO with Fediz IDP and Kerberos

Colm O hEigeartaigh extended Fediz IDP just recently to allow browser-based Kerberos authentication at the IDP. In this blog I'm going to explain how to setup your system environment to provide WS-Federation based SSO for a normal web application:

• Prepare your Active Directory
• Installing the Fediz Demo Application
• Installing Fediz IDP and a Kerberos enabled STS
• Enable Kerberos for your Browser

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.