Meccanismi di sicurezza a livello trasporto possono non essere sufficienti qualora si operasse in un ambiente popolato da intermediari o pari livello (classici ambienti di un Enterprise Service Bus) che ricevano gli stessi messaggi. Può sorgere inoltre il requisito di agire su una gamma più o meno ampia, ad esempio necessitando di criptare campi diversi con chiavi diverse. In questi casi meccanismi di sicurezza punto-punto come quelli visti nel capitolo precedente non sono più sufficienti e diviene essenziale ricorrere a meccanismi a livello messaggio o applicazione (end-to-end).
Come può avvenire ciò? Un sistema è quello di criptare il contenuto del messaggio con la chiave pubblica del destinatario, in modo che esso possa viaggiare normalmente sull’infrastruttura di base, ma senza che il contenuto sia leggibile da soggetti che non siano i destinatari finali.
Introdurre la sicurezza a livello messaggio va però ad impattare su vincoli, specifiche, implementazioni dei Web services. Abbiamo visto in precedenza che instaurare la sicurezza a livello trasporto non ha avuto impatti né sul WSDL, né sulle implementazioni dei servizi. E’ stato sufficiente configurare qualche informazione nell’AS e passare al client gli archivi dei certificati.
Andare invece ad agire sul messaggio SOAP presenta un impatto molto più significativo. Una prima domanda cui rispondere è se i meccanismi di sicurezza implementati debbano avere impatto sul WSDL. E’ possibile pensare di stabilire regole di sicurezza come fatto per il livello trasporto senza toccare il WSDL, ma questa volta i meccanismi sono insiti del messaggio e non del sottostante livello di trasporto, per cui potrebbe avere senso specificare nel WSDL stesso cosa attendersi.
Il WSDL è un linguaggio d’interfaccia, e la stessa definizione di cosa sia il WSDL ha portato a due interpretazioni contrastanti sull’impatto che devono avere le regole di sicurezza sull’interfaccia, per cui da una parte ci sono quanti ritengono che i meccanismi di sicurezza siano estranei alle problematiche d’interfaccia e quindi al WSDL, mentre altri le ritengono parte integrante.
Da tutte le riflessioni scaturite negli ultimi anni è emerso uno standard emanato dall’OASIS (Organization for the Advancement of Structured Information Standards), il WS-Security, specifica che punta a un arricchimento del messaging SOAP in modo da garantire integrità e confidenzialità ai messaggi inviati, nell’ottica di supportare una grande varietà di modelli di sicurezza (tra i quali PKI, Kerberos, SSL) e tecnologie di firma e criptazione.
Il nucleo della specifica è basata sul token, un gettone o simbolo, e la specifica fornisce un meccanismo generico per associare il token al contenuto del messaggio, mantenendosi sufficientemente generica da supportare diversi tipi di formati di tokens. In più, la specifica descrive come criptare tokens e includere chiavi opache (ricevute incapsulate o criptate). In generale quindi lo sforzo dell’OASIS è stato volto a fornire un’estensione al protocollo SOAP che fosse in grado di supportare l’evoluzione dei sistemi di sicurezza.
Assieme alla possibilità di inviare tokens di sicurezza come parte del messaggio, gli altri due meccanismi principali sono costituiti dall’integrità del messaggio e dalla confidenzialità. Nessuno dei tre meccanismi preso da solo è in grado di garantire una sicurezza completa per un Web service, ma possono essere utilizzati tanto in modo indipendente quanto accoppiati reciprocamente, ad esempio firmando e criptando parte di un messaggio e fornendo un security token associato alla chiave usata per la firma e la criptazione. Da notare che stiamo parlando solo di un’estensione del messaggio e non del WSDL. Si riportano di seguito brevi cenni su alcuni termini utilizzati spesso nel capitolo.
- Claim: una dichiarazione fatta da un’entità, racchiude di solito una serie di parametri come nome, chiave, gruppo, privilegi e così via;
- Security Token: una collezione di uno o più claims, in particolare un Signed Security Token è un Security Token firmato e criptato da un’autorità (ad esempio con un certificato X.509 o un ticket Kerberos);
- Trust: caratteristica di un’entità che è disposta a contare su un’altra per eseguire azioni e/o fare asserzioni su un insieme di argomenti o ambiti.
Nel proseguo di questa lezione e della prossima approfondiremo lo standard WS-Security, per poi presentare alcuni esempi pratici. Successivamente si porranno le basi di un altro standard, WS-SecurityPolicy, creato a partire da WS-Security e altri standard per offrire meccanismi utili a rappresentare le funzionalità e i requisiti dei Web services come policies, di modo da potere descrivere nel WSDL quali sono le regole di sicurezza implementate.
WS-Security: modello di sicurezza dei messaggi e protezione
In WS-Security, i security tokens possono essere combinati con firma digitale e criptografia per proteggere e autenticare messaggi SOAP. I claims dei security tokens possono essere usati per affermare l’associazione tra identità e chiavi. Un’autorità può fare da garante per i claims contenuti nei security tokens fornendo una chiave utile a criptarli o firmarli (misura raccomandata), autenticandoli. Ad esempio, è possibile usare un certificato X.509 associando un’identità pubblica ad una chiave pubblica. In assenza di una garanzia di terze parti, il destinatario può scegliere se accettare i claims dichiarati nel token in base alla fiducia riposta nel produttore del messaggio.
La firma consente di verificare origine e integrità del messaggio. Inoltre, può essere usata per dimostrare la conoscenza di una chiave, tipicamente di terze parti, confermando l’associazione tra security token e messaggio creato.
L’integrità dei messaggi è gestita da XML Signature (XMLSIG) in congiunzione con i security tokens per assicurare che eventuali modifiche/corruzioni vengano individuate. Il meccanismo è estendibile e studiato in modo da supportare firme multiple e attori/ruoli potenzialmente multipli.
La confidenzialità è gestita da XML Encryption (XMLENC) in congiunzione con i security tokens per assicurare la confidenzialità a porzioni del messaggio SOAP. Tale meccanismo è studiato per supportare diversi attori/ruoli.
ID References e Security Header
Per diversi motivi è utile instaurare riferimenti tra diversi elementi del messaggio, ad esempio per correlare una firma a un security tokens. Per tale motivo nella specifica è stato previsto un attributo (wsu:id) che permette al destinatario di identificare agevolmente a quali parti del messaggio si applicano le misure di sicurezza. La presenza dell’attributo consente di evitare di dovere utilizzare regole di trasformazione più generali come l’XPATH, semplificando tutto il processo.
Il Security Header (wsse:Security) fornisce un meccanismo per associare informazioni sulla sicurezza a specifici destinatari, siano essi destinatari finali o intermediari. Come conseguenza, elementi di questo tipo possono essere presenti diverse volte in un messaggio SOAP. Un intermediario attivo potrebbe ad esempio aggiungere dei sotto elementi a un header già esistente.
Un messaggio può quindi avere diversi security header se sono previsti diversi destinatari. Un header può omettere gli attributi (S12:role) ruolo o (S11:actor) attore, ma due headers devono avere differenti valori:
| Attributi ed elementi | Descrizione |
|---|---|
| /wsse:Security/@S11:actor | Attributo (SOAP 1.1) opzionale per identificare un attore |
| /wsse:Security/@S12:role | Attributo (SOAP 1.2) opzionale per identificare un ruolo |
| /wsse:Security/@S11[S12]:mustUnderstand | Attributo (SOAP 1.1 [1.2]) opzionale utilizzato per indicare se un header è opzionale o obbligatorio per un destinatario |
| /wsse:Security/{any} | Meccanismo estensibile che consente di passare diversi tipi di informazioni di sicurezza; le informazioni passate dovrebbero rispettare uno schema, viceversa potrebbero generare errori durante l’esecuzione |
| /wsse:Security/@{any} | Meccanismo estensibile che consente di passare diversi attributi; gli attributi dovrebbero rispettare uno schema, viceversa potrebbero generare errori durante l’esecuzione |
Quando un header include un attributo mustUnderstand="true" il destinatario deve generare un errore SOAP se non implementa le specifiche WSS:SOAP Message Security corrispondenti al namespace o se non in grado di processare i security tokens inclusi nell’haeder. In base a policies di sicurezza locali, il destinatario potrebbe comunque ignorare alcuni elementi o estensioni dell’header.
Componenti principali di WS-Security
Riassumono le componenti logiche principali di WS-Security fornendo una rappresentazione schematica degli elementi posti all’interno di un messaggio SOAP.
| Sezione | Descrizione |
|---|---|
| Security Tokens | Sezione destinata a gestire in particolare le informazioni d’autenticazione |
| Message confidentiality | Sezione destinata a gestire le informazioni di cifratura del messaggio (XML Encryption) |
| Message integrity | Sezione destinata a gestire le informazioni di firma del messaggio o relative parti (XML Signature) |
| Security timestamp | Sezione destinata a gestire le informazioni temporali del messaggio, utili al destinatario a stabilire la validità dell’informazione contenuta nel messaggio |
