Security & Architecture : WS-*

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

.NET 4.0 BETA 1 e WS-Discovery

mfontana — Mon, 20 Jul 2009 17:14:25 GMT

WS-Discovery è diventato standard OASIS come specificato nel blog di team.

Ma la cosa, forse, più interessante è che la BETA 1 del framework .NET 4 comprenderà già i bit della specifica OASIS!!

Per maggiori informazioni su WS-Discovery e l’importanza che anche questa specifica ricopre nel mondo dei Web Services vi rimando a “tra poco” con un post dell’ amico Alessio Mannelli sempre su questo canale !!!

Stay tuned :-)

--Mario

L' Application Security è indietro 10 anni rispetto al Software Development ?

mfontana — Tue, 16 Jun 2009 08:01:00 GMT

“In evolutionary terms, the information security field is more than a decade behind software development” con queste parole inizia un interessante articolo di Gunnar Peterson dal titolo “Service-Oriented Security Indications for Use”. In sistesi Gunner sostiene che a partire dagli anni 90 abbiamo assistito a molteplici evoluzioni nel campo del software development mentre in ambito security siamo rimasti pressochè fermi, immobili.

Io mi trovo pressochè d’accordo con lui anche se man mano proseguivo nella lettura dell’articolo le ragioni del mio essere d’accordo divergevano sempre più da quelle presentate da Gunner. Mi spiego meglio.

In sintesi Gunner sostine cha se dal lato applicativo c’è stata una forte evoluzione partendo dagli anni 90 con lo sviluppo delle prime Web Applications con CGI, passando poi per l’era ASP/JSP, le 3-tiers Apps nel 1998 per arrivare agli anni 2000 dove si inizia a progettare con SOAP, XML e REST per arrivare agli albori del Web 2.0, dal lato security non siamo mai andati oltre i firewalls e SSL. Su questo sono d’accordo anche se a mio avviso è necessario fare un ulteriore distinguo tra le definizione di standard per la sicurezza e relativa adozione di quest’ultimi da parte dell’industria per capire meglio il fenomeno. Infatti non è vero che lato security non c’è stata innovazione!

Tra il 2001 e il 2002 sono comparsi i primi draft delle specifiche che volevano andare oltre la sicurezza del protocollo SSL e di infrastruttura (comunque lato sicurezza applicativa i firewall erano già bypassati con l’introduzione di SOAP/XML, fino alla comparsa delle prime versioni capaci di fare content control su formati XML based). Nacque il così detto stack WS-* ovvero l’insieme di tutte quelle specifiche dedicate prevalentemente al mondo dei Web Services (non solo in ambito Security) e che oggi si riconoscono perchè iniziano tutte con WS- !!

Quindi già dai primi anni del nuovo millennio abbiamo assistito alla comparsa di specifiche che volevano in qualche modo superare i limiti imposti da SSL e indirizzare il problema della sicurezza nel messaggio non solo tra due end-point ma fino al raggiungimento del destinatario finale. Questo scenario diventò sempre più importante in scenari SOA dove la sicurezza è o dovrebbe essere gestita più da un punto di vista delle operations che tecnologico e dove i servizi possono essere distribuiti in security context diversi e/o geograficamente. Una breve analisi del concetto di infrastruttura applicativa a servizi e relativi modelli di autenticazione li potete trovare in questi post : cosa intendiamo per infrastruttura applicativa, autenticazione a livello di canale, autenticazione a livello applicativo, autenticazione a livello di messaggio. Già a partire da Dicembre 2002 con WSE 1.0 (per chi lavorava in ambito .NET) erano a disposizione di architetti e developers i primi bit per disegnare e soprattutto implementare scenari basati su queste nuove specifiche (WS-Security, WS-Routing (ora chiamata WS-Addressing) e poco più.

Questo lato innovazione. Lato adozione lo scenario è effettivamente diverso; tali innovazioni non furono prese molto in considerazione per vari motivi (novità, poca esperienza, pigrizia (tanto c’era SSL) e a mio avviso perchè negli anni le vere potenzialità che possono fornire le architetture a servizi come SOA/EDA sono sempre state sottovalutate. Personalmente lavoro con le specifiche WS-* dalla primissima BETA di WSE (Luglio/Agosto 2002) e ho realizzato molte soluzioni in ambito Enterprise e posso riassumere la mia esperienza in questo modo:

le competenze sui patterns di sicurezza in ambito SOA sono conosciuti e adottati in bassissima percentuale nella fascia dei grandi clienti e quindi non mi meraviglio che in scenari meno enterprise non ci sia traccia di sicurezza se non con firewalls e SSL. Questo almeno fino ad un paio di anni fa.

Fortunatamente questo scenario sta cambiando… l’adozione di patterns per la federazione via WS-Federation e SAML 2.0 Protocol oltre i modelli basati sulla Claims-Based Security ne sono una conferma. Anche in questo caso però sto notando una adozione prima da parte delle aziende ed enti pubblici e poi man mano in scenari sempre meno Enterprise. Personalmente conto molto sulla “democratizzazione” di questi aspetti di security con il Cloud Computing perchè diventa (fortunatamente) sempre più difficile realizzare soluzioni silos e totalmente custom dove al contrario gli aspetti di interoperabilità, sicurezza e distribuzione geografica sono un must fin dalle prime fasi della progettazione!!

Altro ambito in cui negli ultimi anni sto iniziando a vedere un discreto aumento di sensibilità in tutti i settori del mercato IT è quello legato alle best practices sullo sviluppo di codice sicuro. Da qui l’adozione di modelli derivanti dal SDL – Security Development LifeCycle – (ad esempio qui trovate i tool per integrare i principi del SDL con i vari aspetti dell’ ingegneria del software via Visual Studio Team System) e degli sforzi di OWASP – Open Web Application Security Project - per rendere esplicite le best practices in questo ambito.

Quindi tornando all’articolo in oggetto non credo che il mondo della sicurezza sia stato alla finestra a guardare il resto dell’ IT che si evolveva restando inerte. Credo invece che l’intriseca fatica nel capire le evoluzioni in ambito sicurezza legate alla complessità dei nuovi scenari architetturali abbia di fatto rallentato se non fermato per anni l’adozione in ambito IT. Da qui il mio essere d’accordo con l’articolo ma per ragioni diverse.

Mi piacerebbe molto sapere cosa ne pensate :-)

--Mario

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

Microsoft e SAML 2.0 Protocol

mfontana — Wed, 20 May 2009 13:15:10 GMT

Forse non è ancora noto a tutti che Microsoft sta lavorando per integrare parte del protocollo SAML 2.0 all’interno dei servizi di Active Directory.

Come presentato durante l’ultimo PDC (Professional Developers Conference) da Kim Cameron la nuova versione di ADFS (Active Directory Federation Services) che per adesso ha il code name Geneva, oltre ad estendere il supporto alle specifiche WS-* (WS-Security, WS-Trust, WS-Federation, ecc.…) sarà in grado di “parlare” SAML 2.0 creando una vera e propria infrastruttura sistemistica ed applicativa capace di semplificare gli aspetti di autenticazione e di Single Sign On. Geneva inoltre è definita una “open platform” perchè permette di realizzare una architettura claims-based basata sui principali protocolli standard (WS-* e SAML 2.0). I componenti della specifica SAML 2.0 implementati sono i seguenti :

Web SSO AuthnRequest : HTTP redirect
Web SSO Response : HTTP POST
Identity Provider Discovery : Cookie
Web SSO Response : HTTP Artifact
Artifact Resolution : SOAP
Single Logout (IdP-initiated) : HTTP redirect
Single Logout (SP-initiated) : HTTP redirect
Enhanced Client/Proxy SSO : PAOS

Infine Geneva per automatizzare al massimo l’amministrazione degli aspetti di federazione utilizzerà il nuovo harmonized federation metadata format basato sui metadata SAML 2.0. (leggete qui la notizia da Don Schmidt)

E questo cosa significa?

Interoperabilità e Single Sign On! Infatti SAML 2.0 è il protocollo di riferimento per le principali architetture Open-Source per lo scambio di informazioni di autenticazione ed autorizzazione tra security domains mentre lo stack di specifiche WS-* (e nello specifico WS-Federation) è lo standard di riferimento utilizzato nei principali prodotti commerciali sempre con l’obiettivo di scambiare informazioni di autenticazione ed autorizzazione.

Queste specifiche hanno molti vantaggi per noi architetti ma anche un grosso svantaggio : mantenere i due mondi nettamente separati!! Questo significa che noi poveri architetti spesso siamo costretti a creare componenti di architetture più o meno custom per poter superare queste diversità. E’ il colmo ! Dover disegnare/scrivere delle soluzioni custom per integrare gli standard !!! (questo è il tipico caso in cui la presenza di standard non sempre aiuta!!).
Con Geneva questa realtà finalmente può cambiare!! Oggi siamo in grado di far interoperare questi due mondi permettendoci di disegnare scenari di Single Sign On per i nostri utenti indipendentemente dallo stack applicativo e sistemistico utilizzato. Finalmente possiamo iniziare a parlare di Interoperabilità con la I maiuscola anche in ambito Identity dove normalmente le varie architetture storicamente erano chiuse, blindate dalla propria tecnologia!

WS-* e SAML 2.0 Protocol. Perchè due stack di specifiche?

Ma allora la domanda nasce spontanea … perchè due stack ?

Cominciamo col dire che le specifiche WS-Trust/Ws-Federation (dello stack WS-*) e il protocollo SAML 2.0 hanno alcune parti in comune ma obiettivi differenti !

WS-Trust/Ws-Federation come tutte le specifiche di WS-* sono pensate prevalentemente per Web Services ovvero scenari “attivi” capaci di “parlare SOAP”. Infatti anche il nome lo dice : WS-* significa Web Services-*, e quindi WS-Trust = Web Services Trust, WS-Federation = Web Services Federation. Quindi lo stack WS-* fin dagli albori (siamo alla fine del 2000 circa) ha lo scopo di fornire un’infrastruttura per il mondo a servizi (da SOA a SaaS, S+S, ecc…). WS-Federation in quello che era chiamato “profilo attivo” rappresenta la naturale evoluzione di WS-Trust e descrive i meccanismi di trust tra Security Domains differenti (Federazioni) con una predilezione e un punto di vista a servizi.

Una architettura di questo tipo che pone tra i propri obiettivi anche il Single Sign-On tra applicazioni e Web Services sarebbe stata monca se non avesse aggiunto anche il supporto ai client Web che non sono in grado di gestire il protocollo SOAP (ovvero i Browser). E’ per questo motivo che WS-Federation ha anche il profilo passivo, ovvero una serie di regole che permettono ai browser di utilizzare i protocolli WS-Trust e WS-Federation tramite HTTP 1.1 e quindi di integrare le anche le Web Applications nel processo di Single Sign On. In questo caso (passivo) abbiamo una sovrapposizione con una parte delle funzionalità espresse da SAML 2.0 protocol !!!

Quindi per rispondere alla domanda “perchè due specifiche” posso dire che WS-Federation nasce come evoluzione di un particolare modello ormai consolidato di sicurezza e di gestione delle identità capace di gestire sia i Web Services che per le Web Application mentre questo doppio supporto non era previsto (almeno inizialmente) dal protocollo SAML 2.0 (nato prevalentemente per gli scenari Web Apps). Infatti, SAML 2.0 nasce dalla convergenza di SAML 1.1, Liberty ID-FF 1.2, e Shibboleth 1.3 con il primario obiettivo di definire uno standard per il Web Single Sign On. Successivamente SAML 2.0 ha aggiunto anche il SAML ECP (Enhanced Client Profile) per l’integrazione di client attivi.

WS-Federation quindi permette a tutti quelli che hanno investito sullo stack WS-* di continuare gli investimenti adottando un unico modello di sviluppo indipendentemente dai sistemi utilizzati - Windows/Linux – e dai linguaggi .NET/Java o altro. Dal canto suo, seguendo anche le innumerevoli (e a mio avviso, giustissime) richieste da parte di clienti da tutto il mondo, parte del protocollo SAML 2.0 è stato integrato in Geneva ponendo il primo tassello verso la realizzazione di un Identity MetaSystem capace di gestire ambienti multi piattaforma e multi player. Per ulteriori informazioni leggete questo post di Don sullo stesso tema!!

Con questo post spero di rispondere a tutti quelli che sostengono che WS-Federation è nato esclusivamente con la volontà di fare una guerra al mondo Open Source e al protocollo SAML 2.0. Personalmente , come Software Architect trovo molto frustrante quando esistono stack di infrastruttura applicativa difficilmente integrabili tra loro perchè non ci permettono di svolgere il nostro lavoro al meglio e accolgo sempre in modo positivo quando questi ostacoli vengono superati dalle infrastrutture di base siano esse Microsoft o altro.

--Mario

Identity Developer Training Kit

mfontana — Tue, 12 May 2009 13:03:01 GMT

Ci sono grandi novità in ambito eID tra ieri ed oggi !!!

Con l’uscita della BETA 2 di GENEVA oggi viene presentato anche il nuovo Identity Developer Training Kit ovvero una risorsa per DEV contenente hands- on-labs per sviluppatori creato da una task force composta da persone di DPE (la divisione per cui anch’io lavoro) e dell’ Identity Product Team con l’obiettivo di guidarvi nei meandri della programmazione di Geneva Framework, Geneva Server, Windows Live ID, Microsoft Federation Gateway e del .NET Access Control Service con esempi di applicazioni ASP.NET e WCF.

Questo Kit segue la filosofia dei training kit che (spero) abbiate già sperimentato (Training Kit su Windows Azure, Training Kit su .NET 3.5) dove nel tempo il kit viene arricchito di nuove PPT, source code, scenarios e video.

Buona sperimentazione,

--Mario

E’ arrivata la BETA 2 di Geneva. Quali le novità?

mfontana — Tue, 12 May 2009 12:41:00 GMT

Durante la Keynote di Scott Charney alla RSA Conference di San Francisco è stata annunciata la disponibilità a breve della BETA 2 di Geneva. Si sapeva che l’uscita era in concomitanza con il Tech-ED NA 2009 che è cominciato ieri… ebbene ogni promessa è un debito (mai frase fu più falsa di questa in ambito rilasci di software :-) e quel “a breve” è stato oggi (o meglio quesat notte per noi europei) !!! Infatti da pochissimo sono disponibili in download i bits della BETA 2 di Geneva (Geneva Server, Geneva Workstation, Geneva Cardspace).

Per chi volesse avere una breve overview dei componenti di Geneva la trova in questo mio post “Cosa è Geneva in due parole”

Vediamo quali sono le principali novità:

Geneva Server :

Un nuovo motore per il claims transformation con la possibilità di attingere informazioni (attributes) da (attribute) store come SQL Server e AD LDS (il buon ADAM) e custom oltre che da AD.
Supporto per SAML 2.0 SP-Lite
Proxy per autenticazione di utenti internet verso i Geneva Server nella intranet.
Supporto a PowerShell commandlets
Supporto al Federated RMS.
Provisioning di CardSpace “Geneva” clients via Group Policy.
Supporto alla federazione con il Microsoft Federation Gateway.
Maggiore scalabilità.

Geneva Framework :

Integrazione con VIsual Studio 2008 tramite dei template dedicati per ASP.NET e WCF.
Utility e wizard per aiutare la migrazione di applicazioni esistenti alla claims-based security.
Supporto allo sviluppo di applicazioni claims aware e STS.
Nuova versione di Fedutil.exe per supporto all’offline development.
Supporto a Sharepoint 2007 !!!
Nuove API per l’autorizzazione.
Evoluzione nella struttura dei token handlers e del FAM (Federation Authentication Module).

Geneva CardSpace:

Provisioning di CardSpace “Geneva” clients via Group Policy.
Aggiornamenti alla management UI
Auto provisioning di Information Cards ed estensioni per la gestione da parte gli amministatori.

Su Chanell 9 all’interno della sezione dedicata all’Identity Management “Id Element” oggi sono stati pubblicati 4 video sulla BETA 2 di Geneva.

· Chuck Reeves explores the Geneva Framework structure in depth

· Sesha Mani reports on what’s new with the Geneva Framework

· Jan Alexander describes the new claims transformation language

· Matt Steele discusses what’s new in Geneva Server

--Mario

Cosa è Geneva... in due parole

mfontana — Tue, 12 May 2009 12:35:00 GMT

Nonostante siamo solo alla BETA 2 (da oggi) esistono varie fonti dove trovare documentazione su Geneva. Per questo motivo cercherò di schematizzare in poche righe le peculiarità di Geneva.

Innanzitutto con Geneva si intendono 3 componenti : Geneva Server, Geneva Framework e Geneva Cardspace. Vediamone le caratteristiche:

Geneva Server

Geneva Server è un il code name della versione 2 di ADFS (Active Directory Federation Services) e in questa versione (da oggi disponibile la BETA 2) rappresenta uno dei componenti della piattaforma CBA (Claims based access) di Microsoft. Molte le novità e gli improvements rispetto ad ADFS. Volendo schematizzare Geneva server:

Principalmente Geneva Server è un security token service (STS) che permette di usare Active Directory come Identity Provider del mondo claims-based (Figura 1).
- Identity e Federation provider
Federation Trust Manager
- Automatizza la configurazione e la gestione dei trust via metadata
Basata su standard di mercato
- Supporto all’interoperabilità
- Supporto a scenari WS-Federation passive profile (come ADFS) ovvero per applicazioni Web (via browser)
- Supporto a scenari WS-Federation active profile per integrare nei processi di eID e di Single Sign On anche le applicazioni desktop e i Web Services.
- Supporto (e questa è veramente una grossa novità) a SAML 2.0 Protocol .
  - Web SSO AuthnRequest : HTTP redirect
  - Web SSO Response : HTTP POST
  - Identity Provider Discovery : Cookie
  - Web SSO Response : HTTP Artifact
  - Artifact Resolution : SOAP
  - Single Logout (IdP-initiated) : HTTP redirect
  - Single Logout (SP-initiated) : HTTP redirect
  - Enhanced Client/Proxy SSO : PAOS
- Supporto a token SAML 1.1 e SAML 2.0
Managed Information card-provider per AD
- CardSpace e Identity Selectors di terze parti.

Figura 1: Architettura di Geneva Server

Geneva Framework

Geneva framework è un’insieme di classi che estendono il framework .NET e a sua volta è l’evoluzione di un altro code name : Zermatt.

Classi per rendere le proprie applicaioni claims-based.
Può essere utilizzato sia per le Web Applications che per i Web Services. Quindi sia per ASP.NET e WCF.
Introdotto un nuovo modello claims based.
- Estensione del modello “classico”IIdentity/IPrincipal” con il nuovo “IClaimsIdentity/IClaimsPrincipal”.
- Utilizzo di Thread.CurrentPrincipal al posto di ClaimsPrincipal.Current per un più facile accesso ai claims del chiamante.

Claims e claims types sono tutte strighe.
ClaimsAuthenticationManager per racchiudere tutta la logica di autenticazione in un unico punto.
Uso estensivo dei token Handlers per processare qualsiasi tipo di token (U/P,X509, Kerberos, SCT e HttpCoockies.
Il FAM (Federated Authentication Module) è composto da tre authentication models: SessionAuthenticationModule, WSFederationAuthenticationModel e ClaimsPrincipalHttpModule. In questo modo si semplifica la compatibilità con la Forms Authentication di ASP.NET e i moduli di UrlAuthorization.
Supporto allo sviluppo di custom STS.
GTS : Geneva token Service è un servizio disponibile con il Geneva framework che permette di trasformare token XML (come ad esempio SAML tokens) in Windows Token tramite l’ UPN name (Dietro le quinte utilizza il Kerberos Extension S4U2Prox)
Supporto allo sviluppo di RP (Relying party – ovvero applicazioni claims-aware) con il supporto di CardSpace.
Supporto ASP.NET controls e integrazione con VIsual Studio 2008 tramite dei template dedicati per ASP.NET e WCF.
Nuove API per l’autorizzazione.

Geneva CardSpace

CardSpace “Geneva” rilascia dei security token ai web sites/Web Services sfruttando l’infrastruttura claims-based e i meccasismi basati su WS-Security/WS-Trust e WS-Federation permettendo di mitigare al massimo il problem del phishing e aumentando la privacy degli utenti (è l’utente che piò selezionare quali e quante informazioni dare ad un sito durante la fase di autenticazione). Le informazioni all’utente sono gestite tramite delle Information cards ovver dei documenti XML firmati da un STS.

--Mario

Come integrare vecchi e nuovi applicativi C/C++ con i Web Services

mfontana — Tue, 24 Mar 2009 12:35:18 GMT

Con l’uscita della prima beta di Windows 7 (e Windows Server 2008 R2) sono disponibili delle nuove API – Windows Web Services API (WWSAPI) - che permettono ai programmatori C/C++ di integrare le loro applicazioni “unmanaged” (= non .NET) con il variopinto mondo dei Web Services . Le WWSAPI permettono di creare sia la parte client che la parte server (Web Services) in puro stile C. Le applicazioni C/C++ oggi sono ancora fortemente presenti nei reparti IT e (spesso) non ci sono particolari ragioni per doverle riscrivere in codice .NET o Java!! Quindi le applicazioni C/C++ sono ancora una realtà e come tale è giusto che possano facilmente, ovvero a basso costo e senza overhead, integrarsi con tutti quei Web Services che tanto vanno di moda da qualche anno a questa parte.

Come spesso racconto durante i seminari o durante gli incontri con i clienti l’adozione dei Web Services all’interno di un reparto IT (grande o piccolo che sia) può essere suddiviso in due momenti : Enterprise Efficency ed Enterprise Agility. Nel primo caso stiamo parlando di tutte quelle aziende (ad oggi la maggior parte in Italia) che iniziano a sperimentare l’efficacia dei Web Services e li utilizzano essenzialmente come mezzo per facilitare l’interoperabilità tra software che nativamente non si parlano (spesso per ragioni tecnologiche). Facilitare l’interoperabilità signifca essere più efficienti, da cui Enterprise Efficiency.
Man mano che l’adozione dei Web Services da puro strumento di interoperabilità si trasforma in una architettura adottando quei modelli architetturali che vanno sotto il nome di SOA, EDA, SaaS,... allora entriamo nella così detta Enterprise Agility. Ovvero adottando questi modelli rusciamo ad essere più reattivi alle richieste da parte del business perchè il nostro modello permette o dovrebbe permettere i principi dell’application composition. Bene! Tutto questo panegirico per dire che, una volta tanto, sono qui per parlare della parte di Efficiency e non (solo) della Agility. Infatti tramite le WWSAPI sarà possibile mettere in comunicazione i nostri applicativi unmanaged con servizi scritti con .NET, J2EE e tutti quei linguaggi capaci di gestire SOAP 1.1 o 1.2 e HTTP. In realtà le WWSAPI fanno molto di più : permettono l’integrazione degli applicativi anche in scenari complessi basati su stack WS-* !!!

Ah, quasi dimenticavo, da una indagine svolta dalla società PayScale pare che i programmatori C/C++ abbiano in media uno stipendio più alto dal 2 al 20 % rispetto ai colleghi .NET e Java !!! Programmatore avvisato … :-)

Perchè un’altra libreria?

Perchè le applicazioni unmanaged, essendo una forte realtà sul mercato hanno bisogno di uno stack snello e performante capace di integrare le applicazioni C/C++ con le funzionalità esposte dai Web Services. Inoltre, non so voi, ma a me nel tempo è capitato spesso di vedere molte forme custom di integrazione alcune delle quali particolarmente fantasiose :-) Oramai i Web Services sono diventati una realtà non solo per le applicazioni utenti ma sempre più spesso anche da parte del Sistema Operativo. Quindi, chi meglio del S.O. può mettere a disposizione una libreria capace di “parlare Web Service”??

Altra richiesta fondamentale è la non dipendenza da altri stack tecnologici. Da anni si possono già integrare componenti .NET con codice C/C++ tramite ad esempio il Managed C++, pInvoke.... Tutte soluzioni però che vedono il caricamente del CLR all’interno dello spazio di indirizzamento del processo unamanged. Questo in molti casi è semplicemente non percorribile per motivi di performance, di security... Morale della favola : le WWSAPI non hanno alcuna dipendenza da altri stack tecnologici come COM, DCOM, .NET o altro... nemmeno ATL!!!! Sono delle semplici API esposte in un’unicqa DLL, WEBSERVICES.DLL, che non ha dipendenze particolari se non quelle classiche di sistema come ad esempio :

MSVCRT.DLL (Windows NT CRT)
WS2_32.DLL (Windows Socket 2.0)
HTTPAPI.DLL (HTTP Protocol Stack API)
WINHTTP.DLL (Windows HTTP Services)
CRYPT32.DLL (Prima di Vista)
BCRYPT.DLL & NCRYPT.DLL (Da Vista in poi)

Solo per Windows 7?

Trattandosi tipicamente di applicazioni C/C++ scritte negli anni non era pensabile che il S.O.di riferimento fosse solo ed unicamente Windows 7 e R2 di W2008. Per questo motivo le WWSAPI saranno disponibili anche per tutti i S.O. ancora coperti da supporto tecnico:

Windows XP con Service Pack 2 (SP2) e successivi
Windows Vista
Windows Server 2003 con Service Pack 2 (SP2)
Windows Server 2003 R2 con Service Pack 2 (SP2)
Windows Server 2008

La domanda più ricorrente a questo punto è : perchè non Windows 2000? Perchè ormai W2K è fuori dai cicli evolutivi e di supporto.

Download delle varie versioni : http://connect.microsoft.com/WNDP/content/content.aspx?ContentID=11205

WWSAPI e WCF che relazione?

nessuna :-) ormai dovrebbe essere chiaro. WWSAPI non hanno dipendenze con il framework .NET e quindi neppure con WCF. Sono due librerie paritetiche : WWSAPI utilizzate in codice unmanaged; WCF in codice managed! Condividono però una serie di similitudini come ad esempio il modello di programmazione Function-oriented che permette di mascherare al programmatore i dettagli di una comunicazione message-oriented. Altra similitudine è il supporto a scenari più articolati come quelli previsti dallo stack di specifiche WS-* per i Web Services :

Specifiche di Base:

Trasporto

HTTP, TCP, UDP

XML Encoding

Text, Binary, MTOM

Metadata

WSDL 1.1, XML Schema 1.0

Envelop

SOAP 1.1 e SOAP 1.2

Specifiche WS-*

Addressing

WS-Addressing 0.9 e 1.0

Metadata

WS-MetadataExchange 1.1
WS-Transfer March 2006

Security

WS-Security 1.0 e 1.1 (implementazione parziale)
WS-Trust February 2005 e 1.3 (implementazione parziale)
WS-SecureConversation 1.1 e 1.3 (implementazione parziale)

Policy

WS-Policy dalla versione March 2006 alla 1.2
WS-PolicyAttachment dalla versione March 2006 alla 1.2
WS-SecurityPolicy 1.1

Come si può notare a fianco delle specifiche di sicurezza c’è la scritta un po’ inquietante : implementazione parziale. Questo significa che la versione 1.0 delle WWSAPI implementano solamente la sicurezza a livello di trasporto e Mixed-mode Security escludendo di fatto quella parte delle specifiche relative alla sicurezza a livello di messaggio che al contrario è presente in WCF. Quindi riassumendo le caratteristiche del Channel Security avremo:

Trasport Security:

HTTP : SSL e Header auth: basic/digest/SPNEGO/NTLM e SSPI
TCP: Windows SSPI e SSL

Mixed-mode Security

Il trasporto mette in sicurezza la connessione e fornisce la funzionalità di server authentication.
Gli Header WS-Security all’interno dei messaggi SOAP vengono utilizzati per il client authentication:

Token : Username/Password, Kerberos AP_REQ, SCT, Generic XML
Supporto a token SAML e scenari di Federation.

WWSAPI Architecture

Nella documentazione ancora in BETA ogni tanto si fa ancora riferimento alle WWSAPI con il codename Sapphire !

Nella figura sottostante è schematizzata la struttura delle WWSAPI:

Figura 1 : architettura delle WWSAPI

Esistono una serie di oggetti trasversali ai layer come ad esempio Errors, Tracing, Heap che permettono al programmatore di gestire facilmente alcuni aspetti della gestione delle WWSAPI. L’oggetto Error ad esempio permette di uniformare la gestione degli errori semplificando anche la complessità dei SOAP Faults mentre l’oggetto Heap permette di fare chiarezza su chi alloca e chi disalloca le risorse impiegate per la gestione delle comunicazioni. Maggiori informazioni sull’uso di questi oggetti e relative funzioni si trovano qui

Come si può notare dalla figura 1 il codice applicativo può lavorare a diversi layer a seconda del livello di dettaglio che si vuole gestire direttamente. In due parole cercherò di descrivere i vari layer mentre una descrizione più esaustiva la si può trovare qui sul sito MSDN.

Il Service Model è il layer più ad alto livello che permette di gestire la comunicazione tra il client e il Web Service con il modello a chiamate a funzioni. Il punto di contatto tra il client e un Web Services anche per le WWSAPI è solo il WSDL e gli XSD che vengono trasformati in codice C (.c e .h) da una utility a riga di comando wsutil.exe (Maggiori dettagli nel prossimo post dove partiremo da zero nell’integrazione con dei Web Services).
Lato client permette di chiamare delle funzioni proxy generate dal tool WSutil.exe mentre lato server permette di concentrarsi quasi esclusivamente nell’implementazione delle funzioni di callback.

Il Channel Layer rappresenta una astrazione del canale di comunicazione e permette di interagire direttamente con le sue poprietà. A mio avviso non saranno molti gli scenari dove sarà richiesto l’accesso a questo livello di dettaglio.

L’ XML Layer/Serialization rappresenta il proprio motore specializzato per i’ XML parsing delle WWSAPI con encoding Text, Binary e MTOM. Queste API esportano un XML Buffer, un XML Reader e un XML Writer che permettono di gestire, leggere e scrivere documenti XML solo in modalità “forward-only”. L’unica nota che mi preme sottolineare è il non supporto dei DTD come spesso avviene in scenari SOAP. Anche in questo caso a mio avviso saranno pochi gli scenari dove è richiesto un intervento a questo livello.

Nel prossimo post vedremo come utilizzare queste API passo-passo in diversi scenari…

--Mario

Dialogo alla stazione...

mfontana — Fri, 19 Dec 2008 22:18:37 GMT

... sul marciapiede in attesa del treno (in ritardo) per Brescia tra due nonnetti :

Lei (cappottino marrone, borsetta e foular sui capelli) guardando il tabellone dell'orario del treno: "Te Arturo, cusa l'aspetta il nostro treno?? en Veb Service ??? mal passa de qui???" (traduzione: Arturo, cosa aspetta il nostro treno?? un Web Services? Ma passa su questo binario??).

Arturo (credo fosse il marito con tanto di cappotto a quadretti rossi, cappello e bastone) : "Bah, Veb...Veb??? sarà en laur de internet" (traduzione: sarà riferito ad internet, al Web).

Lei : "internet? cosa c'entra l'internet coi treni?"

Arturo : "a mel so mia, me voe saper quando arriva el me treno beeeeepppppp, beeeeeppppp"...

Questo è successo ieri sera verso le 18.20 mentre ero bloccato alla stazione di Milano Lambrate a cause del cambio dell'orario di tutti i treni e proprio durante gli annunci di ritardi , con un tempismo perfetto, tutti i monitor degli orari e i tabelloni sui binari si sono spenti e riaccesi con la scritta "Attesa connessione Web Services" anche quelli sui binari facendo credere che sul binario sarebbe arrivato un Web Service !!!!! :-)
Come loro mi chiedo quante altre persone si saranno chiesto cosa c'entravano gli orari dei treni con Internet anche se, sicuramente, molte meno rispetto a quanti si saranno chiesto che fine aveva fatto il proprio treno !!!

Questo dovrebbe far riflettere sull'importanza della User Experience soprattutto in presenza di errori del sistema :-)

--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

Il materiale dell' Architect Insight Conferenze

mfontana — Mon, 19 May 2008 17:59:15 GMT

Il 28 e 29 Aprile si è svolto l' Architect Insight Conference in una stupenda cornice bucolica very british :-) appena fuori Londra.

Per me è stata l'occasione di rivedere alcuni colleghi ed amici... immersi nel verde :-)... ma lontani dai pub... :-(

La conferenza dedicata a Senior Architects, CTOs e decision makers quest'anno è stata suddivisa in quattro focalizzazioni :

Enterprise Architecture
Infrastructure Architecture
Solution Architecture
Software plus Services.

Lato sicurezza consiglio di visionare le presentazioni di Steve Plank (ottimo speaker) su:

A Claims Based Identity System dove tratta i concetti di base che hanno portato alla definizione dell' Identity Metasystem.
Whiteboard discussion of WS-Federation e WS-Trust. Questa sessione non è proprio introduttiva però permette di capire il flusso dei messaggi definiti dalle due specifiche.

La sessione di Benjamin Ravani (GM diGlobal Foundation Services) : Building Resilient Web Services invece riporta alcune interessanti considerazioni sulle sicurezza e disponibilità di servizi su Internet anche se da un'occhio prettamente sistemistico.

Infine, segnalo la sessione di Steve Lamb su Security Management for Dynamic virtual systems with Server 2008 and System Center per capire i principali rischi di sicurezza (e non solo) legate all'introduzione della virtualization all'interno delle nostre infrastrutture applicative.

L'intero materiale lo potete trovare sul sito di Microsoft UK.

--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

Progetto : WCF Security

mfontana — Fri, 11 Apr 2008 16:00:55 GMT

Su CodePlex è nato questo nuovo interessantissimo progetto di Patterns and Practices dedicato a WCF (Windows Communication Foundation) e la sicurezza. Una delle novità che ho maggiormente apprezzato è la suddivisione in scenari e relativa documentazione in stile how-to in modo da essere quanto più veloci nell'adattare le proprie soluzioni secondo queste best practices di sicurezza.

Sono disponibili anche vari video. Il progetto è appena iniziato e quindi manca ancora di molte parti essenziali ma è solo questione di tempo...

Alcune curiosità.

La struttura di questo progetto nasce da un lavoro pubblicato ormai nel lontano 28 maggio 2004.

Il focus di questo BIGINO (919 pagine) era l'architettura e l'implementazione di soluzione Web (più) sicure con .NET 1.1. Le tecnologie toccate quindi erano ASP.NET, CAS, Enterprise Services (COM+), Web Services, Remoting e data access. Il tomo era fatto bene ed entrava nei dettagli delle singole configurazioni suddivise per scenari (internet , intranet).

Gli anni passano e il 7 Agosto 2007 abbiamo un nuovo libro sulla sicurezza delle applicazioni incentrato questa volta solo sui Web Services con l'allora mitico WSE 3.0 (Web Services Enhancement - nome in codice WSDK Web Services SDK). sottolineao la versione 3.0, l'unica compatibile a livello di specifiche (non sempre però :-)) con WCF.. Era la Web Service Security Guide

Anche in questo caso abbiamo la suddivisione in scenari (molto più articolati rispetto al precedente)...L'unico problema di questo MINI BIGINO (solo 359 pagine) fa dei ragionamenti su un modello di programmazione basato su WSE che a livello architetturale è molto diverso da WCF...

cosa manca al nuovo lavoro?? Beh, una copertina :-)

--Mario