Sicurezza nei Web Services: Migrazione dell autenticazone di Web Services da ticket di sessione a WS-Security con token SAML

Transcript

1 Master Universitario di II livello in Interoperabilità Per la Pubblica Amministrazione e Le Imprese Sicurezza nei Web Services: Migrazione dell autenticazone di Web Services da ticket di sessione a WS-Security con token SAML Lavoro pratico I Periodo didattico Anno Accademico 2011 Autore: Dott. Carlo Carrabs Univervsità degli Studi di Roma La Sapienza Facoltà di Ingegneria

2 Indice 1. Obiettivo 2. Introduzione alla SOA 3. Web Services 4. Sicurezza: Aspetti generali 5. WS-Security : sicurezza nei Web Services 6. Standard SAML 7. AS-IS: Web Services autenticati tramite ticket di sessione 8. TO-BE: Web Services con Ws-Security e asserzione SAML 2

3 Obiettivo La seguente tesina ha lo scopo di presentare una descrizione di massima delle specifiche WS-Security e dei possibili utilizzi dello stessa per implementare un meccanismo di autenticazione e autorizzazione per servizi pre-esistenti effettuando una procedura per l allineamento della metodologia di sicurezza alle attuali specifiche di riferimento per i Web Services con l introduzione di WS-Security con SAML 2. 3

4 Service Oriented Architecture - SOA Con SOA si identifica un paradigma architetturale distribuito orientato ai servizi, i quali erogano funzionalità tramite delle interfacce ben definite ed indipendentemente da come questi vengano realizzati Architettura SOA Gli attori che compongono una architettura SOA sono tre: Service provider: rende disponibile il servizio, ne espone l'interfaccia e la pubblica su uno specifico registry. Service client: utilizza il servizio tramite l'interfaccia esposta dal provider, ottenuta tramite queries ad un service registry. Service registry: colleziona le informazioni relative ai servizi/provider e le mette disposizione dei requestor/consumer. 4

5 Web Services - Definizione Un Web Services è un sistema software progettato per supportare l interoperabilità tra diversi elaboratori su di una medesima rete; caratteristica fondamentale di un Web Service è quella di offrire un interfaccia software tramite la quale è possibile interagire con il Web Service stesso attivando le funzionalità, dette operazioni, descritte nell'interfaccia e accessibili via rete tramite messaggi XML standard e protocolli aperti. 5

6 Web Services Stack tecnologico Lo stack tecnologico, sui cui si basano i Web Services, è definito su sei livelli (layers) di tecnologie e standard. Di seguito una figura che mostra tale stack: Stack tecnologico dei Web Services XML: è un metalinguaggio utilizzato per la definizione delle interfacce e la codifica dei messaggi in modo strutturale e semantico. SOAP: è un protocollo di trasmissione utilizzato per lo scambio di messaggi XMLbased. UDDI: è un registry XML-based utilizzato per la pubblicazione, catalogazione e ricerca dei Web Services in base alla propria descrizione WSDL. WSDL: è un linguaggio XML-based utilizzato per la descrizione formale delle interfacce dei Web Services e l accesso ad essi. 6

7 Sicurezza Aspetti generali Oggi è sempre maggiore, in un ambiente composto da sistemi distribuiti, la necessità di avere a disposizione dei meccanismi di sicurezza dei sistemi molto elevati per garantire un alta affidabilità dei servizi che vengono erogato oppure fruiti. In particolare la sicurezza, applicata ai sistemi distribuiti, deve avere i seguenti obiettivi: Autenticazione: è il processo che verifica l identità di una entità coinvolta in una transazione. Autorizzazione: una volta determinata l autenticità di un entità, bisogna verificarne i permessi, vedere quali attività è abilitata a svolgere e a quali risorse può accedere. Integrità dei dati: è il processo che assicura che i messaggi non possono essere intercettati e alterati durante lo scambio fra entità. Privatezza dei dati: i dati non solo non devono essere alterati, ma devono essere letti solo da chi ha il permesso di accedervi. 7

8 WS-Security : sicurezza nei Web Services (1) WS-Security è una specifica che propone un insieme di standard di estensioni del protocollo SOAP che possono essere usati per creare Web Services sicuri, garantendo autenticazione, integrità e confidenzialità a livello di messaggio indipendente dal protocollo di trasporto utilizzato. Di seguito lo stack delle specifiche per la sicurezza nei Web-Services: 8

9 WS-Security : Estensione al messaggio SOAP (2) Estensione alla struttura di un messaggio SOAP contenente le componenti principali di WS-Security : Security tokens: utilizzati per inserire informazioni essenzialmente utilizzate per l autenticazione. UsernameToken BinarySecurityToken Message confidentiality: ottenuto tramite XML Encryption utilizzato per cifrare un messaggio o parte di esso Message integrity: ottenuto tramite XML Signature utilizzato per firmare un messaggio o una o più parti di esso 9

10 Standard SAML E uno standard OASIS con sintassi XML-based utilizzato in particolare per lo scambio di informazioni di autenticazione e autorizzazione, dette asserzioni, tra differenti componenti applicativi e domini. I componenti fondamentali sono: asserzioni: dichiarazioni relative all autenticazione e all autorizzazione di un utente. protocolli (struttura delle informazioni): definiscono opportuni protocolli, basati sul paradigma richiesta/risposta, per lo scambio di asserzioni. binding (modalità di trasporto): indicano il protocollo di trasporto utilizzato per lo scambio di informazioni di sicurezza in SAML. profili: scenari d uso delle asserzioni, protocolli e binding in modo combinato per raggiungere gli scopi degli scenari. 10

11 WS-Security con asserzione SAML Le asserzioni SAML <saml:assertion> vengono incluse nell elemento <security> della specifica WS- Security e definiti come security token. 11

12 AS-IS: Web Services autenticati tramite ticket di sessione Gli attuali Web Services utilizzano un meccanismo di autenticazione e autorizzazione basato su di un servizio di login che restituisce un ticket di sessione ed i profili disponibili per tale utente. Tali informazioni devono essere successivamente inserite nei successivi messaggi SOAP di business. Tale metodologia non è in linea con le attuali specifiche di sicurezza dei Web Services. 12

13 AS-IS: login Nella fase di login, per ottenere il ticket di sessione ed i possibili profili, devono essere inviati i seguenti dati: login: Codice Fiscale Utente password: Password utente 13

14 AS-IS: risultato login Nel messaggio di risposta con successo sono presenti il ticket e un insieme di collaborazioni, dove ogni collaborazione è composta da : Codice fiscale Amministrazione Denominazione Amministrazione Indice della collaborazione: questo indice dovrà essere utilizzato per comunicare agli altri servizi la coppia amministrazione/stazione appaltante di riferimento da usare nelle operazioni di richiesta Denominazione Stazione Appaltante GUID stazione appaltante (codice identificativo interno per i centri di costo) Codice profilo (Amministratore, RUP,.) Ticket di sessione Collaborazione 14

15 AS-IS: richiesta servizio Dopo la fase di ottenimento del ticket, le successive invocazioni dei servizi dovranno utilizzare tale ticket e l indice della collaborazione nei messaggi SOAP. Il destination endpoint esamina il ticket e l indice della collaborazione inviato ed esegue l operazione appropriata. Di seguito un estratto dell invocazione del servizio. ticket Richiesta servizio Indice della Collaborazione 15

16 TO-BE: Web Services con Ws-Security e asserzione SAML Per rendere sicuri i Web Services pre-esistenti si utilizzeranno WS-Security e SAML in modo da introdurre dei meccanismi standard di autenticazione e autorizzazione. Il modello architetturale che si propone è il seguente: 1. RST Username Token/ X.509 Cert. Source endpoint (client) Security token Service 2. RSTR SAML Token 4. Verify SAML Token 3. Request Message SOAP con SAML token Destination endpoint (server) 5. Response Message SOAP 16

17 TO-BE: Request Security Token Il source endpoint che deve inviare un messaggio SOAP, ad un destination endpoint, ottiene un asserzione SAML inviando un messaggio Request Security Token (RST), in cui include un UsernameToken oppure un X.509 Cert per l autenticazione, ad un Security Token Service (STS) ritenuto fidato sia dal source endpoint che dal destination endpoint. UsernameToken Esempio di RST (Request Security Token ) 17

18 TO-BE: Request Security Token Response Verificate le credenziali, l STS invia un messaggio Request Security Token Response (RSTR) contenente un security token di tipo SAML che prova che il source endpoint è autenticato. Inoltre l STS può invocare un AA (Attribute Authority) per ricavare ulteriori informazioni da inserire nell asserzione, come quelle per assegnare i ruoli, utili al processo successivo di autorizzazione. Asserzione SAML Esempio di RSTR (Request Security Token Response) 18

19 TO-BE: Invocazione servizio Ottenuta l asserzione SAML, il source endpoint crea un messaggio SOAP includendo nel SOAP Header un WS-Security Header al cui interno viene inserito il security token di tipo SAML ottenuto in precedenza e lo inoltra al source endpoint per accedere ad uno dei suoi servizi protetto. La chiave referenziata dall asserzione SAML viene usata per creare una firma digitale sui dati del body del messaggio SOAP. Asserzione SAML Richiesta servizio Esempio di invocazione di un servizio con asserzione SAML 19

20 TO-BE: Verifica e abilitazione al servizio Il destination endpoint verifica la firma digitale, valida il token ed in caso positivo abilita l accesso alla risorsa protetta. Le informazioni nell asserzione SAML sono usate per il controllo degli accessi oppure l audit e logging. 20

21 Web Services Architecture: SOA: Architettura a servizi: SOAP: OASIS: Web Service Security: Riferimenti OASIS: SAML V SPCoop Sicurezza: Aspetti%20di%20sicurezza%20nella%20cooperazione%20tra%20i%20servizi_v1%200.pdf Michael P. Papazoglou: Web Services. Principles and Technologies. Pearson Education,