Alcuni anni fa, per implementare l’autenticazione su alcuni flussi realizzati con Mulesoft, avevo usato  il modulo Spring Security [5] con risultati soddisfacenti. Certo avrei preferito che Mulesoft fornisse una componente proprietaria e apposita per questa funzionalità, ma quella che c’è non funziona con la Community Edition del software, per questo avevo dovuto ricorrere a un modulo esterno.

Tuttavia questa componente ha funzionato bene fino a quando non ho avuto la necessità di aggiornare il modulo dalla versione 1.3.6 a una versione successiva, la 1.3.9, per esempio. In quella versione, infatti, erano cambiate diverse cose, tra cui il formato della definizione della componente non si riusciva ad aggiornare il modulo senza ottenere un errore e non avevo trovato nessuna risoluzione al problema nei vari forum nei quali anzi si consigliava di non aggiornare il componente [6][7][8][9].

Ho quindi rimandato l’aggiornamento fino al passaggio alla nuova Runtime (Mule Server), quando è diventato inevitabile affrontare e risolvere il problema

Descrizione del problema

Il problema, in poche parole, derivava dal fatto che è stata introdotta la possibilità di utilizzare più Security Providers all’interno di un Security Manager e che queste due componenti, che prima erano allo stesso livello, ora sono innestate una nell’altra.

Prima:

<spring:config name="Spring_Config" doc:name="Spring Config" doc:id="zzzzzz" files="beans.xml" />
<spring:security-manager doc:name="Spring Security manager" doc:id="xxxxxxxxx" >
  <spring:delegate-security-provider name="auth-manager" delegate-ref="authenticationManager" />
</spring:security-manager>

Dopo:

<spring:config name="Spring_Config" doc:name="Spring Config" doc:id="zzzzzz" files="beans.xml" />
 <spring:security-manager doc:name="Spring Security manager" doc:id="xxxxxxxxx">
    <spring:delegate-security-providers>
        <spring:delegate-security-provider name="auth-manager" delegate-ref="authenticationManager" />
    </spring:delegate-security-providers>
</spring:security-manager>

Allo stesso tempo però il Software Anypoint Studio che è l’IDE (basato su Eclipse) con cui si disegnano i flussi nella versione CE di Mulesoft, non recepiva la nuova sintassi e restituiva degli errori quando si utilizzava il nuovo formato:

Element: delegate-security-provider is not allowed to be child of element Spring Security manager	apiugovqueries.xml	/apiugovqueries/src/main/mule	Spring Security manager	Message Flow Error

Questo errore rendeva impossibile l’aggiornamento del modulo Spring Security dalla versione 1.3.6, l’ultima funzionante, a una qualsiasi versione successiva.

Risoluzione del problema

Quando è sorta la necessità di passare anche a una versione più aggiornata della Runtime di Mulesoft (il cosiddetto core), allora è sembrato saggio tentare un aggiornamento complessivo del sistema che comprendersse le versioni più aggiornate di Java, Runtime, Anypoint Studio, Spring Security e di tutti gli altri moduli.

Basandomi sullo schema di compatibilità presente sul sito ufficiale [10] abbiamo deciso di effettuare i seguenti aggiornamenti:

 

Prodotto	Vecchia versione	Nuova versione
SDK Java	1.8	17
AnyPoint Studio	7.20	7.22
Runtime Mule Server	4.5	4.9
Spring Security	1.3.6	2.1.1

Inoltre, poiché il sistema girava su un container Docker è stato necessario aggiornare anche lui, ma questo magari può essere oggetto di un altro post anche perché pensavo di integrare l’immagine prodotta dal Docker in un Helm Chart (strumento per il deploy su Kubernetes).

I passi seguiti quindi sono stati i seguenti, prima di tutto una tantum è necessario:

1. Installazione di Oracle Java SDK 17  [12] e modifica conseguente dei PATH di sistema e della variabile d’ambiente JAVA_HOME.
2. Aggiornamento/Installazione di Anypoint Studio all’ultima versione.
3. In Anypoint Studio: Aggiunta di jdk 17 in Window->Preferences->Java->Installed JREs.

Poi, per ogni progetto:

1. Aggiornare tutti i moduli: tasto destro sul nome del progetto->Properties->Mule Project->Modules. Tutti i moduli sono stati messi all’ultima versione, in particolare lo Spring Module è stato aggiornato alla versione 2.1.1.
2. Sempre nelle properties del progetto: Properties->Java Compiler:
   • Spuntare “Enable project specific settings“.
   • Impostare Compiler compliance level = 17.
3. Sempre nelle properties del progetto: Properties->Java Build Path->Libraries:
   1. Impostare la versione di JRE System Library a JDK 17.
   2. Impostare la versione del Mule Runtime Server a 4.9.1.
4. Assicurarsi che anche la Run Configuration (Run->Run configuration..) e la Debug Configuration (Run->Debug Configuration…) usino la versione giusta di Java.
5. Modificare a mano il file XML di progetto (Configuration XML) e sostituire le defiizioni di questo tipo:

   <spring:config name="Spring_Config" doc:name="Spring Config" doc:id="zzzzzz" files="beans.xml" />
   <spring:security-manager doc:name="Spring Security manager" doc:id="xxxxxxxxx" >
       <spring:delegate-security-provider name="auth-manager" delegate-ref="authenticationManager" /> 
   </spring:security-manager>

   con definizioni così fatte (stando attenti a riportare nella nuova versione lo stesso doc:id della versione originale:

   <spring:config name="Spring_Config" doc:name="Spring Config" doc:id="zzzzzz" files="beans.xml" />
   <spring:security-manager
       doc:name="Spring Security manager"
       doc:id="xxxxxxxxx">
       <spring:delegate-security-providers>
           <spring:delegate-security-provider
               name="auth-manager"
               delegate-ref="authenticationManager" />
       </spring:delegate-security-providers>
   </spring:security-manager>

6. Alla fine di questa procedura i Global Elements del progetto dovrebbero comparire come in questo screenshot con un auth-manager annidato nello Spring Security Manager.

Questa configurazione è al momento funzionante e in produzione.

Conclusioni

Credo che alla fine semplicemente sia stato l’aggiornamento di AnyPoint Studio a risolvere il problema, però è anche vero che l’ultima versione del modulo Spring richiedeva una Runtime aggiornata che, a sua volta, richiedeva una versione di Java aggiornata. Quindi non è stato difficile decide di aggiornare tutto il sistema.

Sarebbe stato meglio avere una componente inclusa in Mulesoft CE per gestire l’autenticazione, ma purtroppo non c’è.

Una possibilità è quella di gestire all’interno del flusso la verifica dell’header HTTP e controllare “a mano” la Basic Authentication o il Token, in realtà non è detto che in futuro si possa pensare di fare in questo modo e togliere la dipendenza del progetto da Spring.

Fonti e riferimenti

1. Mulesoft, sito ufficiale.
2. Download Mule Kernel, sito ufficiale.
3. Download, Install, Configure, and Upgrade Mule, sito ufficiale,
4. Download and install Anypoint Studio, sito ufficiale.
5. Component Authorization Using Spring Security, documentazione ufficiale.
6. How to solve error: “delegate-security-provider is not allowed to be child of element Spring Security manager”, Mulesoft Community Forum.
7. Error using spring 1.3.9 for basic-authentication on a Mule 4 project, Mulesoft Community Forum.
8. Which is the best way to add Basic Authentication to a flow implemented with Mule CE 4.50?, Mulesoft Community Forum.
9. Multiple spring:delegate-security-provider elements cause a validation error in studio, documentazione ufficiale.
10. Mule Runtime Java Support, documentazione ufficiale.
11. Discussione su canale Slack, cerca “which is the best way to add the Basic Authentication to a flow ” in #technical-questions.
12. Java SE 17 Archive Downloads, sito ufficiale Oracle.+
13. Immagini Java Adoptium, sito ufficiale.