Abbiamo visto nelle lezioni precedenti che WS-Security è un’estensione del protocollo SOAP volto a fornire uno standard per applicare ai Web services misure volte a garantirne la sicurezza. WS-Security opera principalmente tramite estensioni dell’header, senza che questo vada ad impattare sul WSDL e lasciando agli sviluppatori la libertà di decidere cosa fare con quanto contenuto nell’header.
Questo al tempo stesso può essere un vantaggio (e per alcuni ciò rispetta i principi attorno ai quali è stato definito il WSDL) ma anche uno svantaggio, visto che chi consulta un WSDL non è nelle condizioni di sapere quali regole di sicurezza vengono implementate e conseguentemente diviene molto complicato automatizzare il processo di accesso ai servizi. Pertanto, oltre a questo standard sono nati una serie di standard volti a soddisfare diverse esigenze:
- WS-Trust: standard OASIS che fornisce un’estensione di WS-Security specifica per le tematiche che ruotano attorno ai security tokens, volta a garantire i processi utili a stabilire una relazione di fiducia tra utenti e providers di servizi.
- WS-Policy: una specifica che permette ai Web services di usare l’XML per descrivere e condividere le politiche adottate (politiche di sicurezza, quality of services etc.) e ai clients di descrivere le politiche richieste.
- WS-SecureConversation: specifica creata da IBM e altri che lavora assieme a WS-Security, WS-Trust e WS-Policy per abilitare la creazione e la condivisione di contesti di sicurezza. Estendendo i casi d’uso di WS-Security, lo scopo di WS-SecureConversation è quello di stabilire contesti di sicurezza per scambi multipli di messaggi SOAP, riducendo l’overhead derivante dallo scambio delle chiavi attraverso l’instaurazione di chiavi di sessione.
A questi standard se ne è aggiunto un altro, WS-SecurityPoliciy: una specifica creata da IBM e divenuta standard OASIS che estende alcuni protocolli per Web services in ambito sicurezza (WS-Security, WS-Trust e WS-SecureConversation). WS-SecurityPolicies fornisce un modo semplice per configurare e controllare i requisiti di sicurezza estendendo il WSDL in modo da poter descrivere direttamente in esso le politiche di sicurezza adottate da un Web service.
WS-Security è un’estensione di SOAP, ossia dei messaggi che viaggiano, mentre WS-SecurityPolicy estende il WSDL consentendo non solo di applicare ai messaggi SOAP le regole adottate ma di renderle anche visibili a chi volesse consultare il WSDL. WS-SecurityPolicy fornisce quindi un modo più semplice e più basato su standards per configurare e controllare i requisiti di sicurezza, permettendo a svariati tool e framework come .NET o CXF di auto configurarsi semplicemente per interoperare con i servizi esposti.
In WS-SecurityPolicy il binding e/o le operazioni del WSDL possono far riferimento a sezioni WS-Policy che descrivono i requisiti di sicurezza di base per poter interagire con il Web service. Le specifiche di WS-SecurityPolicy permettono di indicare aspetti quali chiavi simmetriche o asimmetriche, utilizzo del protocollo HTTPS, parti da criptare o firmare, se includere il timestamp o meno e così via.
Più in generale, vengono descritte le azioni esercitate per interagire in modo sicuro con il Web service. Non tutti gli aspetti connessi vengono però specificati nelle policies adottate, ad esempio non viene descritto dove trovare keystores, username e password e altre informazioni comunque utili a run-time, così da garantirne la riservatezza.
WS-SecurityPolicy: modello di sicurezza
La specifica definisce policy assertions, asserzioni delle politiche applicate alle proprietà della sicurezza in un Web service. Queste asserzioni sono progettate principalmente per rappresentare caratteristiche di sicurezza definite in SOAP Message Security, WS-Trust, WS-SecureCenversation, ma possono anche descrivere requisiti di sicurezza più generici o legati al livello di trasporto.
L’intento della specifica è disporre di un insieme di asserzioni che forniscano un modo comune di descrivere come i messaggi vengono resi sicuri sul percorso mantenendo la flessibilità in termini di tokens, crittografia e meccanismi di firma adottati, ma sufficientemente dettagliati per garantirne l’interoperabilità. Per ottenere questo obiettivo viene sfruttato il meccanismo di selezione delle politiche e associazione ad artefatti del Web service tipico di WS-Policy.
Conseguentemente, dove possibile le asserzioni non si basano su parametri o attributi, evitando di dover legare il primo livello di elaborazione ad aspetti che possono essere specifici di dominio. In generale le asserzioni contemplano anche attributi basati su schemi, attributi che vanno oltre quanto previsto da WS-Policy.
Per fornire una semantica ricca in grado di descrivere vincoli e requisiti di sicurezza, le asserzioni vengono suddivise in semplici patterns: quali parti vengono rese sicure (Protection Assertions), aspetti generici o pre-condizioni di sicurezza (Conditional Assertions), meccanismi usati per fornire la sicurezza (Security Binding Assertions), tipi di tokens e patterns usati per fornire ulteriori claims (Supporting Token Assertions), riferimenti a tokens e opzioni trust (WSS e Trust Assertions).
Le asserzioni possono essere innestate per specificare in modo più approfondito aspetti di un’altra asserzione. Inoltre, le asserzioni possono essere utilizzate in combinazioni multiple. Nella prossima sezione approfondiremo i tipi principali delle Policy Assertions.
