WSE - Web Services Enhancements
Av Johan Lindfors, Microsoft AB

I WSE har Microsoft implementerat ett antal specifikationer rörande bland annat säkerhet och tillförlitlighet som standardiserats på Internet av olika standardiseringsorgan, både W3C:s och OASIS specifikationer finns representerade vilket indikerar på en stark potential för interoperabiltitet mellan olika plattformar, operativsystem och programmeringsspråk. Den viktigaste byggstenen för denna interoperabiltitet är SOAP (Simple Object Access Protocol) som definererar en XML-grammatik för att strukturera ett medddelande som ett kuvert (SOAP-envelope) innehållande ett brevhuvud (SOAP-header) och en meddelandekropp (SOAP-body), hela meddelandet representeras med hjälp av XML och kan därför läsas av många olika operativsystem och applikationer. SOAP är också utvecklat från början för att vara väldigt modulärt, alltså tillåta tillägg till meddelanden för att kunna anpassas till olika lösningar och det är med hjälp av den modulariteten som WSE bygger vidare på en redan idag mycket accepterad teknik och arkitektur.

<Envelope>
    <Header/>
    <Body>
        <AddInt>
            <a>11</a>
            <b>22</b>
        </AddInt>
    </Body>
</Envelope>

Koden ovan visar strukturen av ett SOAP meddelande i pseudokod.

Mer läsning om WSE
Ladda hem WSE 2.0 SP1 och prova själv
Grundläggande artiklar om WSE
Introduktion till WSE på svenska MSDN TV
Nyheterna i och med WSE 2.0

Säkerhet
Webbservices kan idag säkras på flera olika sätt men det finns vanligtvis begränsningar när det gäller att bygga skalbara distribuerade lösningar. Om vi exempelvis väljer att använda SSL (Secure Sockets Layer) och vi behöver vidarehänvisa meddelanden som skickas över nätet via olika servrar, uppstår utmaningen med att autentisera sändaren för mottagaren och samtidigt ha en prestanda som är godtagbar på lösningen.
Istället för att kräva att underliggande transportprotokoll eller fysiskt nätverk använder säkerhet ser WSE istället till att möjligheten finns att applicera säkerhet på meddelanden. Vanligen skickas dessa meddelande som SOAP-meddelanden mellan klient och server men WSE har en så pass flexibel arkitektur och det är fullt möjligt att skicka meddelanden krypterat och signerat över ren TCP eller till och med via SMTP.
WSE åstadkommer den här säkerhetsmodellen genom att använda tekniker definerade i WS-Security specifikationen för att placera säkerhetsinformation i SOAP-meddelandet. Detta görs genom att begära information från klienten som både sändaren och mottagaren förstår och accepterar, denna information agerar bevis eller ”token” och placeras i huvudet på SOAP-meddelandet. Denna teknik gör det också möjligt för mottagaren att kontrollera beviset utan att behöva göra ytterligare anrop till klienten, innan anropet till servern skickas vidare till webbservicen för exekvering. Det finns idag ett antal redan skapade bevistyper som kan användas i en lösning, men naturligtvis går det också att skapa egna typer av bevis för att passa in i scenarios som kräver det.
De här bevisen kan också användas för att signera eller kryptera delar av SOAP-meddelanden för att ytterligare förbättra säkerheten mellan klienten och servern. WSE erbjuder tre funktioner som bidrar till säker kommunikation med SOAP-meddelanden.

<Envelope>
   <Header>
        <Security>
            <Token/>
        </Security>
    </Header>
    <Body>
        <AddInt>
            <a>11</a>
            <b>22</b>
        </AddInt>
    </Body>
</Envelope>

Koden ovan visar i pseudokod hur WSE skapar tillägg till SOAP-huvudet för säkerhet.

Bevis erbjuder bland annat så kallad autentisering, alltså möjligheten för en mottagare att ta reda på vem sändaren utger sig för att vara. Bevis kan bestå av användarnamn och lösenord, baseras på certifikat eller Kerberos-”tickets”. Utvecklare kan också skapa egna bevis antingen med hjälp av XML eller en binär representation.

Digitala signaturer gör så att mottagaren av ett SOAP-meddelande kan garanterat veta att meddelandet inte har påverkats eller förändrats vid transport efter det att sändaren har signerat det. Signering av meddelanden görs genom användandet av ett privat och publikt nyckelpar, där den privata nyckeln används för att kryptera en checksumma beräknat på delar av meddelandet som ska skickas, och den publika nyckeln används på mottagarens sida för att dekryptera denna checksumma och med hjälp av samma beräkning efter transport kunna jämföra checksummor och på så sätt identifiera eventuell påverkan av meddelandet.


Med hjälp av sändarens privata nyckel skapas en digital signatur.

Kryptering används för att tillåta att endast mottagaren av meddelandet kan dekryptera meddelandet och få tillgång till informationen som skickats. Även här använts ofta ett privat och publikt nyckelpar, men den här gången används den publika nyckeln på sändarsidan för att kryptera den information som ska skickas säkert, och mottagaren, som är den enda med tillgång till den privat nyckeln, blir då den enda som kan läsa informationen efter dekryptering.


Endast mottagaren med korrekt privat nyckel kan dekryptera meddelandet.

Mer läsning om säkerheten med WSE
Digitala signaturer och kryptering med XML
Djupdykning i säkerhetsmodellen med WS-Security
Säkerhet med WSE på amerikanska MSDN TV

Adressering
I tidigare versioner av WSE användes specifikationerna WS-Referral och WS-Routing för att säkerställa att meddelanden kom fram till rätt slutdestination samt kunde routas över eventuella brandväggar och servrar. I och med WSE 2.0 används numera WS-Addressing som ersätter de tidigare använda specifikationerna.

Mer läsning om WS-Addressing
Läs mer om WS-Addressing här

Mer om meddelandehantering

Regelverk – ”Policy”
I version 2.0 av WSE kan utvecklare uttrycka krav på emottagande och sändning av meddelande med hjälp av konfigurationsfiler i XML istället för att skriva kod i funktionerna för varje klient eller server i en lösning. Utvecklaren kan konfigurera sina webbservices att till exempel kräva kryptering av delar i meddelanden samt att sändaren skickar ett specifikt bevis för att kunna autentiseras. En regelfil eller ”policy” delas upp i två delar, mappningar (”mappings”) och regler (”policy assertions”). I exemplet nedan mappas funktionen ”StockQuoteRequest” på URL:n ”http://www.microsoft.com/Service.asmx” till två olika regler, en för meddelanden som tas emot (”requests”) och en för svar som skickas (”response”). I gruppen ”policies” finns sedan de två reglerna definerade, där den första regeln som har identiteten ”SignBody” kräver att kroppen (”Body”) på meddelanden signeras med ett X509v3-certifikat som heter ”CN=SignCertificate”. Den andra regeln med identiteten ”EncryptWithX509” kräver att kroppen i svaret från webbservicen krypteras med ett X509v3-certifikat.

<policyDocument>
    <mappings>
        <endpoint uri="
http://www.microsoft.com/Service.asmx">
            <operation requestAction="StockQuoteRequest">
                <request policy="#SignBody" />
                <response policy="#EncryptWithX509" />
            </operation>
        </endpoint>
    </mappings>
    <policies>
        <Policy Id="SignBody">
            <Integrity>
                <TokenInfo>
                    <SecurityToken>
                        <TokenType>X509v3</TokenType>
                        <Claims>
                            <SubjectName>CN=SignCertificate</SubjectName>
                        </Claims>
                    </SecurityToken>
                </TokenInfo>
                <MessageParts>Body</MessageParts>
            </Integrity>
        </Policy>
        <Policy Id="EncryptWithX509">
            <Confidentiality>
                <KeyInfo>
                    <SecurityToken>
                        <TokenType>X509v3</TokenType>
                    </SecurityToken>
                </KeyInfo>
                <MessageParts>Body</MessageParts>
            </Confidentiality>
        </Policy>
    </policies>
</policyDocument>
Ett exempel i pseudokod på hur en deklarativ regel i XML kräver signering av meddelanden som tas emot och krypterar meddelanden som skickas tillbaka.

Läs mer om WS-Policy
WS-Policy i WSE 2.0

 

Arkitekturen – ”Pipeline”
I WSE finns en kraftfull arkitektur för skickandet och mottagandet av meddelanden med hjälp av en så kallad ”pipeline” precis som i flera redan existerande produtkter, allt från Site Server till BizTalk Server 2004. Denna ”pipeline” består av några fördefinerade steg eller filter som meddelandet kommer att transporteras via innan det fysiskt skickas över nätverket, i varje filter kan meddelandet påverkas och SOAP-huvuden läggas till eller modifieras. På mottagarens sida tas meddelandet emot av en likadan ”pipeline” och meddelandet transporteras genom alla filter i omvänd ordning innan det lämnas över för exekvering. Som utvecklare går det naturligtvis att skapa egna filters och lägga till dessa till både den utgående och inkommande ”pipelinen”, de filters som finns med i WSE vid installation är:

  • Timestamp – lägger till eller läser en tidsanvisning på meddelanden.
  • Security – hanterar säkerheten, autentisering, signering och kryptering.
  • Trace – ger möjligheten att spara inkommande och utgående meddelanden på disk.


Både på klienten och servern existerar en identisk uppsättning filters som meddelanden passerar

Mer läsning om programmeringsmodellen
Läs mer om arkitekturen bakom WSE 2.0

Sammanfattning
WSE är en samling klasser som installeras bredvid Microsoft .NET Framework och möjliggör säkerhet och tillförlitlighet på kommunikation med SOAP. Innan Longhorn introducerar en integrerad arkitektur för säker och tillförlitlig kommunikation oavsett transportprotokoll i och med Indigo är det tänkt att vi på Microsoft släpper WSE 3.0 med en del uppdateringar, när det är dags så kommer jag att uppdatera den här artikeln och infoga ytterligare länkar, under tiden så vill jag rekommendera dig till att ladda ned WSE 2.0 och börja utforska de mycket omfattande exempelapplikationerna som följer med installationen och demonstrerar de flesta av funktionerna i ramverket.