Esecuzione del test
Eseguendo il test del nostro progetto non dovremmo trovare sorprese. Nel server avverrà la verifica che l’user e la password forniti dal client siano corretti, viceversa verrà sollevata un’eccezione. Di seguito viene mostrato uno screenshot in cui. tramite Wireshark. osserviamo cosa viene veicolato.
Si può notare che al messaggio SOAP è stato aggiunto un header, wsse:Security, che fornisce un token come indicato dallo standard WS-Security. Il token è ovviamente in chiaro (WSConstants.PW_TEXT) e la password anche, come richiesto dal tipo di token scelto e dal fatto che non si è richiesta una firma né la crittografia del messaggio, che segue pertanto anch’esso in chiaro.
Osservando invece il messaggio di risposta, questa volta non riportato nella figura, si potrà osservare come tale messaggio non contenga un header di sicurezza in quanto le regole descritte dal file di configurazione jbossws-cxf.xml prevedevano l’header soltanto nell’invocazione del client al server.
In questo modo Abbiamo analizzato un primo esempio di WS-Security e di come essa viene applicata in JBoss. Ovviamente, è possibile aumentare il livello di sicurezza e organizzare meglio la gestione delle password, ad esempio mediante dei files di properties, ma ciò va oltre lo scopo di questa lezione.
Vantaggi di WS-Security come estensione del messaggio SOAP
Quello che si vuole sottolineare ancora una volta è che il WSDL non è stato modificato, né si è dovuto ricompilarlo per potere utilizzare lo stack CXF utile a intercettare i messaggi SOAP in uscita dal client per aggiungere l’header di sicurezza e in ingresso al Web service per analizzarlo. WS-Security infatti è un’estensione del messaggio SOAP, pertanto il WSDL non risente direttamente della sua presenza.
Ciò ovviamente solleva delle questioni inerenti l’opportunità o meno di descrivere le regole di sicurezza definite, in modo da permettere a chi osserva il WSDL di implementare tali regole e potere invocare correttamente i servizi, anche in maniera automatica, senza incappare in errori dovuti al fatto di essere all’oscuro delle policy di sicurezza adottate.
Inoltre, operando la sicurezza come ulteriore strato rispetto allo stack già presente, gestirne gli aspetti correlati è facilitato da una serie di frameworks che si vanno ad aggiungere alle librerie native Java, ma tale processo risente di una maturità non ancora raggiunta.
Completato questo esempio si consiglia di eseguire alcune modifiche per riprova al fine di verificare il comportamento del servizio in caso di invocazione con user e/o password errati. Nella prossima lezione affronteremo un esempio più complesso.
