Security & Architecture : XML

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

Windows Web Services API – Come utilizzare gli esempi della documentazione su MSDN

mfontana — Sat, 28 Mar 2009 06:00:00 GMT

Su MSDN ci sono molti esempi di utilizzo delle Windows Web Services API. Per utilizzarli o si scaricano tutti i files di esempio (*.cpp, *.wsdl e makefile) oppure si crea una nuova solution in Visual Studio 2008 al cui interno si creano due applicazioni di tipo console.

Per la seconda opzione consiglio questo ordine :

Prima di tutto createvi una nuova solution contenente due progetti di tipo console e per entrambi togliete il supporto ai precompiled headers e aggiungete al linker la libreria webservices.lib (per il passo passo di queste azioni consultare questo mio post)

Partiamo dal service (prenderò come spunto l’esempio HttpCalculatorServiceExample su MSDN):

Creiamo una directory WSMetadata e creiamo il file CalculatorService.wsdl copiando il contenuto da qui.
Sempre nella directory WSMetadata lanciamo l’utility Wsutil.exe *.* che ci creerà i seguenti files :

CalculatorService.wsdl.c
CalculatorService.wsdl.h
Aggiungiamoli al nostro progetto.
A questo punto nel nostro file Service.cpp copiamo il codice presente qui.
e inseriamo in testa gli #include files

#include <webservices.h>
#include "wsmetadata\\CalculatorService.wsdl.h"

a questo punto possiamo compilare e tutto dovrebbe funzionare :-)

Passiamo al client (riferimento MSDN qui)

Aggiungiamo i files del punto 2 precedente.
A questo punto nel nostro file Client.cpp copiamo il codice presente qui.
Eseguiamo il punto 5 precedente.

Compilatina e anche il client dovrebbe essere pronto. A questo punto lanciate il service e poi il client e la calcolatrice unmanaged funzionerà :-)

--Mario

Windows Web Services API : Step-By-Step per creare un Web Service

mfontana — Fri, 27 Mar 2009 12:10:00 GMT

Nel mio post precedente abbiamo visto come scrivere un client C/C++ capace di invocare un servizio scritto in WCF.

In questo post vedremo come scrivere l’equivalente del servizio WCF in codice unmanaged tramite le WWSAPI.

A differenza della realizzazione di un client il server comporta ovviamente la scrittura a priori del WSDL e degli XSD !!! Questo perchè il linguaggio C/C++ non è così ricco di metadati come il framework .NET !! Quindi per gli amanti del contract-first nessun problema, mentre per i più pigri è sempre possibile definire l’interfaccia in WCF e quindi scaricare i metadati via svcutil /t:metadata :-) (come abbiamo fatto per il client)…

A questo punto possiamo avventurarci nella scrittura del nostro primo Web Service in C/C++

Creiamo un nuovo progetto di tipo Win32 Console Application.
Andiamo nella configurazione del progetto e selezioniamo All Configuration in alto a sinistra nella finestra di Property Page.
1. Selezioniamo Configuration Properties->C/C++ –> Precompiled Headers e alla voce Create/Use Precompiled Header impostiamo : Not Using Precompiled Headers.
2. Selezioniamo Configuration Properties->Linker->Input e alla voce Additional Dependencies scriviamo WebServices.lib.
Premiamo OK alla finestra di configurazione.
Includiamo i .h e .c presenti nella directory WSMetadata.
Aggiungiamo al progetto i files .h e .c presenti nella directory WSMetadata.
Aggiungiamo l’include ai file .h inseriti nel progetto e a <webservices.h>:

#include <webservices.h>
#include "..\\wsmetadata\\mariofontanapublicdemos.com.CalculatorService.Bindings.wsdl.h"
#include "..\\wsmetadata\\mariofontanapublicdemos.com.CalculatorService.wsdl.h"
#include "..\\wsmetadata\\mariofontanapublicdemos.com.CalculatorService.xsd.h"
#include "..\\wsmetadata\\schemas.microsoft.com.2003.10.Serialization.xsd.h"
Compiliamo…
Copiamo il codice riportato sotto e poi sempre animati da fiducia… compiliamo :-)

#include <iostream>
#include <conio.h>

// helper routine to print error object
void PrintError(HRESULT errorCode, WS_ERROR* error)
{
printf("Failure: errorCode=0x%lx\n", errorCode);

    if (errorCode == E_INVALIDARG || errorCode == WS_E_INVALID_OPERATION)
    {
        // Correct use of the APIs should never generate these errors
        printf("The error was due to an invalid use of an API. This is likely due to a bug in the program.\n");
        //DebugBreak();
    }

    HRESULT hr = NOERROR;
    if (error != NULL)
    {
        ULONG errorCount;
        hr = WsGetErrorProperty(error, WS_ERROR_PROPERTY_STRING_COUNT, &errorCount, sizeof(errorCount));
        if (FAILED(hr))
        {
            goto Exit;
        }
        for (ULONG i = 0; i < errorCount; i++)
        {
            WS_STRING string;
            hr = WsGetErrorString(error, i, &string);
            if (FAILED(hr))
            {
                goto Exit;
            }
            printf("%.*s\n", string.length, string.chars);
        }
    }
Exit:
    if (FAILED(hr))
    {
        printf("Could not get error string (errorCode=0x%lx)\n", hr);
    }
}

//questa è la vera e propria funzione callback che implementa il metodo Add

HRESULT CALLBACK Add(
    __in const WS_OPERATION_CONTEXT* context,
    __in int a,
    __in int b,
    __out __int64* result,
    __in_opt const WS_ASYNC_CONTEXT* asyncContext,
    __in_opt WS_ERROR* error)
{
    UNREFERENCED_PARAMETER(context);
    UNREFERENCED_PARAMETER(asyncContext);
    UNREFERENCED_PARAMETER(error);

    *result = a + b;
    printf ("%d + %d = %X\n", a, b, *result);
    fflush(stdout);
    return NOERROR;
}

int _tmain(int argc, _TCHAR* argv[])
{

    HRESULT hr;
    WS_ERROR* error;
    hr = WsCreateError(NULL,0, &error);
    if (FAILED(hr)) return -1;

    WS_HEAP* heap;
    hr= WsCreateHeap(1024,0,NULL,0,&heap, error);
    if(FAILED(hr))
    {
        WsFreeError(error);
        return -1;
    }

    wprintf(L"Hosting del mio primo Web Service in C/C++...\n");

BasicHttpBinding_ICalculatorFunctionTable Functions = {Add};

    WS_STRING url = WS_STRING_VALUE (L"http://localhost:8080/NativeCalculatorService");
    WS_HTTP_BINDING_TEMPLATE templateValue = {};
    WS_SERVICE_ENDPOINT* serviceEndpoint;
    hr = BasicHttpBinding_ICalculator_CreateServiceEndpoint (&templateValue,url,&Functions,NULL,NULL,0,heap,&serviceEndpoint,error);
    if(FAILED(hr))
    {
        PrintError(hr,error);
        WsFreeHeap(heap);
        WsFreeError(error);
        return -1;
    }

    WS_SERVICE_HOST* host = NULL;
    const WS_SERVICE_ENDPOINT* serviceEndpoints[1];
    serviceEndpoints[0] = serviceEndpoint;

    hr = WsCreateServiceHost(serviceEndpoints, 1,NULL, 0, &host, error);
    if(FAILED(hr))
    {
        PrintError(hr,error);
        WsFreeHeap(heap);
        WsFreeError(error);
        return -1;
    }

    hr = WsOpenServiceHost(host,NULL,error);
    if(FAILED(hr))
    {
        PrintError(hr,error);
        WsFreeServiceHost(host);
        WsFreeHeap(heap);
        WsFreeError(error);
        return -1;
    }

wprintf(L"Premi Enter per chiudere il servizio...\n");
_getch();

WsCloseServiceHost(host, NULL, error);
WsFreeServiceHost(host);

WsFreeHeap(heap);
WsFreeError(error);

return 0;

}

a questo punto Ctrl+F5 e lanciamo il nostro Web Service e torniamo sul codice client dove andremo a commentare il

#define _WCF

in modo da chiamare il Web Service che abbiamo appena creato. Come si può notare il codice client è il medesimo (salvo l’url) e possiamo invocare indistintamente Web Services scritti in WCF e in C/C++.

La schematizzazione del codice è la seguente :

--Mario

Windows Web Services API : Step->By-Step per il client

mfontana — Thu, 26 Mar 2009 17:21:40 GMT

Il metodo più semplice per provare la nuova libreria WWSAPI è quella di partire da uno scenario WWSAPI client che si integra con un servizio WCF. Passo successivo creeremo lo stesso servizio in C/C++ con WWSAPI e vedremo che lato client ci basterà cambiare l’url del Web Service permettendoci di invocare indistintamente quello sviluppato in WCF e in WWSAPI.

Per crearsi l’ambiente dovremo scaricare il seguente software :

Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP1 : BETA

Beta of Windows Web Services API for Windows XP, Vista, Server 2003 and Server 2008 (solo se non si sviluppa su WIndows 7 o Windows Server 2008 R2)

Web Service in WCF

Come prima cosa costruiamoci un servizio WCF (tipo di progetto VS2008 : WCF Service Application) che implementa una semplice interfaccia (ovviamente lo si può provare anche con un ASMX) :

namespace CalculatorService
{
    [ServiceContract(Namespace = "http://MarioFontanaPublicDemos.com/CalculatorService/")]
    public interface ICalculator
    {

[OperationContract]
long Add(int a, int b);

}
}

Assicurandoci di impostare il binding su basicHttpBindings. Dovremo avere un web.config simile a questo:

<system.serviceModel>
    <services>
      <service behaviorConfiguration="CalculatorService.CalculatorServiceBehavior" name="CalculatorServiceServiceConfiguration">
        <endpoint address="" bindingNamespace="http://MarioFontanaPublicDemos.com/CalculatorService/Bindings" binding="basicHttpBinding" bindingConfiguration="" contract="CalculatorService.ICalculator">
          <identity>
            <dns value="localhost"/>
          </identity>
        </endpoint>
        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
      </service>
    </services>
    <behaviors>
      <serviceBehaviors>
        <behavior name="CalculatorService.CalculatorServiceBehavior">
          <serviceMetadata httpGetEnabled="true"/>
          <serviceDebug includeExceptionDetailInFaults="false"/>
        </behavior>
      </serviceBehaviors>
    </behaviors>
</system.serviceModel>

A questo punto il nostro servizio dovrebbe avere un WSDL di questo tipo :

Prima di abbandonare il nostro servizio ricordiamoci di rendere fissa la porta su localhost. Nel caso di esempio : 62881 (quindi avremo : l’endpoint su : http://localhost:62881/CalculatorService.svc)

Client C/C++

Per creare il client C/C++ che consuma il nostro servizio WCF dobbiamo fare i seguenti passi :

Ottenere i metadati dal Web Service tramite l’utility svcutil.exe (Microsoft Service Model Metadata Tool)
Trasformare i metadati in dichiarazioni C tramite una seconda utility a riga di comando : wsutil.exe (Windows Web Services Tool) Attenzione : controllate che sia la versione 1.0079. in alcuni casi ho riscontrato che la versione 1.0069 che non funziona !!!
Step succesivo scrivere il codice client.

Vediamo passo passo come fare :

Creiamo un nuovo progetto di tipo Win32 Console Application (può andare anche un qualsiasi progetto con interfaccia grafica, ma sapete io sono un nostalgico della cara vecchia console :-) e premiamo pure su finish perchè non ci interessa nessuna customizzazione.
Andiamo nella configurazione del progetto e selezioniamo All Configuration in alto a sinistra nella finestra di Property Page.
1. Selezioniamo Configuration Properties->C/C++ –> Precompiled Headers e alla voce Create/Use Precompiled Header impostiamo : Not Using Precompiled Headers.
2. Selezioniamo Configuration Properties->Linker->Input e alla voce Additional Dependencies scriviamo WebServices.lib.
Premiamo OK alla finestra di configurazione.
Apriamo una console amministrativa e andiamo nella directory del nostro client. Qui possiamo creare una directory ad esempio : WSMetadata.
Entriamo nella directory WSMetadata e lanciamo la nuova versione dell’utility a riga di comando svcutil.exe /t:metadata <indirizzo del nostro servizio WCF> quindi sarà ad esempio :

svcutil.exe /t:metadata http://localhost:62881/CalculatorService.svc.

In questo modo abbiamo scaricato i metadati dal servizio, ovvero il WSDL e gli xsd, e dovremmo avere un file WSDL e uno o più file XSD. Nel nostro caso avremo

mariofontanapublicdemos.com.CalculatorService.Bindings.wsdl
mariofontanapublicdemos.com.CalculatorService.wsdl
mariofontanapublicdemos.com.CalculatorService.xsd
schemas.microsoft.com.2003.10.Serialization.xsd
A questo punto lanciamo un’altra utility a riga di comando wsutil.exe *.* (assicurarsi che non ci siano altri file oltre quelli creati nel punto precedente perchè altrimenti viene ovviamente generato un errore). Con questa operazione abbiamo creato per ogni file presente nella directory un equivalente .c e .h con la descrizione dello schema, del wsdl e delle policy che andermo ad includere nel nostro progetto. Nel nostro caso avremo quindi 12 files :

mariofontanapublicdemos.com.CalculatorService.Bindings.wsdl
mariofontanapublicdemos.com.CalculatorService.Bindings.wsdl.c
mariofontanapublicdemos.com.CalculatorService.Bindings.wsdl.h
mariofontanapublicdemos.com.CalculatorService.wsdl
mariofontanapublicdemos.com.CalculatorService.wsdl.c
mariofontanapublicdemos.com.CalculatorService.wsdl.h
mariofontanapublicdemos.com.CalculatorService.xsd
mariofontanapublicdemos.com.CalculatorService.xsd.c
mariofontanapublicdemos.com.CalculatorService.xsd.h
schemas.microsoft.com.2003.10.Serialization.xsd
schemas.microsoft.com.2003.10.Serialization.xsd.c
schemas.microsoft.com.2003.10.Serialization.xsd.h
Aggiungiamo al progetto i files .h e .c appena creati nella directory WSMetadata.
Aggiungiamo l’include ai file .h inseriti nel progetto e a <webservices.h>:

#include <webservices.h>
#include "..\\wsmetadata\\mariofontanapublicdemos.com.CalculatorService.Bindings.wsdl.h"
#include "..\\wsmetadata\\mariofontanapublicdemos.com.CalculatorService.wsdl.h"
#include "..\\wsmetadata\\mariofontanapublicdemos.com.CalculatorService.xsd.h"
#include "..\\wsmetadata\\schemas.microsoft.com.2003.10.Serialization.xsd.h"
Primo momento della verità : compilatina…e dovrebbe andare tutto OK
Copiamo il codice riportato sotto e poi possiamo compilare nuovamente fiduciosi :-)

#include <iostream>
#include <conio.h>

WCHAR* WsGetErrorDescription(HRESULT hr);

//#define _WCF

int _tmain(int argc, _TCHAR* argv[])
{
    HRESULT hr;
    WS_ERROR* error;
    hr = WsCreateError(NULL,0, &error);
    if (FAILED(hr)) return -1;

    WS_HEAP* heap;
    hr= WsCreateHeap(1024,0,NULL,0,&heap, error);
    if(FAILED(hr))
    {
        WsFreeError(error);
        return -1;
    }

WS_SERVICE_PROXY* serviceProxy;
WS_HTTP_BINDING_TEMPLATE templateValue = {};

    hr = BasicHttpBinding_ICalculator_CreateServiceProxy(
        &templateValue,
        NULL,
        0,
        &serviceProxy,
        error);

    if(FAILED(hr))
    {
        WsFreeHeap(heap);
        WsFreeError(error);
        return -1;
    }

WS_ENDPOINT_ADDRESS address = {};

#ifdef _WCF
WS_STRING Url = WS_STRING_VALUE(L"http://localhost:62881/CalculatorService.svc");
#else
WS_STRING Url = WS_STRING_VALUE(L"http://localhost:8080/NativeCalculatorService");
#endif

address.url = Url;
hr = WsOpenServiceProxy(serviceProxy, &address, NULL, error);

    if (FAILED(hr))
    {
        WsFreeServiceProxy(serviceProxy);
        WsFreeHeap(heap);
        WsFreeError(error);
        return -1;
    }
    int a = 1;
    int b = 2;
    __int64 result=0;
    hr = BasicHttpBinding_ICalculator_Add(serviceProxy,a,b,&result,heap,NULL,NULL,NULL,error);

    if (SUCCEEDED(hr))
    {
        wprintf(L"Invocazione del servizio Calculator : %d + %d = %X \n", a,b,result);

    }else
    {
        std::wcerr << static_cast<LPCTSTR>(WsGetErrorDescription(hr)) << std::endl;

        WS_STRING errordesc;
        hr = ::WsGetErrorString(error, 0, &errordesc);
        if (SUCCEEDED(hr))
        {
            std::wcerr << static_cast<LPCTSTR>(errordesc.chars) << std::endl;
        }
        else
        {
            wprintf(L"Ti sei ricordato di attivare il service host??");
        }
    }

_getch();

WsCloseServiceProxy(serviceProxy, NULL, error);

WsFreeServiceProxy(serviceProxy);

WsFreeHeap(heap);
WsFreeError(error);
}

WCHAR* WsGetErrorDescription(HRESULT hr)
{
switch(hr){

                    case WS_S_ASYNC:
                            return L" The function call is completing asynchronously";
                          break;
                    case WS_S_END:
                            return L" There are no more messages available on the channel";
                          break;
                    case WS_E_INVALID_FORMAT:
                            return L" The input data was not in the expected format or did not have the expected value";
                          break;
                    case WS_E_OBJECT_FAULTED:
                            return L" The operation could not be completed because the object is in a faulted state due to a previous error";
                          break;
                    case WS_E_NUMERIC_OVERFLOW:
                            return L" The operation could not be completed because it would lead to numeric overflow";
                          break;
                    case WS_E_INVALID_OPERATION:
                            return L" The operation is not allowed due to the current state of the object";
                          break;
                    case WS_E_OPERATION_ABORTED:
                            return L" The operation was aborted";
                          break;
                    case WS_E_ENDPOINT_ACCESS_DENIED:
                            return L" Access was denied by the remote endpoint";
                          break;
                    case WS_E_OPERATION_TIMED_OUT:
                            return L" The operation did not complete within the time allotted";
                          break;
                    case WS_E_OPERATION_ABANDONED:
                            return L" The operation was abandoned";
                          break;
                    case WS_E_QUOTA_EXCEEDED:
                            return L" A quota was exceeded";
                          break;
                    case WS_E_NO_TRANSLATION_AVAILABLE:
                            return L" The information was not available in the specified language";
                          break;
                    case WS_E_SECURITY_VERIFICATION_FAILURE:
                            return L" Security verification was not successful for the received data";
                          break;
                    case WS_E_ADDRESS_IN_USE:
                            return L" The address is already being used";
                          break;
                    case WS_E_ADDRESS_NOT_AVAILABLE:
                            return L" The address is not valid for this context";
                          break;
                    case WS_E_ENDPOINT_NOT_FOUND:
                            return L" The remote endpoint does not exist or could not be located";
                          break;
                    case WS_E_ENDPOINT_NOT_AVAILABLE:
                            return L" The remote endpoint is not currently in service at this location";
                          break;
                    case WS_E_ENDPOINT_FAILURE:
                            return L" The remote endpoint could not process the request";
                          break;
                    case WS_E_ENDPOINT_UNREACHABLE:
                            return L" The remote endpoint was not reachable";
                          break;
                    case WS_E_ENDPOINT_ACTION_NOT_SUPPORTED:
                            return L" The operation was not supported by the remote endpoint";
                          break;
                    case WS_E_ENDPOINT_TOO_BUSY:
                            return L" The remote endpoint is unable to process the request due to being overloaded";
                          break;
                    case WS_E_ENDPOINT_FAULT_RECEIVED:
                            return L" A message containing a fault was received from the remote endpoint";
                          break;
                    case WS_E_ENDPOINT_DISCONNECTED:
                            return L" The connection with the remote endpoint was terminated";
                          break;
                    case WS_E_PROXY_FAILURE:
                            return L" The HTTP proxy server could not process the request";
                          break;
                    case WS_E_PROXY_NOT_FOUND:
                            return L" The HTTP proxy server does not exist or could not be located";
                          break;
                    case WS_E_PROXY_ACCESS_DENIED:
                            return L" Access was denied by the HTTP proxy server";
                          break;
                    case WS_E_NOT_SUPPORTED:
                            return L" The requested feature is not available on this platform";
                          break;
                    case WS_E_PROXY_REQUIRES_BASIC_AUTH:
                            return L" The HTTP proxy server requires HTTP authentication scheme ";
                          break;
                    case WS_E_PROXY_REQUIRES_DIGEST_AUTH:
                            return L" The HTTP proxy server requires HTTP authentication scheme ";
                          break;
                    case WS_E_PROXY_REQUIRES_NTLM_AUTH:
                            return L" The HTTP proxy server requires HTTP authentication scheme ";
                          break;
                    case WS_E_PROXY_REQUIRES_NEGOTIATE_AUTH:
                            return L" The HTTP proxy server requires HTTP authentication scheme ";
                          break;
                    case WS_E_SERVER_REQUIRES_BASIC_AUTH:
                            return L" The remote endpoint requires HTTP authentication scheme ";
                          break;
                    case WS_E_SERVER_REQUIRES_DIGEST_AUTH:
                            return L" The remote endpoint requires HTTP authentication scheme ";
                          break;
                    case WS_E_SERVER_REQUIRES_NTLM_AUTH:
                            return L" The remote endpoint requires HTTP authentication scheme ";
                          break;
                    case WS_E_SERVER_REQUIRES_NEGOTIATE_AUTH:
                            return L" The remote endpoint requires HTTP authentication scheme ";
                          break;
                    case WS_E_INVALID_ENDPOINT_URL:
                            return L" The endpoint address URL is invalid";
                          break;

}

Volendo schematizzare le macro funzioni del codice :

Lanciando prima il Web Service in WCF e poi il nostro clientino dovremmo avere la fatidica risposta della somma !!

Nel prossimo post creeremo lo stesso servizio con le Windows Web Services API per dimostrare la completa interoperabilità tra WCF e WWSAPI.

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

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

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

Autenticazione nelle comunicazioni : sicurezza a livello di canale

mfontana — Sat, 29 Mar 2008 14:34:00 GMT

Quando ci troviamo a progettare la forma di autenticazione nelle architetture Service-Oriented dobbiamo considerare vari aspetti relativi allo scenario.

L’identificazione dell’utente che sta compiendo una determinata operazione è alla base di ogni sistema di sicurezza.

Indipendente dal modello di autenticazione utilizzato, il processo di riconoscimento dell’utente prevede la definizione di un protocollo di autenticazione end to end tra i vari (spesso due, ma non è detto) attori della comunicazione a livello di sistema o applicativo per garantire il riconoscimento dell’utente. Il protocollo di autenticazione definisce, quindi, le modalità con le quali il servizio riconosce il chiamante.

Una comunicazione tra due servizi (end to end) costituisce l’elemento base della classica catena di chiamate a cascata tipiche degli scenari complessi. Una volta stabilite le modalità di autenticazione, il processo di riconoscimento dell’utente deve implementare un ben determinato modello di autenticazione per consentire al servizio chiamato di ottenere il corretto contesto di sicurezza (security context) del chiamante, indipendentemente dal flusso di chiamate e dalla posizione del servizio all’interno della catena di chiamate stesse. Al servizio chiamato a sua volta può utilizzare nel modo corretto le informazioni messe a disposizione dal modello utilizzato per realizzare le politiche di sicurezza necessarie.

Le modalità di autenticazione, come detto, definiscono il protocollo con cui il chiamante fornisce al servizio le informazioni di sicurezza per il riconoscimento dell’utente. La scelta della modalità di autenticazione da utilizzare è condizionata da vari fattori: tipo di applicazioni, modalità di colloqui tra chiamante e servizio, piattaforma utilizzata,….Le modalità di autenticazione offrono caratteristiche diverse dipendenti dal livello a cui vengono implementate. In generale esistono tre grandi famiglie di modalità di autenticazione:

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

Sicurezza a livello di canale

La modalità basata sulla sicurezza a livello di canale di comunicazione utilizza il canale di trasporto tra i due end point della comunicazione, per lo scambio delle informazioni necessarie al riconoscimento dell’utente.

Figura 1: modelli di autenticazione a livello di canale di comunicazione

Il protocollo di autenticazione utilizzato in questo caso è strettamente dipendente sia dal canale di comunicazione utilizzato che dalla sicurezza supportata dalla piattaforma.

L’autenticazione è, quindi, trasparente alle applicazioni e configurata a livello di sistema in moda da consentire al chiamante e servizio di instaurare il corretto protocollo per lo scambio delle informazioni.

I vantaggi di questa modalità sono essenzialmente nella semplicità di utilizzo (da parte delle applicazioni) e nella sicurezza offerta, definita dallo stesso canale di comunicazione utilizzato.

Di contro, però la sicurezza di canale, avendo come unica granularità applicabile l’intero messaggio, è molto rigida e non consente di applicare politiche di sicurezza su singole porzioni di messaggio.

Quando usarla

La modalità di autenticazione a livello di canale (trasporto) è semplice e generalmente adeguata in scenari dove i meccanismi di trasporto e i partner della comunicazione sono fortemente controllati.

I maggiori vincoli sono:

basando tutto a livello di trasporto, l’autenticazione è fortemente dipendente dalla piattaforma utilizzata e dai servizi di sicurezza forniti da questa,
l’autenticazione non dipende dalla tipologia di messaggio/richiesta effettuata, non entra nel merito del formato, dei dati e non distingue singole porzioni di messaggio,
l’autenticazione è applicata agli end point della comunicazione senza la possibilità (se non supportata dai meccanismi di sicurezza della piattaforma utilizzata) di fluire in una catena di richieste e tra intermediari.

Nel prossimo post analizzeremo l'autenticazione a livello applicativo....

--Mario

Le specifiche di XAML

mfontana — Fri, 28 Mar 2008 21:34:58 GMT

Lo XAML (Microsoft Extensible Application Markup Language) rappresenta un po' la lingua franca basata su XML di varie tecnologie MS come WPF (Windows Presentation Foundation), WF (Workflow Foundation) e Silverlight.Infatti lo XAML è un XML document type per l'organizzazione di dati generati dai vari runtime.

Da qualche giorno sono disponibili alcune specifiche dello XAML. Questi primi documenti parlano dello Xaml Object Mapping con particolare focus sul data model for Types e object hierarchies più vari tecniche per il mapping. Certo non è una lettura tipica da "comodino" però è importante per architetti e sviluppatori più senior (che già hanno esperienza di XAML) per capire meglio come funzionano gli internals di questa specifica che sta diventando sempre più centrale in molte tecnologie Microsoft.

Anche in questo caso le specifiche sono state rilasciate sotto la Microsoft Open Specificiation Promise che di fatto permette di utilizzare liberamente queste specifiche all'interno dei propri prodotti.

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