Autenticazione nelle comunicazioni : sicurezza a livello di messaggio


Questo post chiude il ciclo dei tre post dedicati alle tre famiglie di modalità di autenticazione.

  • a livello di canale di comunicazione.
  • a livello applicativo.
  • a livello di messaggio (anche di infrastruttura applicativa).

Oggi ci occuperemo della sicurezza a livello di messaggio, molto comune nelle architetture applicative a servizi.

La diffusione della tecnologia dei web services ed in particolare del protocollo SOAP ha fatto nascere l’esigenza di realizzare una modalità di autenticazione indipendente dal protocollo di comunicazione utilizzato, dipendente solo dal tipo di messaggio inviato (SOAP) e basata su standard indipendenti dall’implementazione tecnologica.

Il protocollo SOAP, alla base dei web services, definisce le modalità base di chiamata dei servizi: indipendentemente dalla piattaforma utilizzata (interoperabilità) e indipendentemente dal protocollo di comunicazione utilizzato (HTTP, TCP, SMTP, MQ,….).

Tali caratteristiche rendono l’utilizzo della modalità di autenticazione a livello di canale non particolarmente idonea al contesto web services sia per problemi di interoperabilità sia per problemi di efficienza (il messaggio SOAP con cui i web services sono chiamati può essere composto da varie sezioni ognuna con requisiti di sicurezza diversi).

Sono nate così delle iniziative atte a definire degli standard multivendor per la sicurezza tra web services e delle iniziative per la realizzazione di framework che offrano a livello infrastrutturale tali standard, come il Microsoft GXA (Global XML Architecture).

image

 

Tra gli standard di sicurezza, WS-Security definisce le regole per l’utilizzo della sicurezza a livello di messaggio.

clip_image002

 

WS-Security definisce, quindi, le modalità per utilizzare a livello di messaggio SOAP l’ integrità, la confidenzialità e l’ autenticazione. L’autenticazione è definita mediante l’utilizzo di security tokens, che essendo gestiti al livello di header SOAP fluiscono tra le varie chiamate. La specifica WS-Security non richie nessun tipo specifico di token, ma consene, in base alle esigenze, di utilizzare token di tipo X509, UsernamePassoword, Kerberos, custom binary, …

La sicurezza nella comunicazione è garantita mediante l’utilizzo:

– di firma digitale per garantire la sicurezza del messaggio;

– di XML encryption per garantirne la confidenzialità.

Le specifiche WS-* sono evolute con il tempo in specifiche mirate a determinati contesti di utilizzo. Attualmente le specifiche WS-Security sono formate da una famiglia di standard che consentono di coprire tutte le esigenze di sicurezza del contesto web services, tra cui, ovviamente, l’autenticazione.

 

Messaging Specifications
SOAP
WS-Addressing
MTOM (Attachments)
WS-Enumeration
WS-Eventing
WS-Transfer
SOAP-over-UDP
SOAP 1.1 Binding for MTOM 1.0

Security Specifications
WS-Security: SOAP Message Security
WS-Security: UsernameToken Profile
WS-Security: X.509 Certificate Token Profile
WS-SecureConversation
WS-SecurityPolicy
WS-Trust
WS-Federation
WS-Federation Active Requestor Profile
WS-Federation Passive Requestor Profile
WS-Security: Kerberos Binding
Web Single Sign-On Interoperability Profile
Web Single Sign-On Metadata Exchange Protocol

Reliable Messaging Specifications
WS-ReliableMessaging

Transaction Specifications
WS-Coordination
WS-AtomicTransaction
WS-BusinessActivity

Metadata Specifications
WSDL
WSDL 1.1 Binding Extension for SOAP 1.2
WS-Policy
WS-PolicyAssertions
WS-PolicyAttachment
WS-Discovery
WS-MetadataExchange

XML Specifications
XML
Namespaces in XML
XML Information Set

Management Specifications
WS-Management
WS-Management Catalog

Business Process Specifications
BPEL4WS

Specification Profiles
Devices Profile
WS-I Basic Profile

Microsoft Open Specification Promise
Microsoft has made a promise relating to the implementation of these specifications at Microsoft Open Specification Promise

 

Quando usarla

WS-Security è alla base della sicurezza nelle comunicazioni tra web services e quindi da usare nei contesti di scambio di messaggi sicuri con web services. Scenari di utilizzo ideali comprendono scambio di messaggi tra web services eterogenei (esposti da piattaforme eterogenee) e dei quali non si ha il diretto controllo di tutti gli end point, degli intermediari e del protocollo di comunicazione.

WS-Security definendo la sicurezza a livello di messaggio è:

  • indipendente dal protocollo di comunicazione utilizzato;
  • indipendente dalla tecnologia utilizzata per l’implementazione dei web services e della piattaforma utilizzata per l’esecuzione;
  • fornisce un sistema di autenticazione (ed in generale security) end to end tra i partner della comunicazione, in grado di supportare anche catene di chiamate ed intermediari;
  • supporta varie tecnologie di encryption e signing dei messaggi.

 

WS-Security (qualche info in più)

In attesa che completi il post della serire "in-pillole" su WS-Security diamo due info di massima.

La prima versione della specifica WS-Security porta la data del 5 Aprile 2002. Questa specifica si occupa di estendere i messaggi SOAP per garantire un meccanismo standard e sicuro per lo scambio di informazioni tra Web Services. Con WS-Security si vuole garantire l’integrità, la confidenzialità e l’autenticazione all’interno di un unico messaggio. Questa specifica è stata pensata come un protocollo completamente indipendente da specifici modelli di sicurezza. Infatti, è in grado di contenere diversi tipi di credenziali come quelle PKI, Kerberos,username e password oltre ad altri standard presenti nel mondo XML-aware comen SAML (Security Assertion M Language) e XrML ( rights M Language).

Tale flessibilità in futuro permetterà alla specifica di evolvere e integrare al suo interno le nuove tecnologie e architetture di sicurezza mantenendo però inalterata la propria struttura e quindi l’interazione con il mondo delle soluzioni applicative. WS-Security introduce alcuni elementi base che compongono la specifica : il claim, il security-token, il proof-of-possession, l’integrità, la confidenzialità, l’hash, la firma digitale.

Il claim rappresenta un oggetto o un privilegio che il client possiede, come ad esempio una chiave, una password, oppure l’appartenenza ad un gruppo.

Il security token è semplicemente un insieme di claim. In questo caso viene fatta una distinzione a seconda che il security token sia firmato come ad esempio un certificato X509V3 o i ticket Kerberos definendo così i “Signed Security Token” .

<s:Envelope xmlns:s=”http://www.w3.org/2001/12/soap-envelope”>
   <s:Header>
      <!—Qui vengono inserite le informazioni di infrastruttura –>
   </s:Header>
   <s:Body>
       <!—Qui vengono inserite le informazioni applicative –>
  </s:Body>
</s:Envelope>

Il proof-of-possession, ovvero, la prova di possesso indica l’azione di controllo che una determinata entità sia a conoscenza di un “segreto”. I restanti elementi, l’integrità, la confidenzialità, l’hash e la firma digitale, fanno farte della sfera di crittografia e come tale WS-Security si basa su specifiche già adottate estendendone, in alcuni casi, l’utilizzo. Ad esempio in XMLDSIG viene definito come legare codice XML a delle chiavi crittografiche, in WS-Security, partendo da queste regole si estendono queste associazioni definendo una relazione tra la firma elettronica e i claim.

 

image

Infine WS-Security definisce un meccanismo generale per trasferire le credenziali tramite un Username Token o un Binary Security Token. Un Username Token indica semplicemente una struttura per inserire nel messaggio SOAP l’informazione del nome utente e opzionalmente della password.

image

La password può non essere inviata nel caso l’architettura lo preveda (ricordo che WS-Security come i Web Services non saranno utilizzati solamente tra comunicazioni tra client e server su Internet ma verosimilmente anche tra componenti appartenenti alla stessa architettura magari all’interno dello stesso troncone di rete, con esigenge di autenticazioni diverse).

Comunque, in questo caso, sarà compito dell’applicazione reperire tutte le informazioni necessarie per compiere un processo di autenticazione ed eventualmente di impersonation. Nel caso la password venga inviata è possibile optare per la password in chiaro o l’hash della password. Resta inteso che ,se la password viene inserita nel token, il program manager dovrà farsi carico di prevedere una qualche forma di trasporto sicuro delle informazioni, come potrebbe essere SSL, nel caso si rimanga solo su HTTP. Il semplice invio dell’ hash della password non è sufficiente a proteggersi da alcuni tipi di attacchi come il replay-attack e il dictionary attack. Per mitigare queste tipologie di attacchi è possibile passare alla funzione di hash non solo la password ma anche delle informazioni di timestamp e un nonce generato on demand. Con il nome di Binary Security Token si indica invece la possibilità di inserire e di effettuare l’encoding in XML di informazioni binarie come i certificati X509 v3 oppure i ticket TGT (Ticket Granting Ticket) e ST (Service Ticket) di Kerberos. Questo tipo di token offre, nella maggior parte degli scenari applicativi, una migliore garanzia di sicurezza.

Per concludere la breve descrizione di WS-Security vorrei sottolineare che, come evidenziato nella parte introduttiva dalla specifica stessa WS-Security da un lato non è in grado di risolvere tutti i problemi di sicurezza delle applicazione basate sui Web Services dall’ altro gli architetti e gli sviluppatori non devono pensare che il semplice utilizzo della specifica all’interno delle loro applicazioni renda automaticamente il prodotto sicuro da ogni attacco possibile. Come sempre avviene per la gestione corretta degli aspetti di sicurezza di applicazioni e architetture, è necessario integrare all’interno del completo ciclo di vita del prodotto un ottimo lavoro di Security Assessment, di Risk Management e di Threat analysis.

 

–Mario


Comments (2)

  1. “In evolutionary terms, the information security field is more than a decade behind software development”

Skip to main content