IBM App Connect Enterprise — SOAP WS Security con Security Profile e Vault
In questo articolo andiamo a realizzare un flusso d’integrazione sulla piattaforma IBM App Connect Enterprise (ACE) che consente di esporre un Web Service di tipo SOAP con il meccanismo di autenticazione di WS-Security.
Le credenziali utilizzate per l’accesso al Web Service SOAP saranno salvate all’interno del Vault configurato sul prodotto IBM App Connect Enterprise (ACE).
Il necessario per seguire questa guida sono:
- IBM App Connect Enterprise Toolkit
- Docker, o in alternativa un’installazione del prodotto IBM App Connect Enterprise
Tutto il codice sorgente in questo articolo è disponibile nel seguente repository Git:
IBM App Connect Enterprise
IBM App Connect Enterprise (abbreviato in IBM ACE, precedentemente conosciuto come IBM Integration Bus) è un prodotto di Integration Broker di IBM che permette lo scambio di informazioni tra differente applicazioni. Il prodotto è un Enterprise Service Bus (ESB) e viene utilizzato nelle architetture SOA (Service-oriented Architecture).
IBM ACE fornisce funzionalità per creare soluzioni necessarie a supportare diversi requisiti di integrazione attraverso una serie di connettori per una vasta gamma di origini dati. Un vantaggio dell’utilizzo di IBM ACE è che lo strumento abilita le applicazioni esistenti per i servizi Web senza costose riscritture delle applicazioni legacy.
La versione gratuita per la valutazione del prodotto è scaricabile dal seguenti link.
Creazione e configurazione di un Integration Server
Come prima cosa andiamo a crearci la nostra immagine Docker del prodotto IBM App Connect Enterprise. IBM ha rilasciato la propria immagine ufficiale di prodotto al seguente link.
Purtroppo l’immagine ufficiale non comprende la possibilità di utilizzare la configurazione del Vault di prodotto, pertanto andiamo a creare un’immagine docker custom di IBM ACE, aggiungendo le configurazioni per la creazione del vault:
Come mostrato sopra abbiamo un Dockerfile che estende l’immagine base di IBM e successivamente andiamo a copiare lo script bash, che contiene la configurazione e creazione del vault denominato “ace-local-vault” e la creazione di una credenziale con queste specifiche:
- Nome Credenziale: myCredential
- Username: myUsername
- Password: myPassw0rd
Qualora volessimo inserire più credenziali è sufficiente modificare il file “create-local-vault.sh” e buildare l’immagine.
Per creare l’immagine eseguiamo il seguente comando, nella stessa directory dove sono presenti i file:
docker build -t ace-server-vault --file Dockerfile .Al termine avremo la nostra immagine Docker con il nome di “ace-server-vault”.
Per instanziare il container dalla nostra immagine eseguiamo il comando:
docker run --name ace-server-vault \
-p 7600:7600 \
-p 7800:7800 \
--env LICENSE=accept \
--env MQSI_VAULT_KEY=ace-local-vault \
--env ACE_SERVER_NAME=ACESERVER \
ace-server-vaultNel comando sopra passiamo la variabile d’ambiente “MQSI_VAULT_KEY” con il nome del nostro vault per far capire ad IBM ACE di utilizzare il vault.
Da browser recandoci sulla console di amministrazione vedremo il nostro Integration Server di ACE attivo.
Per accedere alla console utilizziamo il link:
Ora spostandoci sul tab “Credenziali” vedremo la nostra credenziale creata con il bash script.
Definizione delle Policy di sicurezza
Dal nostro Toolkit di sviluppo creiamo un progetto di Policy e creiamo:
- Policy — SecurityProfile
Nella Policy appena create settiamo il “Type” a “Security profile” e andiamo a definire quale autenticazione e quali credenziali dovrà utilizzare il flusso per la validazione della coppia username e password.
Lo creiamo come da immagine seguente:
Nel campo “Autenticazione” andiamo a settare “Local”, cosi IBM ACE andrà a cercare la credenziale specificata “myCredential” nel Vault di sistema.
- WS Policy Sets and Bindings
Si aprirà una finestra modale ed andremo a creare un nuovo “Policy Sets” (nell’esempio sotto è chiamato “WSSecurity_Custom”) ed impostiamo il valore “uname_token” come “Token Name”.
Ora creiamo la “Policy Set Bindings”, nel nostro esempio “WSSBidings_Custom” e gli associamo la “Policy Set” appena creata sopra, ed indichiamo che tipo di Policy è, nel nostro caso di tipo Provider in quanto sarà abilitata su un nodo SOAP Input.
Ora il nostro progetto di Policy sarà composto dai seguenti file:
Ora possiamo deployarlo sul nostro Integration Server :
Accedendo alla console di amministrazione troveremo il nostro progetto di Policy.
Applicare le Policy ad un’applicazione
In questo esempio ci andiamo a creare la nostra applicazione per testare la configurazione e il funzionamento delle policy di WS-Security.
Creiamo una applicazione (denominata “WSS_Test”) che conterrà un WSDL che andremo ad esporre con un SOAP Input, il Message Flow principale e un oggetto di Mapping.
Il Message Flow sarà così composto:
Mentre il nostro Mapping implementa la logica del servizio:
Ora la nostra applicazione è pronta e non ci rimane altro che applicare le Policy alla nostra applicazione.
Per prima cosa dobbiamo creare un file BAR, successivamente aprendolo dal Toolkit andiamo a cercare il nodo SOAP Input e applichiamo le properties al nodo. Il pattern della stringa per impostare le policy è la seguente:
{PolicyProject}:PolicyNameNel nostro caso andiamo ad impostare:
- Policy Set → {WSS_Policy}:WSSecurity_Custom
- Policy Set Bindings → {WSS_Policy}:WSSBindings_Custom
- Security Profile → {WSS_Policy}:WSS_SecurityProfile
Salviamo il BAR e deployamolo sull’Integration Server.
Sempre dalla console di amministrazione è possibile visionare la nostra applicazione installata:
Da browser sarà possibile visionare il WSDL:
SOAP WS-Security Test
Per testare il nostro sviluppo utilizziamo il tool SoapUI, creiamo un nuovo SOAP Project e settiamo il WSDL del nostro Servizio deployato:
Effettuiamo la prima SOAP Request senza impostare nessuna Autenticazione:
Come vediamo dall’immagine sopra il Servizio risponde con un SOAP Fault in quanto non ha superato l’autenticazione.
Ora sul progetto di SoapUI andiamo a configurare la WS-Security:
Adesso impostiamo la configurazione WSS sulla SOAP Request:
Come visibile sopra ora il Servizio risponde correttamente, segno che l’autenticazione è avvenuta con successo!
