1. Web Services Security
Università Roma - Tor Vergata
- Corso di Laurea Specialistica in Informatica -
Esame Sistemi Distribuiti
Giuseppe Specchio

2. Introduzione
● I servizi web si basano su messaggi SOAP
scambiati via HTTP.
● Il protocollo HTTP non è stato realizzato con
l’obiettivo di creare connessioni sicure dal
punto di vista della riservatezza e integrità
dei dati e da solo non può offrire garanzie di
scambio messaggi in modalità sicura.
● Tuttavia sono state implementate alcune so-
luzioni, come il protocollo SSL o sistemi di
crittografia a chiave simmetrica e asimmetri-
ca.

3. Obiettivi di sicurezza (1/2)
● Autenticazione : è il processo che verifica
l’identità di un’entità coinvolta nella
transazione. Può essere implementato come
una semplice username+password o con un
più complicato riconoscimento biometrico
● Disponibilità : una volta determinata
l’autenticità di un’entità, bisogna verificarne i
permessi, vedere quali attività è abilitata a
svolgere e a quali risorse può accedere.

4. Obiettivi di sicurezza (2/2)
● Integrità : è il processo che assicura che i
messaggi non possono essere intercettati e
alterati durante lo scambio fra entità.
● Riservatezza : dati non solo non devono
essere alterati,ma devono essere letti solo da
chi ha il permesso di accedervi.

5. Informazioni di Messaggio
SOAP Sicuro
1.che consentano di identificare l'entità o le
entità interessate dal messaggio.
(Autenticazione)
2. provino che le entità appartengono ai gruppi
corretti.(Riservatezza)
3.provino che le entità godono dei diritti di
accesso corretti.(Disponibilità)
4.stabiliscano che il messaggio non ha subito
modifiche.(Integrità)

6. Sicurezza nel Web
● Il protocollo Secure Socket Layer (SSL) si
pone l’obiettivo di stabilire un canale sicuro,
come un tunnel fra client e server.
1. il client si connette
2. il server invia il certificato
3. il client invia la chiave crittografata
4. Entrambe le parti usano la chiave
durante la comunicazione
● SSL garantisce gli obiettivi di autenticazione,
integrità e riservatezza dei dati.
L’autorizzazione può essere determinata
automaticamente dall’autenticazione.

7. WS-Security
● Per garantire i quattro aspetti della sicurezza
Microsoft e IBM hanno elaborato le specifiche
WS-Security.

8. Messaging Layer
● Descrive le estensioni al protocollo SOAP
per garantire uno scambio di messaggi
sicuro.
● WS-Security affronta il problema della
protezione facendo ricorso a standard e
specifiche esistenti: per l’autenticazione si
utilizzano le specifiche Kerberos e X.509,
oltre alla solita coppia username+password;
● Le specifiche XML Encryption e XML
Signature descrivono come crittografare e
firmare il contenuto del messaggio XML.

9. Policy Layer
● WS-Policy definisce un framework molto generale
ed estensibile per i mittenti e destinatari per
dichiarare le loro capacità e requisiti che
interessano entrambe le parti.
● WS-Trust definisce un modello per creare e gestire
le relazioni fidate fra le parti. Comprende anche
l’inclusione di terze parti e intermediari nelle
relazioni di mediazione fidate.
● WS-Privacy definisce invece un modello per
richiedenti e serventi su come dichiarare le
preferenze in fatto di privacy.

10. Federated Secure layer
● WS-SecureConversation definisce un
modello di autenticazione per autenticare i
messaggi del richiedente e autenticare i
servizi proposti al richiedente.
● WS-Federation definisce come costruire vari
scenari di mediazione utilizzando WS-
Security, WS-Policy, WS- Trust e
WSSecureConversation.
● WS-Authorization definisce come le
politiche di accesso sono gestite.

11. All’interno di WS-Security (1/2)
● In WS-Security, all’interno dell’intestazione di
SOAP (SOAP Header) sono trasportati i dati
(o metadati) relativi alla protezione.
● Nel caso di autenticazione tramite login e
password viene utilizzato l’elemento
UsernameToken.
● Per i token di autenticazione binari, quali i
ticket Keberos e le coppie chiavi pubbliche-
private (X.509) si utilizza l’elemento
BinarySecurityToken.

12. All’interno di WS-Security (2/2)
● Se il messaggio è firmato, l’intestazione
deve contenere informazioni su come è stato
firmato il messaggio e su dove sono
memorizzate le informazioni relative alla
chiave. La chiave può essere nel messaggio
o altrove, nel qual caso il messaggio conterrà
un riferimento ad essa.
● Dato che un messaggio SOAP può
contenere più di un’intestazione, un
intermediario capisce quale intestazione è
destinata a lui grazie all’attributo actor
univoco.

13. Autenticazione tramite
username e password
<wsse:UsernameToken>
<wsse:Username>giuseppe</wsse:Username>
<wsse:Password Type=quot;wsse:PasswordTextquot;>
password
</wsse:Password>
</wsse:UsernameToken>

14. UsernameToken Schema
<xs:element name=quot;UsernameTokenquot;>
<xs:complexType>
<xs:sequence>
<xs:element ref=quot;Usernamequot;/>
<xs:element ref=quot;Passwordquot; minOccurs=quot;0quot;/>
</xs:sequence>
<xs:attribute name=quot;Idquot; type=quot;xs:IDquot;/>
<xs:anyAttribute namespace=quot;##otherquot;/>
</xs:complexType>
</xs:element>

15. Schema di autenticazione
tramite certificati X.509
<xs:element name=quot;BinarySecurityTokenquot;>
<xs:complexType>
<xs:simpleContent>
<xs:extension base=quot;xs:stringquot;>
<xs:attribute name=quot;Idquot; type=quot;xs:IDquot; />
<xs:attribute name=quot;ValueTypequot; type=quot;xs:QNamequot; />
<xs:attribute name=quot;EncodingTypequot; type=quot;xs:QNamequot; />
<xs:anyAttribute namespace=quot;##otherquot;
processContents=quot;strictquot; />
</xs:extension>
</xs:simpleContent> definisce il tipo di codifica utilizzata:
●wsse:X509v3: un certificato X.509 versione 3.
</xs:complexType>
</xs:element> ●wsse:Kerberosv5TGT: un TGT, conforme alla
definizione della sezione 5.3.1 della specifica
Kerberos.
●wsse:Kerberosv5ST: un Service Ticket, con-
forme alla definizione della sezione 5.3.1 della
specifica Kerberos.

16. Schema di autenticazione
tramite certificati X.509
<xs:element name=quot;BinarySecurityTokenquot;>
<xs:complexType>
<xs:simpleContent>
<xs:extension base=quot;xs:stringquot;>
<xs:attribute name=quot;Idquot; type=quot;xs:IDquot; />
<xs:attribute name=quot;ValueTypequot; type=quot;xs:QNamequot; />
<xs:attribute name=quot;EncodingTypequot; type=quot;xs:QNamequot; />
<xs:anyAttribute namespace=quot;##otherquot;
processContents=quot;strictquot; />
</xs:extension>
</xs:simpleContent> definisce la codifica utilizzata che può essere
</xs:complexType> impostata su wsse:Base64Binary o
</xs:element> wsse:HexBinary.

17. Schema di autenticazione
tramite certificati X.509
<xs:element name=quot;BinarySecurityTokenquot;>
<xs:complexType>
<xs:simpleContent>
<xs:extension base=quot;xs:stringquot;>
<xs:attribute name=quot;Idquot; type=quot;xs:IDquot; />
<xs:attribute name=quot;ValueTypequot; type=quot;xs:QNamequot; />
<xs:attribute name=quot;EncodingTypequot; type=quot;xs:QNamequot; />
<xs:anyAttribute namespace=quot;##otherquot;
processContents=quot;strictquot; />
</xs:extension>
Esempio di Intestazione:
</xs:simpleContent>
</xs:complexType> <wsse:BinarySecurityToken
</xs:element> ValueType=quot;wsse:X509v3quot;
EncodingType=quot;wsse:Base64Binaryquot;
Id=quot;SecurityToken-f49bd662-59a0-
401a-ab23-1aa12764184fquot;>
MIIHdjCCB...
</wsse:BinarySecurityToken>

18. Crittografia (1/2)
● La crittografia si rende necessaria quando il
contenuto del messaggio non deve essere
intercettato, come nella trasmissione del
codice di carta di credito.
<?xml version=quot;1.0quot; encoding=quot;utf-8quot; ?>
<soap:Envelope
xmlns:soap=quot;http://schemas.xmlsoap.org/soap/envelope/quot;
xmlns:xenc=quot;http://www.w3.org/2001/04/xmlenc#quot;>
<soap:Header
xmlns:wsse=quot;http://schemas.xmlsoap.org/ws/2002/07/secextquot;
xmlns:wsu=quot;http://schemas.xmlsoap.org/ws/2002/07/utilityquot;>
<wsu:Timestamp>
<wsu:Created wsu:Id=quot;Id-3beeb885-16a4-4b65-b14c-0cfe6ad26800quot;>
2007-12-15T00:26:15Z</wsu:Created>
<wsu:Expires wsu:Id=quot;Id-10c46143-cb53-4a8e-9e83-ef374e40aa54quot;>
2007-12-15T00:31:15Z</wsu:Expires>
</wsu:Timestamp>

19. Crittografia (2/2)
<wsse:Security soap:mustUnderstand=quot;1quot; >
<xenc:ReferenceList>
<xenc:DataReference URI=quot;#EncryptedContent-f6f50b24-3458-41d3-
aac4-390f476f2e51quot;/>
</xenc:ReferenceList>
<xenc:ReferenceList>
<xenc:DataReference URI=quot;#EncryptedContent-666b184a-a388-46cc-
a9e3-06583b9d43b6quot;/>
</xenc:ReferenceList>
</wsse:Security>
</soap:Header>
<soap:Body>
<xenc:EncryptedData Id=quot;EncryptedContent-f6f50b24-3458-41d3-
aac4-390f476f2e51quot; Type=quot;http://www.w3.org/2001/04/xmlenc#Contentquot;>
<xenc:EncryptionMethod
Algorithm=quot;http://www.w3.org/2001/04/xmlenc#tripledes-cbcquot; />
<KeyInfo xmlns=quot;http://www.w3.org/2000/09/xmldsig#quot;>
<KeyName>Chiave simmetrica</KeyName>
</KeyInfo>
<xenc:CipherData>
<xenc:CipherValue>InmSSXQcBV5UiT...
Y7RVZQqnPpZYMg==
</xenc:CipherValue>
</xenc:CipherData>
</xenc:EncryptedData>
</soap:Body>
</soap:Envelope>

20. Conclusioni
● WS-Security è uno standard studiato per realizzare
comunicazioni sicure e autenticate tra web
services.
● Non vuole definire nuovi strumenti per la sicurezza,
ma fornisce un metodo per includere nei messaggi
SOAP gli strumenti di autenticazione e protezione
già creati e utilizzati, come Kerberos, i certificati X.
509 i sistemi di login e password.
● Inoltre nello stesso messaggio possono essere
indicati diversi tipi di protezione, interpretati poi dai
vari destinatari.

21. Strumenti
● toolkit IBM WebSphereSDK for Web
Services v5.1 (WSDK) compreso di JVM di
IBM
● Plug-in per Eclipse per generare Web
Dinamic Project Sicuri