SOAP Security Enhancement pre ASP.NET webové služby

Obsah práce

1.	XML a webové služby
2.	XML ASP.NET webové služby
3.	Zabezpečennie webových aplikácií
4.	Integrita a dôvernosť komunikácie
5.	Autentifikácia
6.	Autorizácia webových služieb
7.	Zabezpečenie webových služieb
8.	XML security
9.	SOAP Security Enhancement pre ASP.NET webové služby

SOAP Security Enhancement pre ASP.NET webové služby

V predchádzajúcich dvoch kapitolách sme si opísali teoretické možnosti zabezpečenia XML ASP.NET webových služieb a štandardy zamerané na bezpečnosť XML. Táto kapitola sa zaoberá vývojom vlastnej bezpečnostnej platformy pre XML ASP.NET webové služby v jazyku C , ktorú sme nazvali SOAP Security Enhancement (SSE) Naša bezpečnostná platforma bude predstavovať zabezpečenie na úrovni správ a tiež na úrovni aplikácie. Pri vytváraní bezpečnostného systému pre webové aplikácie treba zabezpečiť:

• Mechanizmus pre overovanie klientskych aplikácií. Možnosti overovania klientov sme si podrobne rozobrali v kapitolách 5, 5.1, 5.2, 5.3.
• Mechanizmus pre autorizáciu klientov overených webovou službou. Spôsobmi autorizácie sme sa zaoberali kapitolách 5.1, kde sme sa zaoberali autorizáciou s využitým webového servera IIS a takisto autorizáciou prostredníctvom konfiguračného súboru webovej služby, ktorú sme si opísali v kapitole 6.
• Mechanizmus pre zabezpečenie dôvernosti a integrity komunikácie. Spôsobov na vytvorenie bezpečnej komunikačnej linky je viacero. Najrozšírenejší spôsob je použitie technológie SSL, ktorou sme sa zaoberali v podkapitole 4.1. Táto technológia má aj svoje nedostatky, ktoré sme načrtli v kapitole 7 a s ktorými sa oboznámime v podkapitole 9.7.1.

V príslušných kapitolách sme vysvetlili výhody, nevýhody a oblasti použitia daných mechanizmov pre autentifikáciu, autorizáciu a zabezpečenie dôvernosti a integrity komunikácie. V tejto kapitole ponúkame vlastný komplexný spôsob, ako zabezpečiť komunikáciu medzi XML ASP.NET webovou službou a klientskou aplikáciou na platforme .NET Framework 3.5.

V Tab. 9.1 sú prehľadne opísané spôsoby a technológie, ktoré použijeme na autentifikáciu, autorizáciu a zabezpečenie dôvernosti a integrity komunikácie. Tie podrobnejšie popíšeme a vysvetlíme nasledujúcich podkapitolách.

Tab. 9.1 Popis technológií použitých pri vlastnej bezpečnostnej platforme

Mechanizmus	Technológia
Autentifikácia	Certifikát X509
Autorizácia	Autorizácia bude realizovaná prostredníctvom programovej impersonácie, ktorú sme si vysvetlili v podkapitole 5.2.1.
Integrita a dôvernosť komunikácie	Integrita a dôvernosť komunikácie bude zabezpečená prostredníctvom selektívneho šifrovania SOAP správ s využitím Advanced Encryption Standard a prostredníctvom digitálneho podpisovania SOAP správ pomocou certifikátov X509 s využitím štandardu XML Signature.

Štruktúra SOAP Security Enhancement z objektovo-orientovaného prístupu

V Tab. 9.2 sú prehľadne opísané základné programové triedy bezpečnostnej platformy spolu s ich funkcionalitou. Podrobnejšie budú opísané v príslušných podkapitolách.

Tab. 9.2 Triedy bezpečnostnej platformy

Názov triedy	Popis
AbstractDatabase	Trieda vytvorená podľa návrhového vzoru Abstract Factory, ktorá umožňuje flexibilne vytvoriť triedu na prístup k databázovému úložisku podľa konkrétneho DBMS.
DbProvider	Trieda pre prístup k MS SQL databázovému úložisku.
SecureExtension	Trieda SOAP rozšírenia umožňuje prístup k SOAP správam v rôznych etapách spracovania.
SecureExtensionAttribute	Predstavuje atribút SOAP rozšírenia, pomocou ktorého sa špecifikujú konkrétne časti (elementy) SOAP správy ktoré budú šifrované a digitálne podpísané.
SecureExtensionUtilities	Táto trieda obsahuje metódy na šifrovanie, dešifrovanie, digitálne podpisovanie a verifikáciu digitálneho podpisu SOAP správ.
SecureUtilities	Zabezpečuje autentifikáciu klienta, vygenerovanie parametrov AES šifry a vytvorenie konfiguračného XML dokumentu obsahujúce parametre pre bezpečnú komunikáciu.
TicketIdentity	Táto trieda reprezentuje autentifikačný lístok umiestnený v SOAP hlavičke klienta.
UserData	Predstavuje „data object“ reprezentujúci údaje pre šifrovanie a digitálne podpisovanie SOAP správ.
UserImpersonation	TTrieda zabezpečuje mechanizmus autorizácie prostredníctvom Windows impersonácie.

Autentifikácia klientov v SOAP Security Enhancement

Možnosti na overovanie klientov pre XML ASP.NET webové služby sú značne obmedzené. Kedže webová služba neposkytuje žiaden vstavaný spôsob akým, by mohol užívateľ predložiť prihlasovacie údaje, napríklad webový formulár. Najrozšírenejšie spôsoby overovania klientov webovou službou sú tieto [1]:

• Autentifikácie Windows. Tento typ nie je veľmi flexibilný a má veľa nedostatkov, ktoré sme si opísali v kapitole 5.1.
• Vlastný typ autentifikačného procesu založeného na prihlasovacích lístkoch s využitím SOAP rozšírenia.
• Použitie klientskych certifikátov X509.

Autentifikáciu založenú na certifikátoch X509 sme zvolili z nasledujúcich dôvodov:

1. Použitie klientskych certifikátov dáva značnú kontrolu nad užívateľskými identitami, nakoľko certifikáty sú vydávané certifikačnou autoritou, ktorá býva zvyčajne pod kontrolou administrátora servera, na ktorom môže byť hosťovaná webová služba. Tak isto je možné klientske certifikáty mapovať na užívateľské účty Windows, či už priamo na webovom serveri IIS alebo priamo programovo vo webovej službe.

2. Certifikáty X509 predstavujú účinnú ochranu proti podvrhnutiu falošného verejného kľúča ( Man-in-the-Middle Attack [36] ).

3. Tak isto predstavuje účinný mechanizmus na zabezpečenie toho, že vlastník verejného kľúča má k nemu zodpovedajúci súkromný kľúč.

Certifikátom sme sa podrobnejšie venovali v podkapitole 4.1.1. Na vystavenie klientskych certifikátov sme vytvorili vlastnú testovaciu certifikačnú autoritu na operačnom systéme Windows Server 2003.

Počiatočnú autentifikáciu sme sa rozhodli teda realizovať prostredníctvom klientskych certifikátov X509. Na korektný prenos certifikátov X509 je nutný HTTPS prenos.

Kedže použitie technológie SSL má aj nedostatky a pri prenose veľkého množstva dát je náročné, rozhodli sme sa, že HTTPS kanál bude použitý pri komunikácii klienta a webovej služby iba raz, a to pri počiatočnom volaní webovej metódy, ktorá zabezpečí overenie klienta na základe klientskeho certifikátu X509. Následne bude klientovi vydaný „autentifikačný lístok", ktorý bude umiestnený do SOAP hlavičky. Lístok obsahuje 128 bitové jedinečné číslo, ktoré identifikuje užívateľa pri nasledujúcich volaniach webových metód, a je použitý na jeho overenie. Lístok sa vydáva klientovi s určitou časovou platnosťou, ktorú je možné podľa potreby a priority meniť.

Hodnota ID v autentifikačnom lístku je uložená spolu s príslušnými údajmi z klientskeho certifikátu do relačnej databázy, ktorú webová služba používa na ďalšie overovanie klienta pri volaní webových metód.

Proces prvotnej autentifikácie je nasledovný. Pri počiatočnom prístupe klienta k webovej službe musí klient zavolať webovú metódu CreateConnection webovej služby. Metóda

CreateConnection plní v komunikačnom scenári nasledujúce funkcie:

• Overenie klientskeho certifikátu.
• Vytvorenie SOAP hlavičky s užívateľským ID.
• Zápis príslušných parametrov z klientskeho certifikátu do databázy.
• Vygenerovanie a zaslanie parametrov AES, ktoré sú použité na šifrovanie SOAP správ.

Prostredníctvom vlastnosti Context, ktorú trieda webovej služby získala odvodením z abstraktnej triedy WebService (pozri podkapitola 2.1), je extrahovaný klientsky certifikát.

Tab. 9.3 Extrahovanie klientského certifikátu z vlastnosti Context

X509Certificate2 cert = new X509Certificate2(Context.Request.ClientCertificate.Certificate);

Následne je klientsky certifikát overený na revokáciu a dôveryhodnosť certifikačnej autority.

Pokiaľ je certifikát klienta úspešne overený, webová metóda CreateConnection vygeneruje hodnotu ID v autentifikačnom lístku.

Po vygenerovaní ID pre overeného klienta sú údaje z klientskeho certifikátu (verejný kľúč a common name), ID klienta spolu s dátumom a časom vytvorenia lístka zapísané do databázy. Následne je vytvorená SOAP hlavička , do ktorej je umiestnené ID užívateľa.

Výhoda vlastného autentifikačného systému na lístkoch:

• Výhoda vytvorenia SOAP hlavičky je tá, že objekt proxy ju na strane klienta automaticky udržuje. Pokiaľ klient používa rovnakú inštanciu triedy proxy, bude automaticky pri ďalšom odosielaní SOAP správ na webovú službu posielaný aj autentifikačný lístok v SOAP hlavičke.
• Pri opätovnom volaní webových metód nemusí byť posielaný s požiadavkou aplikácie aj klientsky certifikát. Vďaka tomu nemusí byť opätovne použité aj HTTPS spojenie.
• Autentifikačný lístok môže byť aplikácii vydaný s určitou časovou platnosťou, čo zvyšuje flexibilitu systému.

Parametre AES šifry sú zaslané webovou metódou CreateConnection vo forme XML dokumentu. XML dokument je zašifrovaný pomocou RSA šifry s využitím verejného kľúča z klientskeho certifikátu.

XML dokument obsahuje parametre AES šifry a takisto verejný kľúč z certifikátu servera, na overenie digitálneho podpisu SOAP správy webovej služby.

Zašifrované XML je na strane klienta dešifrované pomocou súkromného kľúča z patričného klientskeho certifikátu.

Parametre AES šifry využíva objekt proxy na šifrovanie SOAP požiadaviek klienta.

Tab. 9.4 Autentifikačný lístok v SOAP hlavičke

<source lang="xml"> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Header> <TicketHeader xmlns="http://tempuri.org/"> <Ticket>f84bd797-8ea5-463c-9319-5d952ec30207</Ticket> </TicketHeader> </soap:Header> <soap:Body> </soap:Body> </soap:Envelope>

Obr. 9.1 Autentifikačný proces

Popis autentifikačného procesu na Obr. 9.1 :

1. Načítanie klientskeho certifikátu z úložiska.

2. Pridanie certifikátu k objektu proxy a zavolanie webovej metódy CreateConnection.

3. Autentifikácia klientskeho certifikátu, vydanie autentifikačného lístka, ak bol certifikát prijatý.

4. Pri následnom volaní webovej metódy sa autentifikácia klienta vykoná na základe autentifikačného lístka a komunikácia prebieha cez HTTP kanál.

Databázové úložisko

Ako sme v predchádzajúcej podkapitole spomenuli, informácie o autentifikovanom klientovi sú na strane webovej služby uchovávané v relačnej databáze, konkrétne MS SQL. Pre komunikáciu s databázovým úložiskom sme mohli použiť nasledujúce technológie:

1. LINQ to SQL [32],

2. ADO.NET [33].

LINQ to SQL poskytuje niektoré pokročilé možnosti v porovnaní s ADO.NET. Avšak samotná technológia ADO.NET poskytuje dostatočnú podporu pre rôzne DBMS [33] :

• MS SQL Server,
• MS SQL Mobile Server,
• Oracle,
• MySQL,
• ODBC,
• OLEDB.

V praktickej časti sme vytvorili triedu AbstractDatabase podľa návrhového vzoru Abstract Factory, ktorá umožňuje flexibilne vytvoriť triedu na prístup k databázovému úložisku podľa konkrétneho DBMS. Tým je zabezpečená možnosť upraviť databázové úložisko pre potreby praxe. Pri komplexnej podnikovej aplikácii by bolo najvýhodnejšie použiť ORM Framework napr. NHibernate. Dosiahli by sme separáciu objektového kódu od databázového kódu a znížili závislosť logickej vrstvy od bussines vrstvy. Použitie ORM Frameworku je nad rámec tejto práce, ale považovali sme za vhodné ho spomenúť.

Spracovanie SOAP správ

Jedným z prvkov na zabezpečenie integrity a dôvernosti komunikácie medzi klientskou aplikáciou a XML ASP.NET webovou službou je mechanizmus šifrovania a digitálneho podpisovania SOAP správ. Predtým, než si opíšeme spôsob, akým sú šifrované a podpisované SOAP správy, sa musíme oboznámiť so spôsobom, akým sú spracovávané SOAP správy na strane webovej služby aj na strane klientskej aplikácie.

Spracovávanie SOAP správ na strane webovej služby, ale aj na strane klienta prebieha v 2 etapách [3]:

1. Serializácia. Požiadavka klienta alebo odpoveď webovej služby je serializovaná ako XML schéma.

2. Deserializácia. SOAP správa je deserializovaná na dátové typy.

Aby sme mohli pristupovať k jednotlivým etapám spracovania SOAP správ, musíme implementovať mechanizmus SOAP rozšírenia na strane webovej služby, ale aj na strane klientskej aplikácie. Prístup k etapám serializácie a deserializácie je nutná podmienka na šifrovanie a digitálne podpisovanie SOAP správ

Rozšírenie SOAP

Rozšírenie SOAP predstavuje mechanizmus akým môžeme manipulovať so SOAP správami na strane klienta aj na strane webovej služby. Tento spôsob je veľmi flexibilný, o čom sa presvedčíme neskôr. Pokiaľ vytvoríme SOP rozšírenie, spracovanie SOAP správ prechádza 4 etapami [3]:

• BeforeDeserialize. Táto sa spúšťa v okamihu, keď webový server, poprípade objekt proxy dostanú SOAP správu.
• AfterDeserialize. V tejto etape je nespracovaná (raw) SOAP správa prevedená na dátové typy platformy .NET Framework. Vykonáva sa ešte pred spustením webovej metódy.
• BeforeSerialize. V tejto etape sa už spracováva kód webovej metódy, ale návratová hodnota webovej metódy nie je ešte serializovaná do SOAP správy.
• AfterSerialize. V tejto etape je návratová hodnota webovej metódy serializovaná do SOAP správy, ale tá ešte nie je odoslaná na klientsku aplikáciu.

V etapách BeforeDeserialize a AfterSerialize môžeme získať celý obsah SOAP správy. SOAP rozšírenie musí byť vykonávané aj na strane klienta, a to prostredníctvom objektu proxy. Celý proces spracovania SOAP správ je na Obr. 9.2.

Obr. 9.2 Serializácia a deserializácia SOAP správ

Vytvorenie SOAP rozšírenia

SOAP rozšírenie na platforme .NET Framework sa skladá z 2 častí [1]:

• Samotného SOAP rozšírenia, reprezentovaného vlastnou triedou, ktorá musí byť vytvorená odvodením z triedy System.Web.Protocols.SoapExtension.
• Vlastného atribútu, ktorý sa použije u webovej metódy na indikáciu, že na danú webovú metódu sa má aplikovať SOAP rozšírenie. SOAP atribút sa vytvára odvodením z triedy System.Web.Protocols.SoapExtensionAttribute.

Atribút pre SOAP rozšírenie - SecureExtensionAttribute

Atribút SOAP rozšírenia umožňuje spojiť konkrétne rozšírenie SOAP s metódami webovej triedy. Vytvára sa odvodením z triedy System.Web.Protocols.SoapExtensionAttribute. [1] Atribút pre SOAP rozšírenie je v našej webovej službe implementovaný prostredníctvom triedy SecureExtensionAttribute

Tab. 9.5 Atribút SoapExtension

[AttributeUsage(AttributeTargets.Method)] public class SecureExtensionAttribute : SoapExtensionAttribute {...}

Trieda pre SOAP rozšírenie obsahuje atribút AttributeUsage. Pomocou neho špecifikujeme oblasť použitia nášho atribútu. Náš atribút bude teda použitý na jednotlivé deklarácie webových metód.

V našej triede pre SOAP rozšírenie je nutné prekryť 2 abstraktné vlastnosti, ktoré trieda získala odvodením z triedy System.Web.Protocols.SoapExtensionAttribute. Ide o vlastnosti [3] :

• Priority. Slúži na nastavenie poradia, v akom sa spracujú SOAP rozšírenia, pokiaľ ich je na webovú metódu nakonfigurovaných viacero.
• ExtensionType. Vracia objekt Type, ktorý reprezentuje našu vlastnú triedu pre SOAP rozšírenia.

Trieda SecureExtensionAttribute pre atribút SOAP rozšírenia implementuje metódu SoapElement, pomocou ktorej budeme konfigurovať, ktoré časti SOAP správy budú šifrované. Konfigurácia sa vykonáva prostredníctvom Xpath výrazu.

Trieda SOAP rozšírenia - SecureExtension

SOAP rozšírenie je implementované v našej webovej službe prostredníctvom triedy SecureExtension. Každá trieda pre SOAP rozšírenie musí byť vytvorená odvodením z System.Web.Protocols.SoapExtension. [1]. V Tab. 9.6 sú povinné metódy, ktoré musíme prekryť pri vytváraní triedy pre SOAP rozšírenie.

Tab. 9.6' Trieda SOAP rozšírenia

public class SecureExtension : SoapExtension {...}

Tab. 9.7 Povinné metódy triedy SOAP rozšírenia

Metóda	Popis
GetInitializer()	Táto metóda predáva počiatočné informácie pre SOAP rozšírenie. Je spúšťaná pri prvom vykonaní SOAP rozšírenia. To umožňuje inicializovať hodnoty niektorých dát, ktoré sa použijú pri spracovaní SOAP správ. Takisto v tejto metóde môžeme extrahovať hodnoty atribútu pre SOAP rozšírenie. Táto metóda má dve verzie. Volá sa vždy len jedna, v závislosti od toho či je SOAP rozšírenie nakonfigurované prostredníctvom atribútu alebo konfiguračného súboru.
Initialize()	Metóda predáva počiatočné informácie pre SOAP rozšírenie. Je spúšťaná pri každom vykonaní SOAP rozšírenia.
ProcessMessage()	Táto metóda vykonáva vlastné spracovanie SOAP rozšírenia, umožňuje modifikovať SOAP správy. V tejto metóde sú volané metódy pre šifrovanie a digitálne podpisovanie SOAP správ.
ChainStream()	Metóda umožňuje získať prístup k SOAP bez prerušenia iných rozšírení.

Trieda SOAP rozšírenia SecureExtension implementuje v sebe dve pomocné metódy :

• RequestMessage. Jej úlohou je predať SOAP stream objektu typu SecureExtensionUtilities na dešifrovanie a overenie digitálneho podpisu SOAP požiadavky.
• ResponseMessage. Jej úlohou je predať SOAP stream objektu typu SecureExtensionUtilities na zašifrovanie a digitálne podpísanie SOAP odpovede .

SOAP rozšírenie je v podobnej forme, s malými zmenami, implementované aj na strane klienta, s malými zmenami .

Metóda ProcessMessage

Metóda ProcessMessage je volaná ASP.NET v týchto štyroch etapách [4]:

1. BeforeDeserialize,

2. AfterDeserialize,

3. BeforeSerialize,

4. AfterSerialize.

Etapa BeforeDeserialize je prvou etapou spracovanie SOAP požiadavky od klienta. V tejto etape sa na strane webovej služby vykonáva:

• Načítanie hodnoty autentifikačného lístka z hlavičky SOAP správy od klienta.
• Overenie platnosti autentifikačného lístka. Autentifikačný lístok sa vydáva klientovi s obmedzenou časovou platnosťou. V databáze na strane webovej služby je každá hodnota autentifikačného lístka spojená s časom, kedy bol lístok vydaný. Na základe hodnoty lístka sú načítané parametre AES šifry a verejný kľúč klienta.
• Po úspešnom overení lístka je SOAP stream predaný na dešifrovanie a overenie digitálneho podpisu prostredníctvom pomocnej metódy RequestMessage. Proces dešifrovania a overenia digitálneho podpisu je vykonávaný triedou SecureExtensionUtilities. Táto trieda bude popísaná v samostatnej podkapitole.

Spracovanie SOAP správy v etape BeforeDeserialize je znázornené na Obr. 9.3.

Obr. 9.3 Spracovanie SOAP správy v etape BeforeDeserialize

Etapa AfterSerialize je poslednou etapou spracovania SOAP odpovede zasielanej na klienta. V tejto etape sa na strane webovej služby vykonáva:

• Predanie SOAP streamu na digitálne podpísanie a zašifrovanie SOAP správy prostredníctvom pomocnej metódy ResponseMessage. Samotný proces šifrovania a digitálneho podpisovania je vykonávaný triedou SecureExtensionUtilities.

Hlavnou úlohou triedy SecureExtension je:

• Počiatočná autentifikácia klienta na základe hodnoty lístka v SOAP hlavičke.
• Načítanie AES parametrov a verejného kľúča z databázy.
• Predanie SOAP streamov na spracovanie triede SecureExtensionUtilities

Obr. 9.4 Životný cyklus triedy SecureExtension

Šifrovanie a dešifrovanie

Úlohou šifrovania je zabezpečiť dôvernosť a integritu komunikácie na komunikačnej ceste, ktorú tvorí viacero uzlov, čiže vykryť nedostatky technológie SSL. Šifrovanie SOAP správ predstavuje tzv. zabezpečenie na úrovni správ. V našej bezpečnostnej platforme je umožnené selektívne šifrovanie SOAP, ktoré sa dá podľa potreby nastavovať pomocou atribútov SOAP rozšírenia.

Šifrovanie a dešifrovanie SOAP správ je vykonávané v triede SecureExtensionUtilities. Skôr ako vysvetlíme, akým spôsobom je zabezpečená dôvernosť a integrita komunikácie, rozoberieme si nevýhody použitia samotnej technológie SSL.

Nevýhody technológie SSL

Veľmi rozšíreným spôsobom zabezpečenia komunikácie webových aplikácií je použitie technológie SSL, ktorú sme si popísali v podkapitole 4.1. Pre zabezpečenie webových služieb nie je táto technológia veľmi vhodná. Medzi obmedzenia SSL v spojitosti s XML webovými službami patrí:

• SSL predstavuje tzv. end - to - end zabezpečenie komunikácie. Pokrytý je len odosielateľ a príjemca správy. Pre XML webové služby je nutné zabezpečiť komunikáciu medzi každými dvoma uzlami komunikácie, ide o tzv. point – to – point zabezpečenia.
• SSL predstavuje zabezpečenie komunikácie iba na transporte. Pre webové služby je vhodnejšie zabezpečenie na úrovni správ. SSL je závislé na HTTP protokole.
• SSL šifruje celú komunikáciu, neumožňuje selektívne šifrovanie a takisto nepodporuje v plnej miere mechanizmus nepopierateľnosti. Pre webové služby, ktoré sú súčasťou SOA, je selektívne šifrovanie nutnou podmienkou.

Obr. 9.5 Point-to-point a end-to-end zabezpečenie

Advanced Encryption Standard

Pri počiatočnej výmene konfiguračného XML dokumentu je využitá asymetrická šifra RSA s využitím kľúčov z certifikátov webovej služby a klienta. Ďalšia komunikácia je šifrovaná pomocou symetrického šifrovacieho algoritmu. Ako šifrovací algoritmus sme zvolili symetrický blokový algoritmus Rijndael, ktorý bol v roku 1997 vyhlásený americkým úradom pre štandardizáciu (NIST) ako štandard. Dodnes nie sú známe dôkazy o jeho prelomení. [23]

AES predstavuje blokový šifrovací algoritmus so šírkou bloku 128 bitov a možnými dĺžkami kľúčov 128, 192 a 256. Rijndael podporuje aj voliteľné väčšie dátové bloky a kľúče v 32- bitových prírastkoch, ale tie nie sú zahrnuté v špecifikácii štandardu AES. [22]

Trieda SecureExtensionUtilities

Ako už bolo spomenuté, SOAP správy sú šifrované pomocou symetrickej šifry Rijndael, ktoré časti SOAP správy budú šifrované, je určené pomocou atribútov SOAP rozšírenia. Trieda SecureExtensionUtilities zabezpečuje šifrovanie, dešifrovanie, digitálne podpisovanie a verifikáciu digitálneho podpisu SOAP správ.

SecureExtensionUtilities implementuje v sebe dve hlavné verejné metódy:

• InSoap,
• OutSoap,

a tieto pomocné privátne metódy:

• DecryptString, metóda dešifruje textový reťazec z XML dokumentu.
• DecryptSoap, dešifruje XML dokument.
• VerifySignedSoap, overuje digitálny podpis SOAP správy.
• SingSoap, digitálne podpisuje SOAP správu na základe štandardu XML Signature.
• EncryptString, metóda šifruje textový reťazec z XML dokumentu.
• EncryptSoap, šifruje XML dokument.

Metóda InSoap spracováva stream SOAP požiadavky od klienta. Táto metóda je volaná v etape BeforeDeserialize metódy ProcessMessage. Ako vstupné parametre akceptuje:

• string[] soapElement určuje, ktoré elementy SOAP správy budú šifrované.
• Stream inputStream predstavuje raw SOAP správu.
• User user, trieda User predstavuje dátový objekt obsahujúci AES parametre a verejný kľúč klienta.

Ak nie je SOAP správa šifrovaná, metóda InSoap vráti ASP.NET vstupný SOAP prúd. Celý proces spracovania je znázornený na Obr. 9.3. Pokiaľ príde k zmene SOAP správy počas prenosu cez HTTP kanál, čiže overenie digitálneho podpisu SOAP správy indikuje sfalšovanie alebo podvrhnutie, klient je upozornený a nepríde k spracovaniu SOAP správy, či už na strane webovej služby, alebo na strane klientskej aplikácie.

Overovanie digitálneho podpisu na strane klienta je realizované obdobným spôsobom, rozdiel je v tom, že podpisovanie SOAP správ realizuje objekt proxy, v ktorom je implementované samotné SOAP rozšírenie. Na overovanie je použitý verejný kľúč zo serverového certifikátu webovej služby. Úlohou metódy InSoap je teda dešifrovať SOAP správu a overiť jej digitálny podpis.

Metóda OutSoap spracováva stream SOAP odpovede zasielaného na klienta. Táto metóda je volaná v etape AfterSerialize metódy ProcessMessage. Metóda OutSoap ako vstupné parametre akceptuje:

• string[] soapElement určuje, ktoré elementy SOAP správy budú šifrované.
• Stream inputStream predstavuje raw SOAP správu.
• User user, trieda User predstavuje dátový objekt obsahujúci AES parametre a verejný kľúč klienta.
• X509Certificate2 webServiceCert, objekt typu X509Certificate2 predstavuje serverový certifikát so súkromným kľúčom, ktorý sa použije na digitálne podpísanie SOAP správy.

Úlohou tejto metódy je digitálne podpísať a zašifrovať SOAP správu. Každá zašifrovaná SOAP správa od klienta má v SOAP hlavičke umiestnený dodatočný element IsEncrypted, ktorý slúži na identifikáciu, či je daná SOAP správa zašifrovaná. V Tab. 9.8 je ukážka zašifrovania SOAP správy

Tab. 9.8 Ukážka zašifrovanie SOAP správy

<?xml version="1.0" encoding="utf-8" ?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <soap:Header> <TicketHeader xmlns="http://tempuri.org/"> <Ticket>2541a182-8f4f-46c3-84f7-e667c221f494</Ticket> </TicketHeader> <IsEncrypted /> </soap:Header> <soap:Body> <SseReadPatient xmlns="http://tempuri.org/"> <id>Wk/C7PGSj/+fg2jQhQlUyg==</id> </SseReadPatient> </soap:Body> <</soap:Envelope>

Digitálne podpisovanie SOAP správ je realizované prostredníctvom štandardu XML Signature, ktorý sme si popísali v podkapitole 8.1. SOAP správy sú podpisované na strane servera prostredníctvom súkromného kľúča zo serverového certifikátu. Na strane klienta je digitálne podpisovanie realizované prostredníctvom súkromného kľúča z klientskeho certifikátu. V Tab. 9.9 je ukážka podpísanej SOAP správy.

Digitálne podpisovanie na strane klienta je realizované obdobným spôsobom, rozdiel je v tom že podpisovanie SOAP správ realizuje objekt proxy, v ktorom je implementované samotné SOAP rozšírenie. Na podpísanie SOAP správy je použitý súkromný kľúč z klientskeho certifikátu.

Tab. 9.9 Podpísaná SOAP správa

<soap:Envelope:xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <soap:Body> </soap:Body> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" /> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> <Reference URI=""> <Transforms> <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> <DigestValue>2yfAuq6taP4kPBsFEM+J79F7ysM=</DigestValue> </Reference> </SignedInfo> <SignatureValue>r2NmZyXtsku0WfbAJ4Kej/Kx0W0hAYCGAq7ltU7P5EN/NfQLYtZBCr97KHqNHkrEOqnU8Freg6 hEg1LXBhrkmF86bOApHTfOrdzpeK1WjK/tKO2G+xigjD8/PBhQszRK/qfG54gdY3kJ/y/kmn/S F+W49scLowecDxxeIx29UeI3m4yF8GoDGL3xjB/sEN78u8owdaBVcwkH2jIHWz6CiwPHk7YNLF c/Q0/XqE/ieBnAB2i0gLbM377AdHr9qLwMHVG/M9RVyl0JkWnUI8Viwm3Y268xz7cNlTnfa3uT hOGHMgmVDrBboHL44zZIBAZbsNsbqSPEipTMDVc7efC0Vg== </SignatureValue> </Signature> </soap:Envelope>

Pri digitálnom podpisovaní sme použili kanonizačný algoritmus na element <SignedInfo>. Použitie je indikované prostredníctvom elementu CanonicalizationMethodAlgorithm. Je to z toho dôvodu, aby sme zabránili rozdielnym výsledkom pri overovaní digitálneho podpisu. Nakoľko textová reprezentácia XML môže byť spracovaná rozdielne v závislosti použitého dátového prúdu (prázdne tagy, white space, komentáre...), kanonizácia definuje presnú fyzickú štruktúru dokumentu.

Tab. 9.10 Zoznam algoritmom použitých pri digitálnom podpisovaní SOAP

Algoritmus	Popis
SHA1	Hašovací algoritmus použitý pri výpočte hašu.
RSA	Kryptografický algoritmus použitý na vytvorenie digitálneho podpisu.
REC	Kanonizačný algoritmus.

V tejto podkapitole sme si popísali štruktúru triedy SecureExtensionUtilities, vysvetlili sme si akým spôsobom je spracovaný SOAP stream z triedy SOAP rozšírenia, a taktiež digitálne podpisovanie, verifikáciu, šifrovanie a dešifrovanie SOAP správ.

Autorizácia v SOAP Security Enhancement

Selektívne šifrovanie a digitálne podpisovanie má ochrániť samotnú komunikáciu medzi webovou službou a jej klientom. Úlohou autorizácie je rozhodnúť, aké operácie bude môcť autentifikovaný užívateľ vykonávať a k akým zdrojom bude mať prístup na strane webovej služby. Pri vytváraní autorizačných pravidiel sme mali tieto možnosti:

• Vytvoriť autorizačné pravidlá v konfiguračnom súbore webovej služby. Týmto spôsobom sme sa zaoberali v podkapitole 6.1.
• Namapovať klientske certifikáty na užívateľské účty systému Windows prostredníctvom IIS.
• Použiť niektorý zo spôsobov impersonácie, ktorými sme sa zaoberali v podkapitole 5.2.1.

Použitie autorizačných pravidiel v súbore web.config je relatívne flexibilný spôsob autorizácie, ale neposkytuje také pokročilé možnosti ako impersonácia. Rozhodli sme sa použiť programovú impersonáciu, a to z nasledujúcich dôvodov :

• Umožňuje mapovanie klientskych certifikátov na užívateľské účty systému dvoma rôznymi spôsobmi :
• One – to – one,
• Many – to – one.
• Programová impersonácia nám umožní flexibilne nastaviť, ktorá časť programového kódu bude vykonávaná pod účtom Network Service a ktorá pod nami zvoleným užívateľským účtom. Tento spôsob sa prostredníctvom mapovania klientskych certifikátov na IIS nedá docieliť.

Proces programovej impersonácie je nasledovný :

• V databáze je priradený ku každému klientskemu certifikátu jeden užívateľský účet systému Windows.
• Pri úspešnej počiatočnej autentifikácii klienta prostredníctvom certifikátu, sa jeho autentifikačný lístok namapuje na užívateľský účet.

Programová impersonácia je vykonávaná triedou UserImpersonation, ktorá obsahuje tieto metódy :

• Login - získa príznak účtu užívateľa Windows.
• Impersonate - spustí proces vykonávania programového kódu v kontexte identity užívateľského účtu. Pokiaľ klientov autentifikačný lístok nie je namapovaný na užívateľský účet, programový kód bude vykonávaný pod účtom Network Service, ktorý predstavuje prednastavený účet pre spracovanie ASPNET na systéme Windows Server 2003.
• UndoImpersonate - ukončí impersonáciu programového kódu.

Prostredníctvom užívateľských účtov Windows môžeme jednotlivým klientom webovej služby vyčleniť prístup k súborom na disku, k databáze a pod. Použitie triedy UserImpersonate je znázornené v Tab. 9.11.

Tab. 9.11 Použitie triedy UserImpersonate

UserImpersonation _objImp = new UserImpersonation(); _objImp.ReadUserAccount(Ticket.Ticket); _objImp.Login(); _objImp.Impersonate(); //programový kód, ktorý ma byť vykonáný pod inou identitou _objImp.UndoImpesonate();

Výhody SOAP Security Enhancement pre ASP.NET webové služby

V minulosti sa na zabezpečenie ASP.NET webových služieb využívalo rozšírenie Web Services Enhancements (WSE) [25], [26], [27]. Súčasná verzia 3.0 nepodporuje ASP.NET webové služby. Preto je veľmi ťažké porovnať navrhovanú vlastnú bezpečnostnú platformu s nejakým oficiálnym spôsobom zabezpečenia. Jediným možným riešením bolo porovnať spôsob zabezpečenia s rozšírením WSE 2.0. Tento produkt mal veľmi veľa problémov v oblasti interoperability a takisto je zastaralý. Preto sme sa vyhli porovnaniu našej bezpečnostnej platformy s týmto rozšírením.

Naša bezpečnostná platforma poskytuje zabezpečenie na úrovni aplikácie a taktiež na úrovni správ. Poskytuje dva spôsoby autentifikácie :

• Počiatočnú autentifikáciu založenú na certifikátoch X509. Výhodou tohto spôsobu autentifikácie je dobrá kontrola nad užívateľskými identitami.
• Autentifikáciu založenú na autentifikačných lístkoch v SOAP hlavičke. Výhodou tohto spôsobu autentifikácie je :
• Výhoda vytvorenia SOAP hlavičky je tá, že objekt proxy ju na strane klienta automaticky udržuje. Pokiaľ klient používa rovnakú inštanciu triedy proxy, bude automaticky a pri ďalšom odosielaní SOAP správ na webovú službu posielaný aj autentifikačný lístok v SOAP hlavičke.
• Pri opätovnom volaní webových metód nemusí byť posielaný s požiadavkou aplikácie aj klientsky certifikát. Vďaka tomu nemusí byť opätovne použité aj HTTPS spojenie.
• Autentifikačný lístok môže byť aplikácii vydaný s určitou časovou platnosťou, čo zvyšuje flexibilitu systému.

Integrita komunikácie je zabezpečená prostredníctvom digitálneho podpisovania na základe štandardu XML Signature. SOAP správy sú podpisované na základe privátnych kľúčov z certifikátov a overované na základe verejných kľúčov z certifikátov. Pokiaľ príde k zmene SOAP správy počas transferu cez HTTP kanál, čiže overenie digitálneho podpisu SOAP správy indikuje sfalšovanie alebo podvrhnutie, klient je upozornený a nepríde k spracovaniu SOAP správy, či už na strane webovej služby, alebo na strane klientskej aplikácie

Dôvernosť komunikácie je založená na šifrovaní SOAP správ pomocou symetrického blokového algoritmu Rijndael. Výhody:

• SOAP správy sú selektívne šifrované, chránené sú len potrebné dáta. Selektívne šifrovanie je nevyhnutná podmienka začlenenia XML webových služieb do SOA.
• Výhodou voči štandardu XML Encryption je ten, že pri našom šifrovaní nedochádza k „deformácii" XML tagov.
• Šifrovací algoritmus môže byť upravený podľa potreby praxe.
• Šifrovanie je realizované prostredníctvom SOAP rozšírenia. To znamená, že šifruje už serializované dáta. Vďaka tomu môžeme šifrovať a digitálne podpisovať aj vlastné dátové typy.
• Oproti technológii SSL predstavuje náš spôsob zabezpečenia point to point, čo je ďalšia podmienka začlenenia XML webových služieb do SOA.

Veľkú výhodu nášho zabezpečenia vidíme v spôsobe jeho samotného použitia. Celý mechanizmus ochrany SOAP správ sa aplikuje na webovú metódu prostredníctvom atribútu SOAP rozšírenia, ktorý predstavuje len dopísanie jedného riadku kódu nad webovú metódu. Náš spôsob zabezpečenia nemení spracovanie programového kódu webovej metódy.

V Tab. 9.12 je ukážka nastavenia šifrovania elementu body SOAP správy zasielanej ako odpoveď na klientsku aplikáciu. Elementy SOAP správy, ktoré majú byť zašifrované sa zadefinujú prostredníctvom Xpath výrazu pomocou vlastnosti SoapElement triedy atribútu SOAP rozšírenia.

Tab. 9.12 Použitie atribútu SOAP rozšírenia

[WebMethod] [SecureExtension(SoapElement = "//soap:Body/*/*")] public DataSet GetDataSet() { //kód webovej metódy }

Záver

V práci sme opísali technologické pozadie XML webových služieb a ich štandardy. Zamerali sme sa na ASP.NET webové služby. Vysvetlili sme si spôsoby, akým môžeme vytvoriť bezpečnostný komunikačný scenár medzi webovou službou a jej klientom. Rozobrali sme jednotlivé možnosti autentifikácie, autorizácie klientov webovej služby, spôsoby na zabezpečenie dôvernosti a integrity komunikácie. Uviedli sme ich výhody a nevýhody, ktoré so sebou prinášajú.

Upozornili sme na hlavné chyby, ktoré vznikajú pri zabezpečovaní XML webových služieb. Ide hlavne o použitie technológie SSL a štandardu XML Encryption. Samotná technológia SSL nie je postačujúca na zabezpečenie komunikácie medzi webovou službou a jej klientom, nakoľko predstavuje zabezpečenie na úrovni komunikačného kanála a predstavuje tzv. end – to – end zabezpečenie. To nie je veľmi vhodné pre XML webové služby, kedže v praxi bývajú súčasťou SOA. SOA architektúra vyžaduje selektívne šifrovanie, ktoré nie je možné dosiahnuť so štandardom XML Encryption. Pri použití tohto štandardu dochádza taktiež k deformácii XML tagov. Cieľom bezpečnostnej platformy bolo odstránenie týchto nedostatkov. Bezpečnostná platforma predstavuje zabezpečenie na úrovni aplikácie a tiež na úrovni správ. Počiatočná autentifikácia je realizovaná na základe certifikátov X509, pri volaní ďalších webových metód je klient autentifikovaný na základe autentifikačného lístka v SOAP hlavičke. Dĺžka platnosti autentifikačného lístka sa dá flexibilne meniť podľa potreby. SOAP správy sú selektívne šifrované pomocou AES, tým je dosiahnuté utajenie komunikácie. Integrita je zabezpečená prostredníctvom digitálneho podpisovania SOAP správ. Naša bezpečnostná platforma poskytuje autorizačný mechanizmus prostredníctvom programovej impersonácie.

Na otestovanie funkčnosti zabezpečenia komunikácie XML ASP.NET webovej služby bola vytvorená WinForms klientska aplikácia.

Použitá literatúra

1. MacDonald, Matthew., Beginning ASP.NET 3.5 in C# 2008: From Novice to Professional, Apress, 2007. ISBN 978-1590598917
2. Troelsen, Andrew., Pro C# 2008 and the .NET 3.5 Platform, Apress, 2007. ISBN 978-1590598849
3. Glynn, Jay., Skinner, Morgan., Professional C# 2008, Wrox, 2008. ISBN 978-0470191378
4. MacDonald, Matthew., Szpuszta, Mario., Pro ASP.NET 2.0 in C# 2005, Apress, 2005. ISBN 978-1590594964
5. Foggon, Damien., Maharry, Daniel., Ullman, Chris., Watson, Karli., Programming Microsoft .NET XML Web Services, Microsoft Press, 2003. ISBN 978-0735619128
6. Jones, Allen ., Microsoft .NET XML Web Services Step by Step, Microsoft Press, 2002. ISBN13: 978-0735617209
7. Eide, Andreas., Miller, Chris., Sempf, Bill Sempf., Professional ASP.NET Web Services, Wrox Press, 2001. ISBN 978-1861005458
8. Kurt, Chris., Web Services Architecture and Its Specifications: Essentials for Understanding WS, Microsoft Press, 2005. ISBN 978-0735621626
9. Krowczyk, Andrew., Greenvoss, Zach., Banerjee. Ashish., Professional C# Web Services: Building .NET Web Services with ASP.NET and .NET Remoting, Wrox Press, 2001. ISBN 978-1861004390
10. www.w3.org [online]. last updated: 2007-06-05 [cit. 2009-12-19]. Dostupná z WWW: < http://www.w3.org/TR/soap/>
11. www.w3.org [online]. last updated: 2001-03-14 [cit. 2009-12-19]. Dostupná z WWW: < http://www.w3.org/TR/wsdl/>
12. www.oasis-open.org [online]. last updated: 2009-12-19 [cit. 2009-12-19]. Dostupná z WWW: < http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htm>
13. O'Neill, Mark., Web Services Security, McGraw-Hill Osborne Media, 2003. ISBN 978-0072224719
14. Hartman, Bret., Flinn, Donald., Beznosov, Konstantin. Mastering Web Services Security, 2003. ISBN 978-0471267164
15. Nantz, Brian., Expert Web Services Security in the .NET Platform, Apress, 2004. ISBN 978-1590591154
16. Microsoft, Vytváříme zabezpečené aplikace v Microsoft ASP.NET, Computer Press, 2004. ISBN 80-251-0466-4
17. www.w3.org [online]. last updated: 2008-06-10 [cit. 2009-12-19]. Dostupná z WWW: < http://www.w3.org/TR/xmldsig-core/ >
18. www.w3.org [online]. last updated: 2002-12-13 [cit. 2009-12-19]. Dostupná z WWW: < http://www.w3.org/TR/xmlenc-core/ >
19. www.w3.org [online]. last updated: 2004-03-26 [cit. 2009-12-19]. Dostupná z WWW: < http://www.w3.org/MarkUp/SGML/>
20. www.oasis-open.org [online]. last updated: 2009-12-19 [cit. 2009-12-19]. Dostupná z WWW: < http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml>
21. www.w3.org [online]. last updated: 2005-12-20 [cit. 2009-12-19]. Dostupná z WWW: < http://www.w3.org/TR/XMKS/ >
22. Rijmen, Vincent., The Design of Rijndael: AES - The Advanced Encryption Standard, Springer, 2002. ISBN 978-3540425809
23. Tom, Denis., Cryptography for Developers, Syngress, 2007. ISBN 978-1597491044
24. www.msdn.microsoft.com [online]. last updated : 2009-12-22 [cit. 2009-12-22]. Dostupná z WWW: http://msdn.microsoft.com/en-us/library/system.security.cryptography.passwordderivebytes.aspx
25. Microsoft Corporation, Web Service Security: Scenarios, Patterns, and Implementation Guidance for Web Services Enhancements (WSE) 3.0, Microsoft Press, 2006. ISBN 978-0735623149
26. Hasan, Jeffrey., Expert Service-Oriented Architecture in C#: Using the Web Services Enhancements 2.0, Apress, 2004. ISBN 978-1590593905
27. Evjen, Bill., Web Services Enhancements: Understanding the WSE for .NET Enterprise Applications, Wiley, 2003. ISBN 978-0764537363
28. www.msdn.microsoft.com [online]. last updated : 2009-12-22 [cit. 2009-12-22]. Dostupná z WWW: http://msdn.microsoft.com/en-us/library/system.security.cryptography.passwordderivebytes.aspx
29. www.msdn.microsoft.com [online]. last updated : 2010-01-07 [cit. 2010-01-07]. Dostupná z WWW: http://msdn.microsoft.com/en-us/library/72wdk8cc(VS.71).aspx
30. http://www.oasis-open.org [online]. last updated : 2010-01-07 [cit. 2010-01-07]. Dostupná z WWW: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml
31. www.msdn.microsoft.com [online]. last updated : 2010-01-07 [cit. 2010-01-07]. Dostupná z WWW: http://msdn.microsoft.com/en-us/library/ms229335.aspx
32. www.msdn.microsoft.com [online]. last updated : 2010-01-07 [cit. 2010-01-07]. Dostupná z WWW: http://msdn.microsoft.com/en-us/netframework/aa904594.aspx
33. www.msdn.microsoft.com [online]. last updated : 2010-01-07 [cit. 2010-01-07]. Dostupná z WWW: http://msdn.microsoft.com/en-us/library/e80y5yhx%28VS.80%29.aspx
34. www.msdn.microsoft.com [online]. last updated : 2010-01-07 [cit. 2010-01-07]. Dostupná z WWW: http://msdn.microsoft.com/en-us/library/dd0w4a2z%28VS.80%29.aspx
35. Dostálek, Libor., Vohnoutová, Marta., Velký průvodce infrastrukturou PKI a technologií elektronického podpisu, 2006. ISBN 80-251-0828-7
36. www.msdn.microsoft.com [online]. last updated : 2010-01-07 [cit. 2010-01-07]. Dostupná z WWW: http://msdn.microsoft.com/en-us/library/cc488021.aspx