Dopo aver implementato i progetti di client e server sarà possibile provare ad eseguire il test rammentandosi di aggiornare il progetto deployato sotto JBoss (ad esempio con un clean se si sta utilizzando il plugin di jboss per Eclipse). Di seguito osserviamo con wireshark cosa viaggia al momento dell’esecuzione.
E’ possibile notare gli elementi descritti nella precedente lezione teorica. Osserviamo l’elemento ReferenceList, il BinarySecurityToken contenente il certificato, il Timestamp, ma soprattutto possiamo osservare che questa volta l’header e il body vengono criptati, per cui un eventuale osservatore non potrà ricavare granché ponendosi in ascolto sulla rete. Nello stesso modo, eventuali destinatari possono essere diversificati per consentirgli di leggere solo le parti di pertinenza.
Altro aspetto osservabile, ad essere criptata e firmata non è la sola richiesta ma anche la risposta, come del resto richiesto in fase di configurazione prevedendo gli interceptors in ingresso e in uscita. Osservando i campi relativi alle informazioni sulla chiave (elemento KeyInfo), non esplosi nelle immagini per motivi di spazio, sarà possibile osservare come nella richiesta vengano utilizzati gli estremi relativi al certificato del server, mentre nella risposta quelli relativi al certificato dell’utente Bob.
Osservando invece il timestamp, anche questo non esploso, sarà possibile vedere che di default la scadenza è impostata su cinque minuti.
Provando a verificare cosa restituirà il servizio nel caso di invocazione attraverso il main realizzato nella precedente lezione (ServizioClientWSSec) basato su utente e password, vedremo che verrà restituito un messaggio di errore del tipo "An error was discovered processing the <wsse:Security> header".
Ancora una volta abbiamo potuto quindi integrare un meccanismo di sicurezza per Web services senza avere bisogno di modificare il WSDL o ricompilarlo. Nell’esempio mostrato abbiamo un server legato a un particolare utente, per cui è uno scenario che vede un accordo precedentemente stabilito. In alcuni scenari sarà invece utile o necessario lasciare il server libero di fornire il servizio (incluso di firma e criptazione) ad utenti non noti ma affidabili.
Ciò può avvenire grazie al supporto offerto da Apache CXF che consente di impostare il parametro di configurazione ws-security.encryption.username sul valore useReqSigCert. Il keystore lato server dovrà comunque continuare a mantenere le chiavi pubbliche dei clients da servire.
E’ infine utile dire che negli esempi mostrati si è fatto uso del protocollo HTTP, ma è possibile basarsi anche su HTTPS aggiungendo un meccanismo di sicurezza a livello trasporto come fatto in precedenza. E’ poi possibile agire in proposito anche sul file web.xml aggiungendo un security-constraint che renda disponibile il Web service in questione solo su HTTPS, come fatto di seguito:
<security-constraint>
<web-resource-collection>
<web-resource-name>PresentazioneService </web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>Finora abbiamo operato su estensioni del messaggio SOAP. Nelle prossime lezioni andremo invece ad operare direttamente sul WSDL, utilizzando apposite policies per descrivere come gestire la sicurezza nel Web service e utilizzando le stesse informazioni per ridurre la quantità di configurazioni da impostare nel file jbossws-cxf.xml.
