Una volta completato il nostro progetto su WS-SecurityPolicy e usernameToken occorrerà passare alla fase di test su un server configurato con Spring (il server Spring RS creato in precedenza), attendere il corretto avvio ed effettuare prove di invocazione del servizio con il client impostato sui parametri (protocollo, host, porto) corretti.
In primo luogo, accedendo con un browser all’host del servizio tramite l'URL:
http://localhost:8080/Presentazione/PresentazioneService/ServizioPresentazioneIF?wsdlpotremo osservare quanto segue.
Oltre ai classici parametri del Web service, segue la policy SecurityServiceBindingPolicy che informa così un eventuale utente interessato al servizio sulle politiche di sicurezza implementate e su come consumare il servizio.
Eseguendo l’accesso con un client datato che non contempli le policies descritte o con il nuovo client con la variabile booleana addSecHeader settata su false, otterremo in risposta un messaggio di errore che ci informerà circa la necessità di soddisfare le regole di sicurezza corrette.
Impostando invece la variabile su true, potremo accedere correttamente al servizio. Non essendo necessario modificare il WSDL del server, ed essendo le regole identiche a quelle di fatto previste nel primo esempio proposto, per poter consumare il servizio potremo utilizzare anche il client creato per il primo esempio relativo a WS-Security.
Questo perché alla fin fine quello che conta è quanto sta viaggiando nel messaggio inviato dal client verso il server, ossia quanto descritto nell’header di sicurezza e relative regole di implementate nel messaggio. Ovviamente, lato client la presenza di un WSDL che contempli le policies di sicurezza adottate lato server non è inutile, in quanto può permettere ad esempio di applicare lato client controlli di sicurezza che vadano a verificare le regole di sicurezza implementate evitando di far partire messaggi che non le rispettino (ed evitando di conseguenza che messaggi non conformi viaggino sulla rete solo per essere rifiutati).
In questo esempio, osservando con Wireshark si noterà che a viaggiare su rete sono messaggi in chiaro del tutto analoghi a quelli che abbiamo analizzato nella prima esercitazione. Un messaggio in chiaro all’andata con un header di sicurezza, e un messaggio privo di header come risposta.
Il meccanismo descritto pertanto è piuttosto potente e permette di effettuare modifiche minimali lato server per poter far variare i meccanismi di sicurezza implementati permettendo al contempo di verificare semplicemente le modifiche apportate o comunque le regole da implementare per accedere ai servizi esposti.
E’ possibile evitare di dover mettere mano al WSDL ogni volta che si modificano le policies descrivendo queste ultime in documenti esterni referenziati nel WSDL, come descritto nello standard Web Service Policy 1.5 Attachment.
