Security & Architecture : Specifiche di Base

WS-Discovery enhanced

mfontana — Tue, 13 Oct 2009 07:23:42 GMT

Continua la saga su WS-Discovery scritta sempre da Alessio Mannelli. Per chi si fosse perso la prima puntata può leggerla qui.

Recap

Ben ritrovati in questa serie di post dedicati alla specifica WS-Discovery. Nella puntata precedente abbiamo fatto conoscenza del modello, dei messaggi e delle interazioni basiche fondamento della specifica.

Abilitare scenari di composizione dinamica, sia a design-time, ma soprattutto a runtime, sono il fulcro alla base della specifica.

In questa nuova puntata andremo a conoscere il supporto di rete previsto in WS-Discovey, il Discovery Proxy, come gestire il concetto degli Scopes, ed introdurremmo gli scenari applicativi che implementeremo nella prossima puntata della serie WS-Discovery.

Supporto di rete

Abbiamo già visto nella prima puntata le due modalità operative presenti in WS-Discovery, ad-hoc e managed. La prima si basa completamente sullo scambio di messaggi in Multicast per tutte le peculiarità di Discovery (Hello/Bye/Probe/Match e relative *Resolve), la seconda si basa sulla presenza di un servizio di rete, denominato Discovery Proxy, al quale inviare i messaggi di ricerca (Probe e Resolve).

La specifica identifica le seguenti definizioni per l’invio di messaggi in multicast:

· DISCOVERY_PORT: port 3702

· IPv4 multicast address: 239.255.255.250

· IPv6 multicast address: FF02::C (link-local scope)

I messaggi multicast devono essere inviati utilizzando SOAP over UDP.

Quando la modalità operativa utilizzata è quella ad-hoc, tutti i messaggi di richiesta devono essere inviati come sopra definito, mentre tutte le risposte verranno inviate in unicast al client che ha inviato i messaggi. Per comunicare in unicast verso il client vi sono due possibilità:

· Il client aggiunge un indirizzo di risposta sfruttando l’header di Addressing ReplyTo .

· Il server utilizza l’indirizzo IP e la porta sorgente della connessione UDP ricevuta per rispondere al client.

Nella modalità operativa managed il client dialoga con il Discovery Proxy in unicast, sia in richiesta che in risposta.

Client e Discovery Proxy

Il Discovery Proxy, come già descritto, è alla base della modalità operativa cosiddetta managed.

Un client, se non diversamente istruito, si trova normalmente in un stato nel quale non conosce Discovery Proxy; è possibile, chiaramente che riceva un Hello dal Discovery Proxy, riconoscibile da uno specifico Service Type che lo contraddistingue (d:DiscoveryProxy) nel qual caso modificherà radicalmente il modo con il quale invia richieste di Probe e Resolve, secondo il diagramma a stati sotto descritto:

Quindi, una volta che il client si trova a conoscere un Discovery Proxy comunicherà con lo stesso in modalità unicast, evitando quindi di congestionare la rete con messaggi in multicast.

Un DiscoveryProxy, di contro, quando riceve un messaggio di Probe o Resolve in multicast è tenuto a spedire subito un messaggio di Hello (in multicast a sua volta): questo particolare messaggio modifica lo stato dei client in modo tale che utilizzino solamente i Discovery Proxy di cui si fidano, ed ingnorino di contro i messaggi in multicast dei Target Service.

A questo punto sia i Client che i Target Service indirizzeranno le loro comunicazioni (di ricerca, per il client, di connessione/disconnessione dalla rete, per i servizi) al Discovery Proxy. Eventualmente i messaggi di connessione/disconnessione (Hello/Bye) potranno essere inviati ancora in multicast, da parte dei Target Service: il loro peso specifico è talmente basso, cosi come il numero di messaggi inviati, da essere praticamente trascurabili in uno scenario reale.

Tra i vantaggi di avere un’infrastruttura di Discovery managed vi è anche la possibilità di scavalcare il limite di utilizzo delle comunicazioni multicast (overhead di gestione del routing del protocollo fra tutti): inserire alcuni Discovery Proxy tra le varie sottoreti, e sfruttare il modello di discovery, può portare ad allargare gli orizzonti del proprio ambiente operativo.

In questo modo i client possono trovare ed utilizzare servizi non presenti nelle loro sottoreti, senza rendere difficoltosa la gestione dell’infrastruttura.

Scopes

Come già accennato, gli scopes, di seguito indicati anche come “ambiti”, possono caratterizzare un servizio nel mondo di WS-Discovery. La specifica identifica solamente i metodi specifici con i quali un Target Service deve confrontare i suoi ambiti, con quelli richiesti dal messaggio di Probe ricevuto, per rispondere, eventualmente, con un messaggio di Match (Probe o Request). Ripetiamo la lista dei modelli di confronto utilizzabili, per riferimento:

· http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/rfc3986

· http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/uuid

· http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/ldap

· http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/strcmp0

· http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/none

Per maggiori informazioni sugli stessi il capitolo 5 della specifica entra nei dettagli di ogni modello.

Scenari applicativi di utilizzo di WS-Discovery

Fino a qui abbiamo praticamente visto tutti gli aspetti peculiari della specifica WS-Discovery, cerchiamo adesso di focalizzare l’utilizzo della stessa nel mondo reale, proponendo alcuni scenari che normalmente si propongono in un ambiente orientato ai servizi, e che elaboreremo nella prossima puntata:

1. Ricerca a runtime di un servizio che implementa l’interfaccia che ci interessa.

2. Ricerca a runtime di un servizio che, oltre ad implementare l’interfaccia richiesta, è configurato con uno scope specifico.

Il primo scenario è il più frequente in ambito composizione : configurazione degli indirizzi fisici utilizzati dai servizi nei diversi “ambienti operativi” nei quali l’ applicazione verrà eseguita (sviluppo, pre-produzione, produzione e chi più ne ha più ne metta). Il vantaggio che deriva dall’utilizzo di WS-Discovery come asset fondamentale di tutti i servizi e le applicazioni è evidente: ad ogni modifica di “ambiente operativo” l’applicazione ricercherà il servizio specifico ed utilizzerà l’indirizzo recuperato a runtime per il colloquio.

Chiaramente vi possono essere degli accorgimenti capaci di evitare il “dispendio” di messaggi che la ricerca di un’istanza di servizio può aggiungere all’economia del colloquio applicazione – servizio. Talvolta il peso è trascurabile, quando ad esempio il client ha un ciclo di vita molto elevato, tale per cui il peso aggiunto diventa infinitesimale rispetto al resto del peso di comunicazione; altre volte invece è necessario salvare l’indirizzo del servizio recuperato tramite utilizzo di WS-Discovery per poi riutilizzarlo al riavvio dell’applicazione. In questo modo vi è la possibilità che il servizio recuperato in precedenza non sia più “vivo”, nel qual caso si potrà procedere con una nuova interazione Probe – ProbeMatch.

Il secondo scenario è il più “ambizioso” in determinati contesti. Ipotizziamo di avere alcune istanze di uno specifico servizio, distribuite in modo tale da coprire più segmenti della topologia di rete in esame. Per esempio potremmo avere un servizio locale su una macchina, un servizio su una LAN particolare , ed un servizio al centro. Tutti e tre i servizi implementano la stessa interfaccia e gestiscono gli stessi dati ma, data la loro differente collocazione geografica hanno uno SLA (service level agreement) diverso a seconda dei dati che vengono richiesti.

Facciamo un esempio : il servizio locale alla mia macchina avrà lo stato completo dei dati che si generano dalla macchina stessa, il servizio interno alla LAN ha lo stato completo dei dati che si generano all’interno della LAN stessa, e per finire il servizio al centro ha lo stato completo dei dati che si generano fuori dal contesto applicativo specifico. Ogni “livello” diverso si sincronizza e coordina con gli altri tramite un ulteriore flusso dati (che non analizziamo) che rende possibile, con tempi diversi, l’allineamento dei dati su tutte le istanze del servizio ipotizzato.

A questo punto l’applicazione deve capire se e come le tre diverse istanze di servizio possono aiutarlo nell’esecuzione delle sue funzioni. In alcuni casi un servizio fisicamente “vicino” al client può essere un aiuto, se non altro per il ridotto round trip di rete dell’invocazione. Altrimenti, se l’applicazione capisce di avere necessità di dati con specifico SLA può ricercare uno dei servizi specifici.

Bene, l’utilizzo degli scopes, in questo caso, è l’ausilio tecnico alla problematica. Ogni diversa istanza di servizio viene configurata in diversi ambiti (scopes, per l’appunto). In contesti gerarchici, come l’esempio illustrato, gli scopes possono essere definiti con una convenzione come la seguente:

· Servizio al centro rende disponibile lo scope http://ROOT

· Servizio di “filiale” rende disponibile lo scope http://ROOT/BRANCH

· Servizio locale rende disponibile lo scope http://ROOT/BRANCH/MACHINE

In questo scenario si possono poi utilizzare diverse tipologie di confronto tra gli scopes: la tipologia di esatta comparazione delle stringhe, ad esempio, restituirà solo uno delle tre istanze di servizio, piuttosto che la versione RFC3986, la quale restituisce una istanza se almeno uno dei sotto livelli della risorsa richiesta è confrontabile con quello richiesto; in questo caso se chiedo lo scope ROOT, tutti e tre i servizi dell’esempio risponderanno con i loro dettagli.

Tutto dipende da quali sono le necessità applicative, ma le prospettive offerte dall’infrastruttura sono molto interessanti, e flessibili.

Conclusioni

Con questo secondo post abbiamo esaurito l’overview della specifica, e definito alcuni scenari che reputo interessanti e che saranno la base del terzo ed ultimo post della serie WS-DISCOVERY. Analizzeremo l’implementazione di WS-Discovery inserito nella nuova versione del .Net Framework 4.0, attualmente in versione Beta, e realizzeremo gli scenari proposti. Per avvantaggiarvi vi consiglio di leggere e sottoscrivere http://blogs.msdn.com/discovery/, ne avremo bisogno!

A presto,

Alessio

Understanding WS-Discovery

mfontana — Thu, 23 Jul 2009 20:04:02 GMT

Da oggi e per i prossimi mesi ogni tanto ospiterò dei post scritti da alcuni colleghi/amici di Microsoft affinchè possano raccontare un po’ della loro expertise e competenza tecnica ottenuta durante le tante attività di consulenza e di supporto sul campo. Ovviamente il tema sarà sempre inerente le architetture applicative e la sicurezza…

In questo post iniziamo con Alessio Mannelli (nella foto, l’unica decente che ho trovato :-)!
Non è la prima volta che parla su questo “canale”… vi ricordate quell’Alessio Mannelli con il quale quasi un anno fa facemmo un video dove spiegava il funzionamento dei Security Token Services ?? Ebbene si, è sempre lui :-) Alessio lavora nella divisione servizi in Microsoft Italia come Senior Developer ed oramai ha un pluriennale esperienza di implementazioni di soluzioni SOA nell’enterprise.

Quindi, non mi dilungo ulteriormente in ciancie e passo la palla ad Alessio per la prima puntata sulla specifica WS-Discovery che tra l’altro è appena stata rettificata come standard OASIS ed è presente nel framework .NET 4.0…

--Mario

La Missione

Tra le tante specifiche che regolano il variegato mondo dei Web Services WS-Discovery è sicuramente una delle più ambiziose:

definire un modello standard per la localizzazione di “servizi”, un modello per essere informati quando un nuovo “servizio” viene fatto partire e quando un “servizio” viene spento.

Un modello quindi per effettuare ricerche di “servizi” e recuperarne caratteristiche specifiche come gli endpoint con i quali è possibile dialogare con gli stessi, i protocolli utilizzabili, e molto altro ancora.

Il modello di Discovery è, o sta diventando, necessario in un mondo dove la “composabilità” delle applicazioni diventa asset fondamentale dell’ecosistema applicativo di una azienda; applicazioni dinamiche per loro natura che, semplicemente, è impossibile connettere a design-time oppure a deployment-time; c’è sicuramente necessità di un modello di “connessione” dinamica a runtime, un modello che valorizzi tutti gli asset di una azienda.

WS-Discovery è anche un facilitatore di scenari dove trovare ed utilizzare servizi all’interno o all’esterno dell’azienda diventa sempre più difficile; strutture verticali aziendali non allineate, poca (talvolta nessuna) Governance dei programmi e progetti in corso, molti fornitori, sono tra le problematiche più classiche che portano alla proliferazione e conseguente non riutilizzo di Web Service.

Per ultimo Discovery si pone l’obiettivo di abbracciare sempre più “elementi” non tradizionali di un modello di software a servizi: stampanti, device RFID, macchine fotografiche digitali, proiettori.

La possibilità di utilizzare un sistema leggero, dinamico, interoperabile per la costruzione di applicazioni composte e distribuite è fondamento della specifica WS-Discovery.

Un servizio “Discoverabile”

Per la specifica WS-Discovery ogni servizio viene identificato sulla base di quattro caratteristiche fondamentali:

- EndpointReference (definito in WS-Addressing)

Un indirizzo che identifichi univocamente il servizio specifico. L’indirizzo non deve essere per forza un indirizzo fisico, anzi la specifica consiglia l’utilizzo di indirizzi logici (eg. Un identificatore universale univoco, GUID, UUID)

- Types (definito in WS-Discovery)

Ogni servizio web implementa uno o più tipologie di portType, cosi come definito dalla specifica di WSDL 1.1: la nomenclatura utilizzata è di tipo Namespace:ServiceTypeName e quasi sempre viene inferita dalle specificità dei contratti implementati nei servizi.

- Scopes (definito in WS-Discovery)

Ogni servizio può identificare uno o più ambiti o contesti nei quali esiste o per i quali è stato configurato.

- XAddrs (definito in WS-Discovery)

Tutti gli indirizzi sui quali il servizio specifico è raggiungibile ed invocabile. Abbiamo quindi un modello per definire completamente uno specifico Servizio:

EndpointReference, l’identificatore univoco

Types, le tipologie di “contratti” che il servizio implementa
Scopes, i contesti applicativi del servizio
XAddrs, gli indirizzi sui quali il servizio è raggiungibile ed invocabile.

<a:EndpointReference>
<a:Address>
     uuid:98190dc2-0890-4ef8-ac9a-5940995e6119
</a:Address>
</a:EndpointReference>
<d:Types>i:PrintBasic i:PrintAdvanced</d:Types>
<d:Scopes>
   ldap:///ou=engineering,o=examplecom,c=us
   ldap:///ou=floor1,ou=b42,ou=anytown,o=examplecom,c=us
   http://itdept/imaging/deployment/2004-12-04
</d:Scopes>
<d:XAddrs>http://prn-example/PRN42/b42-1668-a</d:XAddrs>

Il modello di Discovery

La specifica WS-Discovery definisce sei messaggi specifici:

- Hello/Bye – messaggi utilizzati da un servizio per annunciare la sua presenza (Hello) o la sua “dipartita” (Bye).

- Probe/ProbeMatch – Probe viene utilizzato per cercare uno specifico tipo di servizio, ProbeMatch viene utilizzato in risposta alla richiesta.

- Resolve/ResolveMatch – Resolve viene utilizzato per cercare una specifica istanza di servizio, ResolveMatch viene utilizzata in risposta alla richiesta.

Lo scenario di base prevede che i servizi annuncino la loro operatività e quando possibile il loro “scollegamento” dalla rete.(chiaramente nei casi in cui un servizio si spenga per casi eccezionali, difficilmente può inviare un messaggio di Bye, e la specifica non è giustamente prescrittiva in questo senso…)

Figura 1 : Hello e Bye Messages

In figura 1, viene rappresentato lo scenario di base dove l’ipotetico Client riceve i messaggi di Hello dai servizi WS1 e WS2 cosi come riceve il messaggio di Bye dal servizio WS3, il quale nel frattempo si è scollegato dalla rete. Il Client potrà quindi utilizzare le informazioni presenti nei messaggi di protocollo per selezionare il servizio da contattare, qual’ora, chiaramente, implementi le tipologie di servizio richieste.

Quando invece un Client si connette ad una rete, ed è interessato ad uno specifico servizio, può utilizzare i messaggi di protocollo Probe e/o Resolve:

Figura 2 : Probe/Resolve e ProbeMatch/ResolveMath Messages

In figura 2 invece il Client ricerca uno specifico servizio e solo due dei tre servizi presenti e connessi alla rete rispondo con un messaggio di Match. E’ da notare che, nello scenario definito, la richiesta di Resolve difficilmente verrà inviata: ricordiamoci infatti che Resolve serve per richiedere i dati di una specifica istanza di servizio, a differenza di Probe che ricerca istanze generiche che implementino specifiche tipologie di servizio. In questo caso il messaggio di Resolve potrebbe essere utilizzato nel caso in cui, dopo aver ricevuto un ProbeMatch alcune informazioni specifiche (tipo gli indirizzi per il dialogo) non fossero presenti.

Le modalità operative

Le modalità operative definite dalla specifica sono la “ad-hoc” e la modalità “managed”.

La modalità “ad-hoc” non utilizza nessun servizio di rete né server; i messaggi di Hello/Bye/Probe/Resolve vengono inviati in multicast (le relative risposte, dove necessarie, vengono inviate in modalità unicast al client che ha effettuato la richiesta).

La modalità “managed” è supportata da un servizio di rete, denominato Discovery Proxy, che funge da accentratore dei servizi presenti nell’ambiente, e che opera per conto loro nel rispondere alle richieste. Riprenderemo il concetto di Discovery Proxy in un prossimo post, poiché merita sicuramente un approfondimento.

Conclusioni

In questo primo post abbiamo solamente scalfito la superficie della specifica WS-Discovery: vi sono tutta una serie di concetti e di peculiarità proprie della specifica che verranno riprese nella prossima puntata.

Saluti,

Alessio Mannelli

Microsoft, Apache… un ossimoro??

mfontana — Sun, 07 Jun 2009 11:06:00 GMT

Innanzitutto prima di generare uno sciopone a qualcuno vi prego di notare la punteggiatura nel titolo di questo post !!! Microsoft VIRGOLA Apache e non Microsoft Apache :-) Nessuna paura quindi , non abbiamo acquistato Apache !!!! Però c’è da dire che questa notizia, come architetto, mi ha reso proprio contento. Alzi la mano (tanto vi vedo) chi di voi si è trovato almeno una volta nella situazione di far parlare del codice .NET con quello JAVA e/o PHP o viceversa? E tenga su la mano chi ha incontrato qualche “piccolissima” difficoltà nella configurazione e settaggi vari nei rispettivi ambienti !!!! Nessuno ?? ok allora questo post non fa per voi :-)

Diciamo che c’è stato un evento epocale… Microsoft partecipa alla keynote della conferenza JavaOne!! Infatti durante la conferenza JavaOne Steven Martin - Senior Director, Developer Platform Product Management – e Aisling MacRunnels - Sun Vice President- hanno annunciato durante la keynote che Sun parteciperà attivamente al progetto open-source Stonehenge inizialmente creato da Microsoft, WS02, University of Moratuwa, Progress Software, Red Hat e Eviware. In particolare Sun si occuperà della realizzazione Java/Metro della soluzione StockTrader.

Microsoft (anche se molti non lo sanno) ha partecipato e sta partecipando a molti progetti open source ma questa è la prima volta che Microsoft partecipa come code contributor in un progetto Apache!!

Lo scopo di questo progetto è nobile : realizzare in concreto degli scenari di interoperabilità e di best practices tra applicazioni e web services sviluppati su stack tecnologici diveri. Come dissi in questo mio post “non basta avere delle specifiche standardizzate per realizzare veramente degli scenari di interoperabilità” (sintetizzato) !!! I motivi sono molteplici : non tutti i vendor implementano le medesime specifiche anche se standardizzate, non sempre è chiaro come configurare i vari ambienti e prodotti, spesso ci sono delle piccole differenze in termini di serializzazione, encoding che se non gestite possono rendere difficile la realizzazione del progetto…

Per questo motivo il progetto Stonehenge realizza delle applicazioni di esempio basate su stack Java, .NET, PHP ma anche Python e Ruby in grado di interoperare utilizzando un set comune di specifiche standard definte dal W3C e OASIS. Stiamo parlando in prevalenza di comunicazioni basate sugli standard WS-*. I vari sorgenti li potete trovare nel repository di stocktrader :

--Mario

Ci vediamo a ROMA??

mfontana — Fri, 06 Feb 2009 20:41:04 GMT

Il 16-17-18 Marzo a ROMA si tiene la prima edizione della conferenza BASTA! Italia. La più prestigiosa conferenza sullo sviluppo .NET tedesca sbarca in Italia !!

Il 17 mattina terrò una sessione dal titolo : Make your old applications SOA-aware with Web Services API. From Windows XP/2003 to Windows 7/2008 R2.dove parlerò della nuova architettura per i Web Services presenti nelle prossime versioni del sistema operativo Windows 7 e Windows Server 2008 R2. Sarà una sessione di livelllo 400 (Expert) per dare un po’ di internals e capire come queste API unmanged possono essere utilizzate in architetture SOA e in particolare con servizi WCF/Asmx . Per dare un po’ di background sull’argomento nei prossimi giorni pubblicherò una serie di link introduttivi. Farò comunque i primi 10 min della presentazione una overview di massima.

L’abstract:

Con Windows 7 e Windows Server 2008 R2 il sistema operativo si arricchisce di nuove API native (WWSAPI – Windows Web Services API) che permettono di estendere le applicazioni unmanaged verso le architetture a servizi.Analizzeremo le ragioni di queste nuove API, l’architettura, le possibilità di interoperabilità con il mondo .NET e Java, e i principali standard WS-* di riferimento implementati.Tramite varie demo scorreremo i principali scenari di utilizzo evidenziandone i pro e i contro.

--Mario

Come funzionano i Security Token Services.

mfontana — Mon, 29 Sep 2008 09:10:01 GMT

Oggi per la serie MSDN Talks siamo in compagnia di Alessio Mannelli - Senior Developer - della divisione Servizi di Microsoft Italia. Con Alessio negli anni passati abbiamo speso insieme parecchio tempo nella definizione e realizzazione di infrastrutture applicative (a partire da WSE 2.0) fino ad arrivare ai giorni più recenti con WCF (WIndows Communicatino Foundation). In questo breve video Alessio ci parlerà dei meccanismi di autenticazione tra servizi nei modelli definiti da WS-Security, WS-Trust e SAML 1.1. Particolare attenzione viene posta al concetto di Authority (detto anche STS - Security Token Service). Questa breve introduzione teorica sull'argomentè essenziale per capire scenari più complessi di Single-Sign-On in architetture SOA. Inoltre, i meccasismi spiegati da Alessio sono i medesimi che troviamo in tecnologie come ADFS (Active Directory Federation Services), CardSpace, nel nuovo Zermatt (di cui parleremo a breve) e nelle future tecnologie che verranno presentati tra poco al PDC.

L’authority gestisce il riconoscimento dei chiamanti e la profilazione degli utenti sui servizi offrendo al sistema un punto centrale per la gestione delle politiche di sicurezza. Il chiamante prima di poter effettuare una richiesta al servizio deve autenticarsi presso l’authority e farsi rilasciare un ticket di accesso al servizio richiesto.

L’autenticazione presso l’authority avviene mediante l’invio dell'identità del servizio client che può essere espressa sotto varie forme: credenziali di rete, credenziali custom, certificati X509 oppure Ticket Granting Ticket (TGT) preventivamente rilasciati dalla stessa authority.

Alessio, ci parlerà prevalentemente del modello di autenticazione di un servizio tramite certificati X509. L’utilizzo di certificati X509 consente di realizzare un’infrastruttura di sicurezza basata su algoritmi asimmetrici che utilizzano chiavi pubbliche e private per firmare e criptare le comunicazioni verso l’authority.

Lo scenario basato sull’utilizzo di certificati X509 richiede la presenza di una Certification Authority (interna o esterna all'azienda) riconosciuta da tutte le entità dell’infrastruttura che rilascia certificati X509 per l’identificazione dei vari attori e per l’utilizzo degli algoritmi di crittografia e firma. Ad ogni componente (chiamante, servizio e authority) è associato uno specifico certificato. La specifica WS-Trust definisce come i servizi in gioco possano autenticarsi tra loro. Riassumento lo scenario descritto da Alessio avremo :

1) il servizio/applicazione chiamante si autentica all'authority via X509. In questo contesto la specifica WS-TRust definisce un tipo di messaggio chiamato RST (Request Security Token).

2) l'authority autentica il servizio/applicazione client, verifica le policy autorizzative e crea un nuovo security token di tipo SAML che descrive l'identity del client ed eventuali informazioni aggiuntive sui ruoli e applicative.In questo contesto la specifica WS-TRust definisce un tipo di messaggio chiamato RSTR (Request Security Token Response).

3) Il chiamante passa il security token di tipo SAML al servizio target che può effettuare la verifica dell' identità del client e procedere all'esecuzione del processo di business.

Buona visione

--Mario

Cosa intendiamo per Infrastruttura Applicativa

mfontana — Tue, 22 Apr 2008 10:20:00 GMT

L’ Infrastruttura applicativa può essere vista come l’estensione dell’infrastruttura sistemistica capace di offrire servizi ad un insieme controllato di applicazioni.

Questa infrastruttura è un insieme di componenti e servizi che consentono alle applicazioni di comunicare con altrettanti servizi (sia locali che remoti).
L’ Infrastruttura applicativa si occupa qindi di fornire delle funzionalità di base ed avanzate che siano trasversali alle applicazioni oltre ad un insieme di regole sulla modalità di comunicazione che deve essere utilizzata da e per ciascun servizio, rendendo questi dettagli trasparenti alle applicazioni:

I servizi di base sono ad esempio Autenticazione, Autorizzazione, Identity Flow, Logging, Instrumentation, Discovery, ecc.. mentre i servizi avanzati (o di runtime) possono essere : Mail, Fax, Extarnal Services, ecc..

L’utilizzo dei servizi consente di realizzare un sistema secondo i canoni Services Oriented Architecture (SOA) rendendo omogenei e interoperabili i servizi esposti dall’enterprise. SOA sfrutta gli standard di mercato come XML/SOAP e WS-* come definizione delle caratteristiche a cui i servizi esposti aderiscono per consentire comunicazioni sicure, scalabili, reliable, interoperabili, …

Le specifiche WS-*, però, definiscono solo le caratteristiche a cui i WS devono sottostare, lasciando l’implementazione libera. In ambito Enterprise tale libertà introduce la necessità di realizzare un’infrastruttura (o framework) che implementi i servizi base di WS-* mettendoli a disposizione dei WS in modo semplice e trasparente. Rendere i servizi sviluppati indipendenti da quelli base è inoltre garanzia di evoluzione: l’infrastruttura di base è in grado di evolvere seguendo i nuovi standard senza richiedere la modifica dei servizi sviluppati. La presenza di un framework, quindi, consente di poter realizzare una parte fondamentale della SOA disaccoppiando le applicazioni di business dalle caratteristiche d'infrastruttura creando un sistema omogeneo, aderente agli standard, facile da manutenere e da evolvere.

L’ Infrastruttura applicativa dovrà inoltre consentire l’implementazione di differenti Message Exchange Pattern (MEP) attraverso tipologie di contratti differenti come ad esempio :

Request/Reply
OneWay
Duplex

L’ Infrastruttura applicativa fornisce quindi dei servizi a valore aggiunto utilizzabili per tutti i servizi definiti all’interno ed all’esterno dell' Enterprise (sia servizi di basso livello sia servizi di business veri e propri), consentendo al programmatore applicativo di concentrarsi sulla logica della funzionalità specifica senza preoccuparsi della parte infrastrutturale. Inoltre consente di separare gli aspetti di gestione e configurazione dal codice di ciascuna funzionalità, permettendo a chi gestisce l’applicazione di modificare le caratteristiche infrastrutturali senza ricompilare l’applicazione. All’interno dei servizi di base l’ Infrastruttura applicativa è in grado di fornire anche le seguenti funzionalità a valore aggiunto:

Trasporto di informazioni di contesto indipendenti dai singoli servizi.
Caching dei dati restituiti dai servizi
Monitoraggio della comunicazione (tracing, performance counters)
Indipendenza dei chiamanti dalla locazione fisica dei servizi (indirizzamento dinamico)
Gestione centralizzata delle policies ed autoconfigurazione degli endpoint

prossiamanente vediamo come progettare e realizzare una infrastruttura applicativa con .NET

--Mario

Rese pubbliche le specifiche dei formati binari di Office 97-2007

mfontana — Sun, 17 Feb 2008 22:10:19 GMT

Da ieri sul sito di interop di Microsoft sono disponibili le specifiche del formato binario di Office 97-2000-2003-XP-2007. Questo permette a chiunque di utilizzare liberamente anche il formato binario, oltre a quello XML-based presente in Office 2007, in aderenza alla Microsoft Open Specification Promise.

Le specifiche coprono i seguenti prodotti/tecnologie : Word, Excel, PowerPoint, Office Drawing, Windows Compound Binary File Format Specification,Windows Metafile Format (.wmf) Specification ed infine Ink Serialized Format (ISF) Specification.

--Mario

Specifiche di base: XML Encryption in pillole...

mfontana — Thu, 22 Nov 2007 13:52:23 GMT

La specifica XML Encryption [XMLENC xmlns:xenc='http://www.w3.org/2001/04/xmlenc#' ] ha il compito di definire la sintassi e il processo per cifrare dei dati binari o testuali e rappresentarli in formato XML. La struttura XML della specifica si basa sull’elemento EncryptedData :

<EncryptedData Id? Type? MimeType? Encoding?>
    <EncryptionMethod/>?
    <ds:KeyInfo>
      <EncryptedKey>?
      <AgreementMethod>?
      <ds:KeyName>?
      <ds:RetrievalMethod>?
      <ds:*>?
    </ds:KeyInfo>?
    <CipherData>
      <CipherValue>?
      <CipherReference URI?>?
    </CipherData>
    <EncryptionProperties>?
  </EncryptedData>

il quale può contenere o referenziare il documento cifrato (o ciphertext) permettendo due modalità diverse di rappresentazione : Enveloping e Detached.

Nel primo caso è presente l’elemento CipherValue che contiene il ciphertext espresso in Base64 mentre nel secondo caso l’elemento CipherReference punta ad una locazione dove è presente il ciphertext. In questo caso è stato utilizzato il termine Detached encryption e non Enveloped encryption perchè in crittografia Enveloped encryption ha un significato diverso. Infatti Enveloped Encryption viene utilizzato per definire una operazione di cifratura un pò più complessa. Il testo in chiaro (o plaintext) viene cifrato con una chiave simmetrica (detta di sessione) generando un ciphertext. La chiave di sessione appena utilizzata (e generata) per l’encryption viene cifrata a sua volta da un’altra chiave (asimmetrica). La cifratura della chiave di sessione avviene tramite la chiave pubblica del destinatario (inteso come l’entità che deve decifrare il messaggio). Il ciphertext e la chiave di sessione cifrata devono essere presenti entrambi durante la fase di decryption possibile solo dal possessore della chiave privata associata.

EncryptionMethod è un elemento opzionale che indica quale algoritmo crittografico è stato utilizzato per le operazioni di cifratura. Nel caso questo elemento non fosse presente, il compito di ottenere tali informazioni è demandato al livello applicativo. In tabella 1 è presente uno schema riassuntivo degli algoritmi supportati dalla specifica.

Tabella 1.

L’elemento KeyInfo serve per rappresentare le informazioni inerenti le chiavi di cifratura. Si noti che tale elemento è preceduto dal namespace ds (xmlns:ds='http://www.w3.org/2000/09/xmldsig#) della specifica [XMLDSIG]. Questo indica che le regole riguardanti questo elemento appartengono alla specifica di firma digitale. Per un maggiore dettaglio sull’argomento consultare la specifica [XMLDSIG] mentre per le possibili estensioni consultare la specifica [XMLENC].

Un ’estensione importante è data dall’elemento EncryptedKey.

<element name='EncryptedKey' type='xenc:EncryptedKeyType'/>
  <complexType name='EncryptedKeyType'>
    <complexContent>
      <extension base='xenc:EncryptedType'>
        <sequence>
          <element ref='xenc:ReferenceList' minOccurs='0'/>
          <element name='CarriedKeyName' type='string' minOccurs='0'/>
        </sequence>
        <attribute name='Recipient' type='string' use='optional'/>
      </extension>
    </complexContent>   
  </complexType>

Tale elemento viene impiegato per la distribuzione delle chiavi simmetriche tramite il pattern definito in Enveloped Encryption, dove la chiave simmetrica viene cifrata per ogni destinatario con un’altra chiave (chiave pubblica). EncryptedKey può essere inserito come figlio di ds:KeyInfo, come documento XML disgiunto, oppure come elemento all’interno dello stesso documento XML contenente un ds:KeyInfo.

Il sottoelemento opzionale ReferenceList indica quali chiavi simmetriche sono state cifrate mentre CarriedKeyName e Recipient danno ulteriori informazioni al contesto applicativo per individuare la chiave di cifratura.

L’elemento CipherData è un dato obbligatorio e referenzia o contiene il ciphertext che sostituisce l’informazione in chiaro. Lo schema di CipherData indica che sono possibili due valori : CipherValue e CipherReference

<element name='CipherData' type='xenc:CipherDataType'/>
  <complexType name='CipherDataType'>
     <choice>
       <element name='CipherValue' type='base64Binary'/>
       <element ref='xenc:CipherReference'/>
     </choice>
   </complexType>

L’elemento CipherValue rappresenta il ciphertext in formato Base64 mentre CipherReference è un riferimento al ciphertext puntato tramite l’attributo URI.

<element name='CipherReference' type='xenc:CipherReferenceType'/>
   <complexType name='CipherReferenceType'>
       <sequence>
         <element name='Transforms' type='xenc:TransformsType' minOccurs='0'/>
       </sequence>
       <attribute name='URI' type='anyURI' use='required'/>
   </complexType>

   <complexType name='TransformsType'>
      <sequence>
        <element ref='ds:Transform' maxOccurs='unbounded'/> 
      </sequence>
   </complexType>

Anche in questo caso, come in [XMLDSIG] è possibile effettuare delle trasformazioni per processare i dati. Le operazioni di trasformazione però sono state concepite in modo diverso rispetto alla specifica di firma digitale. Infatti in [XMLDSIG] il processo di generazione e di validazione utilizza sempre gli stessi dati di input (sempre il plaintext) ed applica le trasformazioni nello stesso ordine.Vicecersa, in [XMLENC], le operazioni di cifratura e decifratura partono da input diversi (rispettivamente il plaintext e il ciphertext) e la specifica indica che l’ordine in cui sono impostate le trasformazioni sono da intendersi solo per l’operazione di decifratura. Questo significa che durante la fase di cifratura le operazioni vengono svolte nell’ordine inverso. A causa di queste diversità il sottoelemento Transforms è definito all’interno del namespace di [XMLENC].

Infine l’ultimo elemento opzionale di EncryptedData è EncryptionProperties che rappresenta un insieme di informazioni aggiuntive per l’applicazione di decrypt come ad esempio il timestamp o informazioni rigurdanti device crittografici o settaggi software per la decifratura.

In seguito sono riportati alcuni esempi di applicazione , tratti dalla specifica, di questa RFC a porzioni di documenti XML:

<PaymentInfo xmlns='http://example.org/paymentv2'>
    <Name>John Smith</Name>
    <CreditCard Limit='5,000' Currency='USD'>
      <Number>4019 2445 0277 5567</Number>
      <Issuer>Example Bank</Issuer>
      <Expiration>04/02</Expiration>
    </CreditCard>
</PaymentInfo>



<PaymentInfo xmlns='http://example.org/paymentv2'>
    <Name>John Smith</Name>
    <EncryptedData Type='http://www.w3.org/2001/04/xmlenc#Element'
    xmlns='http://www.w3.org/2001/04/xmlenc#'>
      <CipherData>
        <CipherValue>A23B45C56</CipherValue>
      </CipherData>
    </EncryptedData>
</PaymentInfo>



<PaymentInfo xmlns='http://example.org/paymentv2'>
    <Name>John Smith</Name>
    <CreditCard Limit='5,000' Currency='USD'>
      <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'
      Type='http://www.w3.org/2001/04/xmlenc#Content'>
        <CipherData>
          <CipherValue>A23B45C56</CipherValue>
        </CipherData>
      </EncryptedData>
    </CreditCard>
</PaymentInfo>

Esempio di cifratura secondo il pattern Enveloped Encryption.

<S:Envelope
   xmlns:S="http://www.w3.org/2001/12/soap-envelope"
   xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
   xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/04/secext"
   xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
  <S:Header>
    <wsse:Security>
      <xenc:EncryptedKey>
        <xenc:EncryptionMethod Algorithm="..."/>
        <ds:KeyInfo>
          <ds:KeyName>CN=Mario Fontana, C=IT</ds:KeyName>
        </ds:KeyInfo>
        <xenc:CipherData>
          <xenc:CipherValue>...</xenc:CipherValue>
        </xenc:CipherData>
        <xenc:ReferenceList>
          <xenc:DataReference URI="#bodyID"/>
        </xenc:ReferenceList>
      </xenc:EncryptedKey>
    </wsse:Security>
  </S:Header>
  <S:Body>
    <xenc:EncryptedData Id="bodyID">
      <xenc:CipherData>
        <xenc:CipherValue>...</xenc:CipherValue>
      </xenc:CipherData>
    </xenc:EncryptedData>
  </S:Body>
</S:Envelope>

Il documento XML è formato dall’elemento xenc:EncryptedKey il quale contiene le informazioni sulle chiavi simmetriche e asimmetriche e un secondo elemento xenc:EncrytpedData contenente il ciphertext dei dati applicativi. Vediamo durante le due fasi (encryption e decryption) quali sono i passi che un’applicazione deve seguire: nella fase di creazione del documento XML l’applicazione genera una chiave di sessione SK1 che utilizza per cifrare le informazioni sensibili creando l’elemento xenc:EncryptedData che sostituisce al plaintext. A questo punto determina il destinatario del messaggio secondo la propria logica applicativa e utilizza la relativa chiave pubblica per cifrare SK1 che, in formato cifrato, viene inserita in xenc:CipherValue e imposta l’URI in xenc:DataReference per associare i dati cifrati con la chiave di sessione. Successivamente l’applicazione crea l’elemento ds:KeyInfo che tramite il sottoelemento ds:KeyName inserisce una stringa (“CN = Mario Fontana, C=IT”) che l’applicazione utilizzerà per iniziare il processo di decifratura tramite l’uso della corrispettiva chiave privata. In fase di decifratura l’applicazione, partendo dalla stringa in ds:KeyName, accede alla chiave privata e decifra il contenuto in xenc:CipherValue. Tale contenuto è la chiave di sessione SK1 che verrà utilizzata per decifrare la porzione XML referenziata da xenc:DataReference (in questo caso “#bodyID”) che punta ovviamente ad un blocco xenc:EncryptedData. Con questo meccanismo è possibile risolvere il problema della cifratura di informazioni applicative oltre al problema della distribuzione delle chiavi.

--Mario

Specifiche di base : XML Digital Signature in pillole...

mfontana — Tue, 30 Oct 2007 17:22:53 GMT

Per chi di voi ha partecipato al Panel della sicurezza che ho tenuto a WPC 2007 (o letto le slides) può capire il perchè sto scrivendo questa serie di post... "in pillole". Infatti per comprendere completamente alcuni nuovi attacchi sul fronte XML/Web Services è necessario approfondire il funzionamento di alcune specifiche di sicurezza nel mondo XML, perciò... eccoci qua :-)

XML Digital Signature [XMLDSIG xmlns="http://www.w3.org/2000/09/xmldsig#"] è il risultato di un lavoro congiunto tra il W3C e IETF. Lo scopo di questa specifica è di definire una sintassi XML e un insieme di regole per la creazione, la rappresentazione e la verifica di una o più firme digitali generate da documenti binari o XML. Al contrario XMLDSIG non si occupa del problema della generazione delle chiavi crittografiche, dell’associazione di tali chiavi ad utenti, servizi o processi e dei lagami di trust che devono essere impostati tra chi firma e chi verifica. Questa scelta permette di evidenziare la differenza tra le operazioni crittografiche e le policy di validazione che possono cambiare a seconda dello scenario applicativo.
La specifica prevede tre modalità per applicare le firme digitali in un formato XML:

Enveloped
Enveloping
Detached.

Come si può notare ciò che distingue una modalità dall’altra è il posizionamento dell’elemento <Signature> rispetto al documento firmato. Nel caso di Enveloped il contenuto da firmare contiene l'elemento <Signature> mentre si ha la situazione inversa nel formato Enveloping. La modalità Detached indica che il documento da firmare è completamente disgiunto dal documento contenente la firma digitale. [XMLDSIG] XML Digital Signature può firmare contemporaneamente più entità rendendo possibile associare in un unico documento XML le diverse modalità di firma.

Nella figura sottostante è rappresentato un esempio di documento XML firmato secondo la specifica [XMLDSIG] nel formato Enveloping.

La struttura di un file XML firmato secondo la specifica è il seguente :

<Signature ID?>
     <SignedInfo>
         <CanonicalizationMethod/>
         <SignatureMethod/>
         (<Reference URI? >
             (<Transforms>)?
            <DigestMethod>
            <DigestValue>
         </Reference>)+
     </SignedInfo>
     <SignatureValue>
     (<KeyInfo>)?
     (<Object ID?>)*
</Signature>

Come si può notare il file XML firmato contiene un elemento Signature al cui interno troviamo tre aree principali:

SignedInfo
SignatureValue
KeyInfo

SignedInfo, il cui schema è :

rappresenta sempre il primo elemento di ds:Signature e racchiude il contenuto da firmare e tutte le informazioni necessarie per rappresentare e gestire tali informazioni.
Infatti il primo sottoelemento obbligatorio, CanonicalizationMethod, indica quale algoritmo di normalizzazione deve essere applicato a tutto SignedInfo mentre SignatureMethod,anch’esso obbligatorio, rappresenta l’algoritmo di firma da utilizzare alla forma normalizzata di SignedInfo. L’elemento Reference (maxOccurs="unbounded" significa che possono essere presenti un numero arbitrario di elementi di questo tipo) raccoglie l’informazione da firmare. Lo schema di Reference

ci mostra chiaramente che :

il contenuto da firmare non è il documento stesso ma bensi l’hash del documento (DigestMethod e DigestValue) più le informazioni di rappresentazione.

Quindi la specifica prevede che per ogni documento da firmare vi sia un corrispondente elemento Reference all’interno di ds:SignedInfo il quale contiene l’informazione dell’algoritmo di hashing da applicare al documento in chiaro e il rispettivo valore di hash convertito in Base64. L’elemento opzionale Transform permette di specificare una sequenza di trasformazioni (dalle più semplici come Base64, Canonicalization a soluzioni più complesse basate su XPath o XSLT) da applicare al documento prima di essere firmato garantendo la massima flessibilità nella gestione dei dati.

Queste informazioni verranno utilizzate durante la fase di firma e di verifica. Nell’esempio precedente possiamo vedere che l’elemento SignedInfo contiene il riferimento all’algoritmo di canonicalizzazione C14N ("http://www.w3.org/TR/2001/REC-xml-c14n-20010315"), l’algoritmo di firma il quale indica che è stata usata una coppia di chiavi asimmetriche di tipo RSA (“http://www.w3.org/2000/09/xmldsig#rsa-sha1”) ed infine Reference contiene l’algoritmo di hash utilizzato (“http://www.w3.org/2000/09/xmldsig#sha1") oltre al valore espresso in Base64 (/mTHMHggNBeZJV8ToGqQwNkgs9s) della parte di documento XML da firmare referenziato tramite l’attributo URI=”#Persone”.

Tornando agli elementi che compongono ds:Signature troviamo l’elemento SignatureValue il quale semplicemente contiene la firma digitale vera e propria dell’elemento SignedInfo espressa in Base64. Quindi [XMLDSIG] concepisce la firma di uno o più documenti raccogliendo tutte le informazioni all’interno dell’elemento SignedInfo (riferimenti ai dati da firmare interni allo stesso documento o esterni, gli algoritmi di hash e gli stessi hash) ed infine, firma direttamente SignedInfo utilizzando l’algoritmo di canonicalizzazione e di firma specificati. Nell’esempio precedente il valore espresso in SignatureValue è quindi il prodotto della seguente sequenza:

Firma_rsa-sha1(C14N(SignedInfo))

Infine l’elemento opzionale KeyInfo permette di specificare come ottenere la chiave necessaria alla verifica del messaggio. Questo elemento è opzionale in quanto in alcuni scenari le informazioni sulle chiavi fanno parte del contesto applicativo e la specifica, come detto in precedenza, non vuole dare nessuna restrizione alle applicazioni.
Lo schema di KeyInfo :

dimostra che sono contemplati vari tipi di KeyInfo. In aggiunta a questi tipi ai quali è stata associata una struttura XML [XMLDSIG] prevede un ulteriore formato, chiamato rawX509Certificate, che permette di gestire un certificato X509 (binario) codificato in ASN.1 DER. Nel nostro esempio utilizziamo semplicemente l’elemento KeyValue al cui interno è contenuta la chiave pubblica RSA espressa tramite <Modulus> e <Exponent>.

La fase di verifica della firma digitale avviene in due fasi :

la verifica degli hash contenuti all’interno di ogni Reference
la verifica della firma applicata all’elemento SignedInfo.

La prima fase prevede la normalizzazione di tutto SignedInfo secondo l’algoritmo espresso in CanonicalizationMethod presente sempre nello stesso SignedInfo. In seguito, per ogni elemento Reference si ottiene il documento da verificare tramite l’attributo URI, gli si applicano eventuali trasformazioni, si calcola l’hash utilizzando l’algoritmo identificato in DigestMethod ed infine lo si paragona con il valore salvato in DigestValue.

Nella seconda fase invece si ottengono le informazioni riguardanti le chiavi crittografiche e si verifica la firma digitale applicata all’elemento SignedInfo tramite l’algoritmo specificato in SignatureMethod.

L’analisi della specifica [XMLDSIG] in questo contesto non è completa ma è sufficiente per introdurre WS-Security, la specifica di base per la sicurezza dei Web Services standardizzata da OASIS.

--Mario

Slides del Panel Sicurezza a WPC 2007

mfontana — Sat, 27 Oct 2007 12:42:56 GMT

Qui potete trovare le slides che ho utilizzato per il Panel Sicurezza : "SOA e Sicurezza Applicativa. Le sfide di oggi e di domani".

Durante i giorni del WPC ho avuto modo di parlare con molte persone interessate alle problematiche di sicurezza in SOA e ho raccolto e "consolidato" una serie di aree tematiche di interesse comune sulle quali farò dei post di approfondimento.

--Mario

Panel Security al WPC 2007 : SOA e Sicurezza Applicativa. Le sfide di oggi e di domani.

mfontana — Fri, 19 Oct 2007 17:37:14 GMT

Per chi di voi sarà al WPC 2007 spero di incontrarvi al panel sulla sicurezza "SOA e Sicurezza Applicativa. Le sfide di oggi e di domani" che terrò martedi 23 Ottobre dalle 19.15 alle 20.00. Come orario un po' tardino... a mo' di aperativo prima della cena :-)

Il formato del panel è pensato apposta per sessioni interattive... poche slides (tanto per inquadrare i punti chiavi) e poi via con le domande e un confronto tra noi e le nostre esperienze sui progetti...
E per chi non ne avesse abbastanza la sera dopo cena, questa volta a mo' di digestivo, sarò nell'area "Technical Afterhour" per fare quattro chiacchiere...

--Mario

Agenda del WebCast sull' Identity & Access Management

mfontana — Thu, 27 Sep 2007 01:11:51 GMT

Questa è la versione definitiva dell'agenda del Webcast che ho fatto sull' Identity & Access Management presentato qui.

Agenda

Identity & Access Management Overview.
Cosa intendiamo per Digital Identity.
Identity Design Patterns.
Scenari architetturali.
Identity MetaSystem.
Identity LifeCycle Management.

Potete scaricare le slides mentre l'intero WebCast è disponibile per il download qui.

--Mario

Il primo Webcast non si scorda mai...

mfontana — Thu, 20 Sep 2007 22:50:12 GMT

Giovedì 27 Settembre farò il mio primo Webcast...(quello che non si scorda mai:-). Il tema trattato è una overview sull'identity management nelle architetture service oriented. Qui vi potete iscrivere! Vi aspetto numerosi...

Due notiziole extra... In questa sessione parlerò del "pilastro" Identity & Access (Figura 1) presentato all'interno del percorso formativo per architetti che Giuseppe Guerrasio ed io abbiamo inaugurato il 13 Settembre.
Nel Webcast farò una breve panoramica delle forme di autenticazione, identity flow ed autorizzazione focalizzandomi sulle principali sfide che gli Enterprise Architect e Solutions Architect devono affrontare nel disegno di soluzioni distribuite. Successivamente faremo degli approfondimenti su questo vastissimo argomento tramite post o articoli tecnici.
~~A breve pubblicherò l'agenda della sessione...~~ ECCOLA :-)

Figura 1

Abstract del Webcast:

Il tema dell'Identity & Access Management è uno degli aspetti più delicati all'interno di una piattaforma pensata per la service orientation. L'evoluzione di Internet e la disponibilità di canali comunicazione sempre più affidabili e veloci, unitamente ai nuovi scenari di composizione ed aggregazione di servizi tra organizzazioni diverse, incrementa esponenzialmente l'importanza di questo aspetto rendendolo un fattore chiave. Le tematiche di federazione delle identità e dei nuovi standard nell'area della sicurezza nei web service diventano componenti fondamentali di una moderna architettura. In questa sessione analizzeremo la struttura tecologiche ed i principi architetturali presenti nella piattaforma Microsoft per rispondere efficacemente alle nuove esigenze in questa area.

--Mario

Specifiche di base : XML Canonicalization in pillole

mfontana — Mon, 17 Sep 2007 18:46:00 GMT

Iniziamo col dire cosa significa "Canonicalizzazione". La traduzione di Canonicalization, canonicalizzazione, significa rendere in forma canonica, normale. Quindi Canonicalizzazione = Normalizzazione (che è italiano :-)!

La specifica XML C14N è fondamentale per tutte le operazioni di crittografia nel mondo XML e Web Services (e non solo). E' una specifica del 2001 ovvero possiamo considerarla "matura" nel giovane mondo XML! Capiamo perchè XML C14N è così importante e cosa dice a grandi linee maaaa.... prima di iniziare con i contenuti seri una piccola curiosità:

Questa specifica viene spesso chiamata [XML C14N] perchè sono 14 lettere tra la C e la N di Canonicalization :-) ... svelato il mistero....

Adesso torniamo seri...
Le specifiche di XML Canonicalization si occupano della normalizzazione delle informazioni in una forma universalmente riconosciuta. Queste due specifiche (Canonical XML 1.0 del 15 Marzo 2001 e Exclusive XML Canonicalization 1.0 del 18 Luglio 2002) nascono per risolvere il problema della rappresentazione dello stesso XML Infoset (XML data model astratto – Ver. http://www.w3.org/TR/2001/REC-xml-infoset-20011024 del 24 Ottobre 2001) in formati sintattici e contesti diversi. Si considerino le seguenti rappresentazioni XML :

Questa libertà di rappresentare lo stesso XML Infoset è intrinseca nella serializzazione di XML 1.0 e pone dei problemi in alcune operazioni di crittografia come ad esempio la firma digitale. In figura 1, ad esempio, un’unica informazione viene espressa in tre forme diverse e durante l’operazione di encoding in byte streams (octets) si ottengono tre valori diversi che producono ovviamente tre firme digitali diverse. Infatti la firma digitale avviene tramite l’encryption con la chiave privata dell’hash dei dati da firmare! Poiché le tre rappresentazioni producono tre hash diversi di conseguenza si ottengono tre firme diverse. Perché questo è un problema? Il problema nasce quando un programma vuole verificare una firma digitale rispetto al XML Infoset. Senza un processo di normalizzazione condiviso nel caso precedente avremmo 1/3 delle probabilità che l'operazione di firma dia esito positivo!

Questo aspetto è molto importante perchè la logica applicativa lavora molto spesso a livello di Infoset XML e non sulla singola rappresentazione creando problemi in fase di verifica delle informazioni crittografiche .

Figura 1

Inoltre durante il trasferimento dei dati, come ad esempio nelle operazioni di Orchestration, le rappresentazioni possono cambiare e subire trasformazioni dettate dalle regole sintattiche di altre specifiche come SOAP.

Anche la stessa natura del formato testo pone dei problemi di “compatibilità”. Alcuni esempi possono essere la diversa rappresentazione degli spazi alla fine delle righe, le tabulazioni, i caratteri di fine riga. Queste incongruenze devono quindi essere risolte prima di passare i dati in formato testo alle funzioni di crittografia. A questo proposito sono state create due specifiche: la prima, Canonical XML 1.0 [XML-C14N], chiamata anche Inclusive, descrive le regole di normalizzazione di un documento XML in byte stream. Queste regole prevedono che tutti gli attributi vengano dichiarati con i doppi apici, l’encoding debba essere in UTF-8, i tag debbano essere espressi nella forma estesa e gli attributi e i namespaces siano rappresentati in ordine alfabetico. Per una completa visione di queste regole si faccia riferimento alla specifica Canonical XML 1.0 e Exclusive XML Canonicalization 1.0 .

Applicando la funzione di Canonical XML 1.0 all’esempio precedente avremo il seguente output:

che genererà sempre la stessa firma digitale permettendo quindi l’operazione di verifica (Figura 2).

Figura 2

I limiti di questa specifica si evidenziano quando porzioni di documenti XML vengono spostati o copiati da un documento all’altro. Infatti la specifica prevede l’inserimento di alcune informazioni, come ad esempio le dichiarazioni dei namespaces appartenenti al messaggio XML originario nello stesso sottodocumento estratto, causando un cambiamento nella rappresentazione sintattica del documento stesso. Si è resa quindi necessaria una seconda specifica, Exclusive XML Canonicalization 1.0, che permettesse di escludere le informazioni di contesto dalla parte del sottodocumento passato alla funzione di normalizzazione. Questa situazione è comune soprattutto nel mondo dei Web Services quando un documento XML viene firmato ed estrapolato da un contesto applicativo per essere inserito in un SOAP:Envelope per la trasmissione. Nella fase di verifica il documento XML viene estratto dal SOAP:Envelope e verificato. Ad esempio nel firmare digitalmente la seguente porzione di documento XML che chiamiamo XML₁

<ns1:info xmlns:ns1="http://application">
<ns1:persona eta="35" nome="Mario"></ns1:persona>
</ns1:info>

otteniamo la firma F1. Successivamente ipotizziamo di inserire XML₁ all’interno di un altro elemento e chiamiamo XML₂ il nuovo documento

<ns0:app xmlns:ns0="http://transmission">
<ns1:info xmlns:ns1="http://application">
<ns1:persona eta="35" nome="Mario"></ns1:persona>
</ns1:info>
</ns0:app>

Nella operazione di verifica della firma F1 è necessario estrarre XML₁ da XML₂.

Questa operazione può essere effettuata con la creazione di un node-set XPath passato poi alla funzione di normalizzazione ottenendo il seguente risultato XML₃:

<ns1:info xmlns:ns0=”http://transmission” xmlns:ns1="http://application">
<ns1:persona eta="35" nome="Mario"></ns1:persona>
</ns1:info>

Come si può notare XML₃ è diverso da XML₁.in quanto sono presenti alcune informazioni di contesto di XML₂ che genereranno un errore in fase di verifica della firma digitale F1.

Exclusive XML Canonicalization 1.0, che non inserisce le informazioni di contesto, permette di riottenere esattamente XML₁ e quindi di avere una corretta operazione di verifica.

Questa è una versione un po' aggiornata di un articolo che ho scritto nel 2003 per Visual Basic Journal...

--Mario