XIII. Bezpieczeństwo Web Services (WS-* Specifications)

1. Simple Object Access Protocol

SOAP to stosunkowo prosty i niespecjalnie kosztowny w implementacji mechanizm wymiany zestrukturalizowanej (w sposób prosty) oraz typowanej informacji. Niskie koszty implementacji SOAP – ze względu na XML, którego implementacja jest dość powszechnie dostępna (głównie dotyczy czasów, gdy SOAP definiowano).

SOAP node – dowolny agent odbierający lub/i wysyłający komunikaty SOAP. Pierwotny nadawca (original sender) – węzeł, który zainicjował transmisję komunikatu. Ostateczny/końcowy odbiorca (ang. ultimate receiver) – węzeł znajdujący się na przeciwległym końcu połączenia w stosunku do original sender. Każdy wezeł przetwarzający komunikat, a znajdujący się pomiędzy original sender a ultimate receiver nosi miano pośrednika (intermediary). Wszystkie intermediaries przez które kolejno przechodzi komunikat oraz znajdujący się na końcu ultimate receiver tworza tzw. ścieżkę komunikatu (ang. message path).

Elementy komunikatu SOAP to: <Envelope>, <Header> oraz <Body>.

<Envelope> - caly dokument zawierający opcjonalnie nagłówek oraz obowiązkowo ciało.

<Header> - generyczny element umożliwiający dodawanie kolejnej funkcjonalności w sposób zdecentralizowany. Każdy podelement nagłówka jest określany mianem bloku nagłówka (header block). Specyfikacja SOAP nie definiuje żadnego nagłówka. Odbiorcą <Header> może być zarówno ostateczny odbiorca, jak i węzeł pośredniczący (intermediary).

<Body> jest właściwą zawartością (payload) komunikatu adresowaną do końcowego odbiorcy (ultimate receiver). Specyfikacja SOAP definiuje jeden rodzaj <Body>, czy tzw. Fault służący do raportowania o błędach.

Specyfikacja SOAP określa kilka atrybutów nagłówka, które ustalają: Każdy węzeł bierze pod uwagę te atrybuty w trakcie przetwarzania nagłówka:
  1. Identyfikuje wszystkie bloki adresowane do niego (na podstawie role) – jeśli role nie ma z założenia fragment nagłówka jest adresowany do ultimate receiver.
  2. Weryfikuje czy potrafi przetwarzac wszystkie zidentyfikowane bloki (rozpatrywanie mustUnderstand) – jeśli okaże się, że któryś z bloków nie jest zrozumiały dla bieżącego węzła komunikat jest usuwany i generowany jest błąd – do nadawcy.
  3. Właściwe przetwarzanie komunikatu – opcjonalne bloki mogą być pominięte.
  4. Jeśli bieżący węzeł jest pośrednikiem wszystkie bloki zidentyfikowane w kroku 1, które nie powinny być przekazane dalej (not relayable) sa usuwane z komunikatu. Wiadomość jest przekazywana dalej do następnego węzła w ścieżce. Pośrednik może wstawić nowe bloki do nagłówka, które mogą być również kopiami bloków zidentyfikowanych w kroku 1 (np. w momencie użycia roli Next)

2. Ogólne założenia WS-* Specifications rozszerzających protokół SOAP

Główni dostawcy oprogramowania tacy jak Microsoft, czy IBM przewidują, że w przyszłości aplikacje będą oparte o autonomiczne Web Services. Stąd też w ogólności wzięła się koncepcja środowiska Microsoft .NET. Twórcy .NET Platform od samego początku zakładali pracę rozwijanej platformy w środowisku rozproszonym, a podstawowym medium komunikacji miały być w tamtym czasie raczkujące Web Services.

Zasadnicze założenia stanowiące podwaliny zaawansowanych specyfikacji WS (WS-* Specifications):

2.1 Zorientowanie na komunikaty

Jedynym sposobem komunikacji między usługami są komunikaty. Komunikat stanowi podstawową jednostkę komunikacji. WebServices zakładają, że protokołem najniższej warstwy jest SOAP – izolacja szczegółów związanych z transportem, ktore tym samym nie wpływają na właściwą aplikację. Jest to zasadniczy element decydujący o interoperacyjności. Pojedynczy komunikat moze byc przetwarzany przez wiele wezłów, które mogą wykonywać różne operacje na tym komunikacie. Weryfikować jego zawartość, wyznaczać ścieżkę w oparciu o jego zawartość, lub wykonywać walidację. Pojedynczy komunikat może być przekazywany przez wiele różnych mediów transportowych zanim osiągnie końcowego odbiorcę (ultimate receiver). Z tego względu w pierwszym okresie pracy nad WS-Specification bardzo dużo czasu poświęcono zapewnieniu bezpiecznego i wiarygodnego transportu.

2.2 Dowolne łączenie protokołów

O protokołach można mówić, że mogą być dowolnie łączone, jeśli mogą być wykorzystywane niezależnie od siebie lub w dowolnej konfiguracji. Historia informatyki zna wiele protokołów domain-specific, których twórcy zgromadzili w jednej specyfikacji elementy dotyczące: (1) bezpieczeństwa, (2) niezawodności, czy (3) raportowania o błędach. Tego rodzaju podejście nie może mieć zastosowania w przypadku WS ze względu na różnorodne zastosowania tej technologii. Tworzenie protokolu dla wszystkim mozliwych zastosowań szybko doprowadziloby do tego, ze specyfikacja stałaby sie niezarządzalna i zawsze nieaktualna. Protokoły wchodzące w skład WS-* Specifications stanowią rodzinę komponowalnych cegiełek (ang. building blocks). Każda cegiełka definiuje ściśle określony zakres funkcjonalności. Przykładowo, wszystko co jest związane z podpisywaniem (ang. signing) i opieczętowywaniem (ang. sealing) wiadomości zostało umieszczone w jednym miejscu - specyfikacji WS-Security, z kolei wszystko co dotyczy niezawodnego transportu w specyfikacji WS-ReliableMessaging. Komponowalność WS-Specifications została oparta o elastyczne nagłówki SOAP. Tak naprawdę to sama aplikacja decyduje, czy będzie korzystać z nagłówków danego protokołu, czy też nie – o ile oczywiście korzystanie nie jest wymagane dla właściwej interpretacji komunikatu. Poszczególne protokoły mogą być dodawane uzupełniając funkcjonalność dotychczas stosowanych. WS-* Specifications dostarczają profili, które informują o ograniczeniach oraz najlepszych praktykach łączenia poszczególnych protokołów.

2.3 Autonomiczność usług

Usługi są całkowicie niezależne w zakresie technologii implementacji, sposobu wdrożenia, itp. od korzystających z nich aplikacji klienckich. Jednak ta autonomiczność musi być ograniczona pewnymi ramami – jak np. wersjonowanie usług – w miarę ewolucji usługi zmienia się również grono jej klientów. Ewolucja usługi musi być odpowiednio zakomunikowana klientomi i jest odzwierciedlana w samych komunikatach SOAP – poprzez manipulację nagłówków. Część nagłówków może być bezpiecznie zignorowana przez klientów – wówczas komunikacja będzie uboższa o pewną funkcjonalność. Część nagłówków optarzona mustUnderstand oznacza, ze wyłącznie klienci potrafiący przetwarzać dany nagłówek będą w stanie poprawnie zinterpretować komunikat. Podstawową cechą SOAP jest jego dowolna rozszerzalność – nie ma potrzeby wprowadzania nowej wersji SOAP w celu dodania nowej funkcjonalności. Autonomiczność uczestników konwersacji za pośrednictwem WS wymaga zarządzania wzajemnym zaufaniem. To oczywiscie oznacza walidację komunikatów otrzymywanych na wejściu ale również wzajemne uwierzytelnianie i autoryzacja usług (przyznawanie uprawnien w oparciu o security tokens umieszczne w nagłówkach) Kolejną implikacją autonomiczności jest pelne sprawowanie kontroli nad własnymi zasobami. Istotną kwestią jest tutaj np. odzyskiwanie zasobów – wykorzystano w tym miejscu mechanizm dzierżaw. Sprawowanie kontroli nad własnymi zasobami to również harmonogramowanie wykorzystania tych zasobów. Autonomiczność to również uodpornienie konwersjacji na skutki dowolnej dostępności jej uczestników.

2.4 Zarządzana przezroczystość

Wszystkie szczegóły implementacyjne pozostają prywatne dla serwisu – platformą integracji jest wyłącznie protokół komunikacji. Usługi udostępniają na zewnątrz wyłącznie kontrakt – odczytywalny dla klienta opis interfejsu. Dzięki takiemu opisowi np. środowiska rozwoju oprogramowania umożliwiają utworzenie wiązań do konkretnych usług w terminach danej technologii implementacji. Zarządzana przezroczystość to również różny stopień widoczności różnych fragmentów komunikatów. Nadawca może podjąć decyzję, by część wiadomości była czytelna dla wszystkich, którzy będą mieli okazję odczytać komunikat, inna część zaś będzie zrozumiała jedynie dla ściśle określonego grona odbiorców. W ogólności każda część komunikatu może być czytelna dla dowolnego grona odbiorców.

2.5 Integracja na poziomie protokołu

Popularność koncepcji integracji w oparciu o protokół komunikacyjny doprowadziła do opracowania pojęcia zorientowania na usługi (service orientation), oraz SOA (Service-Oriented Architecture). Dzięki podejściu SOA czerpiącemu konkretne rozwiązania z różnych źródeł: (1) interfejsy oraz polimorfizm (dla różnych klientów) z metodyki obiektowej, (2) kolejkowanie komunikatów z message-oriented middleware, (3) rozproszonego przetwarzania – komunikaty przesyłane między węzłami – każdy węzeł przez który komunikat zostanie przesłany może go jakoś zmanipulować. Koncepcja SOA jest atrakcyjna ze względu na możliwość integracji różnych systemów spadkowych.

2.6 Obszary odpowiedzialności ważniejszych specyfikacji

WS-* Specifications, w których opracowaniu wspólnie uczestniczą m.in. Microsoft i IBM (w ramach WS-I) stanowią platformę umożliwiającą rozszerzenie funkcjonalności WS, bez obniżenia interoperacyjności. Uczestnictwo w procesie standaryzacyjnym przedstawicieli przemysłu gwarantuje interoperacyjność między produktami tych dostawców. Twórcy konkretnych rozwiązań będą musieli jedynie dostosować się do uzgodnień zawartych w konkretnych specyfikacjach WS.

WS-Security – specyfikacja wykorzystująca rekomendacje XML Encryption oraz XML Signature do rozszerzenia funkcjonalności WS o elementy bezpieczeństwa. Protokół początkowo był opracowywany przez Microsoft, IBM, oraz VeriSign – obecnie nad standardem pracuje jeden z komitetów Oasis-Open. WS-Security skupia się na wzbogaceniu komunikacji SOAP o zapewnienie integralności, poufności oraz dołączaniu żetonów bezpieczeństwa do komunikatów. WS-Security umożliwia na korzystanie z Kerberos oraz oczywiście kryptorgrafii publicznej opartej o standard X.509.

WS-SecureConversation – stanowi rozszerzenie WS-Security umożliwiające bezpieczną komunikację między uczestnikami konwersacji WS. Definiuje mechanizmy inicjalizacji oraz współdzielenia kontekstu bezpieczeństwa oraz ustalania współdzielonych kluczy sesyjnych.

WS-Trust – kolejne rozszerzenie WS-Security. Wprowadza mechanizmy umożliwiające żądanie żetonów bezpieczeństwa od uczestników konwersacji umożliwiając tym samym ustalenie relacji zaufania.

WS-Policy – określa mechanizm umożliwiający obydwu stronom konwersacji (usłudze oraz konsumentowi usługi) publikację oraz wymuszanie swoich wymagań, które muszą być spełnione, aby komunikat SOAP mógł być właściwie zinterpretowany. Polityki mogą dotyczyć bezpieczeństwa, jakości usług (QoS).

WS-Addressing – specyfikuje sposób powiązania adresów punktów końcowych (endpoint reference ERP) konwersacji z różnymi funkcjami:

  1. URI przeznaczenie komunikatu – ultimate receiver;
  2. Source endpoint – usługa, która zainicjowała komunikat (sprawdzić, czy nie zmianę w nagłówku);
  3. Reply endpoint – usługa do której powinny byc kierowane odpowiedzi na dany komunikat, itp.

WS-ReliableMessaging – specyfikacja poświęcona niezawodnemu dostarczaniu komunikatów.

WS-Attachments – specyfikacja poświęcona umieszczaniu plików, bądź dokumentów XML (w tym komunikatów SOAP) wewnątrz komunikatów.

3. WS-Policy

Interakcja pomiędzy WS a klientem odbywa się w oparciu o komunikaty SOAP. Zarówno dla wygody tworzenia oprogramowania, jak i odporności całego środowiska rozproszonego wymagane jest, by usługi webowe (a dokładnie kontrakt z klientem usługi) były opisywane za pomocą języka automatycznie interpretowalnych (machine-readable) metadanych. Kontrakt stanowi o izolacji usługi od właściwej implementacji. Metadane opisują interfejs (czyli format komunikatów) wspierany przez WS. WS Specifications uznają, że częścią metadanych mogą być również dodatkowe informacje prezentowane przez WS, które bezpośrednio nie dotyczą funkcjonalności, a wymagań WS w stosunku do klienta – jest to tzw. polityka usługi. Format komunikatów (interfejs dostępu do funkcjonalności usługi) jest opisywany w WSDL. Polityka jest opisywana przez WS-Policy – jedną ze specyfikacji rozszerzających WS.

Zgodnie z WSDL komunikaty SOAP są grupowane w operacje (zasadniczo request/response – chyba, że mamy do czynienia z sekwencjami WS-ReliableMessaging). Operacje opisują podstawowe wzorce wymiany komunikatów (request/response). Z kolei operacje są grupowane w interfejsy – czyli zgodnie ze specyfikacją WSDL tzw. porty. Na końcu porty są wiązane z konkretnym transportem HTTP, TCP, czy SMTP. WSDL stanowi podstawę dla określenia interfejsu usługi, z której korzystają narzędzia programistyczne. Niestety opis WSDL nie jest wystarczający by ująć wszystkie możliwe cechy usługi – przykładowo informację o dostępności usługi (w określonych godzinach, czy dniach), informacje dotyczące uprawnień do korzystania z usługi (kto jest uprawniony, a kto nie jest uprawniony), zabezpieczenie komunikacji, itp. Tego rodzaju informacje musiały być do tej pory przekazywane w sposób niezależny od samych metadanych WS i tym właśnie aspektom jest poświęcona specyfikacja WS-Policy.

WS-Policy udostępnia ogólny model oraz składnię umożliwiający komunikowanie polityki przez usługi webowe. WS-Policy wprowadza pewien zestaw konstrukcji, które mogą być rozszerzane przez specyfikacje opisujące konkretne rodzaje polityki. W ten sposób WS-Policy w żaden sposób nie ogranicza twórców przyszłych specyfikacji. Podstawą opisu każdej polityki jest tzw. asercja polityki (ang. policy assertion). Asercja umożliwia odpowiednie rozszerzenie metadanych w trakcie rozwoju usługi, jak również podczas, lub po wdrożeniu. Najprostszymi przykładami ograniczeń narzucanych przez asercje mogą być:

Poszczególne asercje mogą być grupowane w alternatywy, które stanowią cegiełki, z których budowana jest polityka. Dana alternatywa jest wspierana przez klienta o ile spełnia on wszystkie wymagania przedstawione w alternatywie. Wsparcie alternatywy oznacza, że podmiot żądający (ang. requestor) spełnia wszystkie asercje wymienione w ramach tej alternatywy – co jest ustalane automatycznie poprzez ustalanie wyników poszczególnych asercji składających się na alternatywę. Cała polityka jest wspierana przez klienta o ile spełnia on warunki wymienione w przynajmniej jednej alternatywie tej polityki. Choć z reguły przyjmuje się zasadę, że poszczególne alternatywy powinny się wzajemnie wykluczać.

Wyrażenie polityki (ang. policy expression) sposobem na opis niestandardowych wymagań – dwa operatory All, oraz ExactlyOne oznaczające, że albo wszystkie asercje składające się na alternatywy wchodzące do danej polityki muszą być spełnione, lub też wystarczy, aby jedna asercja spośród tworzących alternatywy pownna być spełniona aby cała była spełniona. Polityki uzupełniają opis WSDL i mogą być dołączane do WSDL lub wpisów (entities) UDDI w sposób zgodny ze specyfikacją WS-PolicyAttachment. Kilka połączonych polityk tworzy razem efektywną politykę – czyli sumę wszystkich ograniczeń wymienionych w poszczególnych politykach.

4. WS-Security

Protokół SSL/TLS zapewnia nam: Ale niestety SSL/TLS zakłada model sesji point-to-point – a w ogólności pewnie chcielibyśmy mieć możliwość przekazywania komunikatu przez wiele węzłów pośredniczących (intermediaries) – przykładowo jeśli właściwy serwis znajduje się za jedną lub wiecej ścianami ogniową. Zależałoby nam na raczej na możliwości zestawiania połączeń end-to-end, gdzie węzły pośredniczące mogą – zgodnie z ogólnymi założeniami specyfikacji WS – wprowadzać modyfikacje do nagłówka komunikatu.

WS-Security – specyfikacja odnosząca się do wspomnianych problemów wykorzystująca dostępne już standardy i specyfikacje (nie wymyśla od nowa koła). W zakresie szyfrowania fragmentów dokumentów XML WS-Security opiera się na XML Encryption oraz XML Signature. W zakresie uwierzytelnienia na infrastrukturze klucza publicznego opartej o standard X.509 oraz protokół Kerberos – oczywiście tam gdzie to ma zastosowanie.

WS-Security definiuje bloki nagłówka, których zadaniem jest dostarczanie informacji związanej z bezpieczeństwem. W momencie gdy część komunikatu została podpisana nagłówek WS-Security będzie zawierał informację nt. metody podpisu, wykorzystywanego klucza, czy też właściwego podpisu. Identyfikacja odpowiedniego bloku jest realizowana za pomocą atrybutu wsu:Id unikalnego w ramach komunikatu. Podobnie będzie w przypadku, gdy wybrany element komunikatu zostanie zaszyfrowany – blok WS-Security będzie zawierał odpowiednią informację zgodną ze specyfikacją WS-Encryption. WS-Security nie zajmuje się sposobem podpisywania, czy szyfrowania, a jedynie zawiera informacje umożliwiające właściwe korzystanie dostępnych metod w tym zakresie w momencie zabezpieczania komunikatów SOAP.

Poza pełnieniem roli magazynu metadanych dla użytych metod zabezpieczania – dzięki czemu odbiorca wie, z czego skorzystał odbiorca, WS-Security zawiera również tzw. profile opisujące sposoby załączania żetonów bezpieczeństwa w nagłówku. Jest to mechanizm transmisji credentials wewnątrz bloku nagłówka SOAP. WS-Security udostępnia 2 metody załączania żetonów:

Zasadniczo schemat dokumentu XML zamieszczony w specyfikacji WS-Security dopuszcza umieszczenie czegokolwiek umożliwiając tym samym do każdego potencjalnego mechanizmu zabezpieczeń – w tym zakresie WS-Security jest jak najbardziej zgodne z duchem WS i WS Specifications. Definicja schematu wynika z faktu, że blok WS-Security z założenia ma przenosić wszelką informację dot. bezpieczeństwa: Komunikat SOAP może zawierać wiele bloków dot. bezpieczeństwa, z których każdy może być opatrzony specjalnym atrybutem Actor. Atrybut Actor umożliwia pośrednikom zidentyfikować, które bloki powinni przetwarzać. Wartością atrybutu Actor jest URI pod którym działa dany pośrednik - URI jest zawsze unikalne. De facto ten sam pośrednik może być uruchomiony pod więcej niż jednym URI, co oczywiście oznacza, że może przetwarzać więcej niż jeden blok. Zakłada się, że każdy pośrednik wie pod którym URI został uruchomiony. Specyfikacja dopuszcza, by co najwyżej jeden blok WS-Security nie był opatrzony atrybutem Actor, co oznacza, że odbiorcą tego bloku jest ultimate receiver. WS-Security wprowadza też specjalny atrybut wsu:TimeStamp wprowadzający mechanizm wygaszania ważności komunikatu, co zabezpiecza usługę przed atakami typu replay – w momencie, kiedy intruz nie jest w stanie zmodyfikować komunikatu (komunikat podpisany). Co oczywiście nie zabezpiecza przed atakiem typu dDOS.

wsu:Created, wsu:Expires i wsu:Received – mogą występować niezależnie bądź jako elementy wsu:TimeStamp.

wsu:TimeStamp jeśli występuje to zawiera jeden z powyższych elementów.

wsu:Created może oznaczać również moment, w którym dany blok został dodany do nagłówka przez pośrednika.

4.1 Uwierzytelnienie

Zadadniczo WS-Security dopuszcza dowolny sposób uwierzytelnienia (patrz. schemat bloku WS-Security), jednak w samej specyfikacji zdefiniowano 3 tzw. profile odnoszące się do przenoszenia credentials w nagłówku SOAP: Uwierzytelnienie w oparciu o credentials składających się z pary: <nazwa użytkownika>/<hasło> jest najbardziej powszechne. Jest to metoda używana np. w opisanych w specyfikacji HTTP tzw. Basic oraz Digest Authentication. WS-Security obejmuje tzw. profil poświęcony specyfikacji schematu tzw. UsernameToken. UsernameToken zakłada istnienie dwóch elementów: nazwy użytkownika oraz hasła. Hasło może być przesyłane otwartym tekstem, ale może być również zaszyfrowane w oparciu o mechanizm wykorzystywany w HTTP Digest Authentication. Skrót (ang. digest) jest wyliczany w oparciu o nonce (16 bajtów) + czas utworzenia nagłówka + hasło dostarczone przez klienta. Serwer przesyła do klienta nonce w postaci zakodowanej w base64. Klient wyznacza skrót dla skonkatenowanych powyżej danych. Serwer wykonuje operację odwrotną, co niestety w przypadku Windows oznacza, że hasło po stronie usługi musi być zaszyfrowane w sposób odwracalny. Tutaj oczywiście pojawia się pewien problem ponieważ ten sposób uwierzytelnienia samodzielnie nie zabezpiecza nas ani przez replay attacks, ani przed zmanipulowaniem komunikatu SOAP przez intruza. Z tego względu to zabezpieczenie powinno być zawsze stosowane w połączeniu z podpisywaniem oraz stempli czasowych (ang. time stamps).

Całkowicie innym sposobem uwierzytelnienia jest umieszczenie w nagłówku SOAP certyfikatu X.509, który pełni oczywiście rolę żetonu identyfikującego klienta, lub osobę w imieniu której działa aplikacja kliencka. Certyfikat X.509 – podobnie jak omówione wyżej credentials może być zmapowany na konkretnego użytkownika aplikacji umożliwiając tym samym określenie jego uprawnień w ramach usługi. Certyfikat X.509 jest wówczas umieszczany jako zawartość elementu BinarySecurityToken – kodowany w base64. Oczywiście korzystanie z certyfikatu w roli żetonu (tak naprawdę to certyfikat jest po prostu żetonem) nie wystarcza i jest narażone na te same ataki co w przypadku uwierzytelnienia w oparciu o skrót. Dlatego jeśli już korzystamy z tak zaawansowanego zabezpieczenia jak kryptografia klucza publicznego powinniśmy również zadbać o podpisywanie komunikatów, tak aby nie były zmanipulowane. W mocy pozostaje również uwaga dot. znaczników czasowych.

Zgodnie ze specyfikacją WS-Security BinarySecurityToken może tak naprawdę przenosić w sobie 3 możliwe ładunki (ang. payloads):

Korzystanie z protokołu Kerberos wymaga od użytkownika podania jakiegoś rodzaju dowodu potwierdzającego tożsamość (credentials), np. pary <nazwa użytkownika>/<hasło>, bądź certyfikatu X.509. Jeśli uwierzytelnienie przebiegnie pomyślnie klient otrzyma tzw. Ticket Granting Ticket (TGT). Klient nie może odczytać TGT, ale może za to wykorzystać ten bilet do otrzymania Service Ticket od Ticket Granting Service. TGS jest usługą odpowiedzialną za przyznawanie biletów upoważniających do korzystania z konkretnych usług. 5. Po otrzymaniu ST, klient może korzystać z danej usługi dla której przyznano mu ST. Oczywistym powodem podpisywania komunikatów jest zabezpieczenie przed ew. manipulacją ze strony intruza.

Każda z wymienionych metod uwierzytelnienia wykorzystuje mechanizmy kryptograficzne umożliwiające podpisanie całego komunikatu, bądź wybranych fragmentów. W przypadku certyfikatu X.509 jest towarzyszący zawartemu w certyfikacie kluczowi publicznemu, klucz prywatny. W przypadku Kerberos jest to klucz sesyjny zawarty w biletach (TGT lub ST). W przypadku <nazwa użytkownika>/<hasło> jest to PBE (Password Based Encryption).

Oczywiście uwierzytelnienie i podpisy cyfrowe nie załatwiają zawsze sprawy, bowiem może istnieć konieczność przesłania danych poufnych – numery kart kredytowych, itp. Poufność danych można osiągnąć za pomocą szyfrowania – podobnie jak w przypadku podpisywania możemy chcieć zaszyfrować dowolnie wybrane fragmenty komunikatu. W ogólności WS-Security umożliwia nam zaszyfrowanie dowolnych części komunikatu dla różnych odbiorców – przy czym oczywiście adresatem <Body> jest zawsze końcowy odbiorca (ang. ultimate receiver). Specyfikacja XML Encryption opisuje sposób szyfrowania fragmentów dokumentów XML. Dane mogą być zabezpieczone przy pomocy dowolnych prymitywów: algorytmów symetrycznych, bądź szyfrów. Oczywiście korzystając z kryptografii tajnej musimy uwzględnić konieczność ustalenia wspólnego klucza tajnego.

5. WS-SecureConversation

Kryptografia klucza publicznego zapewnia bardzo wysoki poziom zabezpieczenia pod względem poufności, czy niezaprzeczalności jednak ma bardzo poważną wadę – jest naprawdę bardzo kosztowna pod względem przetwarzania. Dlatego w praktyce kryptografia klucza publicznego jest stosowana do szyfrowania bardzo niewielkich partii danych (do kilkudziesięciu bajtów). Pod względem wydajności szyfrowanie symetryczne o niebo przewyższa szyfrowanie asymetryczne. Z drugiej strony szyfrowanie symetryczne wymaga by po obydwu stronach znajdował się ten sam współdzielony klucz tajny.

Właśnie dlatego w praktyce najczęściej stosuje się rozwiązanie hybrydowe łączące zalety obydwu rodzajów szyfrowania. Tego rodzaju podejście do zabezpieczenia transmisji nie zostało ujęte w specyfikacji WS-Security – choć oczywiście generyczność WS-Security pozwala na tego rodzaju rozwiązania. Specyfikacja takiego rozwiązania została natomiast umieszczona w rozszerzeniu WS-Security - WS-SecureConversation.

Specyfikacja WS-SecureConversation została poświęcona zabezpieczeniu sesji składających się z więcej niż pojedynczego komunikatu. WS-SecureConversation definiuje kontekst bezpieczeństwa (ang. security context) ustalany pomiędzy obydwoma stronami konwersacji. Kontekst bezpieczeństwa jest oparty o współdzielone klucze tajne. Kontekst jest współdzielony przez strony konwersacji na czas trwania sesji. Na podstawie shared secrets generowane są sesyjne klucze tajne używane do zabezpieczania poszczególnych komunikatów.

WS-SecureConversation definiuje 3 możliwe sposoby ustalenia kontekstu bezpieczeństwa:

Czas życia kontekstu bezpieczeństwa nie musi koniecznie pokrywać się z czasem istnienia sesji – przykładowo kontekst może mieć ustalony czas ważności. Żeton kontekstu bezpieczeństwa zawiera współdzielony klucz tajny, który stanowi podstawę do generowania kluczy służących do podpisywania i szyfrowania komunikatów. W ogólności szyfrowanie każdego komunikatu (a w zasadzie bloku) odbywa się innym kluczem tajnym, który jest tworzony na podstawie klucza dotychczasowego oraz przetworzonych danych. W ogólności jednak ten rodzaj zabezpieczenia ma zastosowanie, gdy komunikacja między klientem a usługą nie sprowadza się do jednego komunikatu – w przeciwnym razie należy się zastanowić, czy narzut związany z negocjacją klucza będzie w ogóle opłacalny wydajnościowo.

6. WS-SecurityPolicy

WS-SecurityPolicy to protokół stanowiący uzupełnienie specyfikacji WS-Security o asercje polityki bezpieczeństwa w stylu znanym z WS-Policy. WS-SecurityPolicy wprowadza sześć rodzajów asercji dotyczących: Przykładowo asercja bezpieczeństwa może nakazywać, by uwierzytelnienie było oparte o bilety Kerberos.

7. WS-Trust

Jak wiemy usługa może zażądać od klienta spełnienia pewnych warunków opisanych w polityce: nazwy użytkownika, klucza, uprawnień, itp. Jeśli klient nie dostarczy takich dowodów (claims) w komunikacie może spróbować odwołać się do odpowiedniej zaufanej trzeciej strony (authority), które mogłoby dostarczyć mu odpowiednie żetony stanowiące dowód jego uprawnień do usługi. WS-Trust jest rozszerzeniem WS-Security uzupełniającym ten protokół o możliwość żądania i wystawiania żetonów bezpieczeńswa. WS-Trust obejmuje operacje: Zaufana trzecia strona (ang. security token service) może być wskazana w polityce usługi. Security token service jest odpowiednikiem Key Distribution Center znanego z Kerberos. Zaufana trzecia strona może ze swojej strony również zarządać dowodów (ang. claims), że dany klient jest rzeczywiście uprawniony do wystawienia mu certyfikatu. Security token service stanowi rodzaj pośrednika pomiędzy dwoma domenami – tą skąd pochodzi żądanie, a tą w której znajduje się usługa. De facto to relacja zaufania jest nieco inna – należy pamiętać, że funkcjonujemy w brokered trust relationship. Właściwą identyfikację klienta może wykonać jeden z pośredników i to on może dostarczyć odpowiednich żetonów do nagłówka WS-Security, które później zostaną odczystane przez ultimate receiver.

WS-Trust opisuje również protokół challenge-response wykorzystywany w momencie pobierania żetonu przez klienta (bądź któregoś z pośredników) – strona ubiegająca się o żeton musi w jakiś sposób udowodnić, że jest do tego uprawniona, że może być jego właścielem. Jeśli klient, bądź jeden z pośredników dostarczy żądanych dowodów sama usługa weryfikuje, czy ufa danemu security token service w zakresie wystawiania żetonów danego typu (np. określających uprawnienia). Usługa może również próbować zweryfikować dostarczone żetony u samego wystawcy (security token service). Ze względu na wygodę proponuje się stosowanie centralnego jednego źródła żetonów – wszystkie żetony otrzymane z tego źródła uznaje się za zaufane – w stopniu adekwatnym do zaufania do samego źródła żetonów. Takie centralny wystawca, czy repozytorium żetonów jest czymś w rodzaju Key Distribution Center znanego z Kerberos. Zasadne jest tutaj również porównanie do Certificate Authority – zwłaszcza w zakresie sprawdzenia, czy certyfikat wystawiony przez dane CA nie został unieważniony, a WS-Trust miałoby w tym miejscu funkcjonalność zbliżoną do CRL, lub bardziej do Online Certificate Status Protocol (OCSP).

Rysunek 13.1: Uwierzytelnienie z wykorzystaniem Security Token Service

8. Microsoft Web Services Enhancements

Oczywiście nawet najlepsza specyficje opracowywane w gronie największych market players, oraz osób posiadających ogromne doświadczenie nie wystarczy. Tylko implementacja może sprawić, że taki standard w ogóle znajdzie zastosowanie w praktyce. Nie wspominając już bezcennego doświadczenia, które może być zdobyte tylko na drodze praktycznego zastosowania. Implementacja powinna byc tak zaprojektowana, by była wygodna w użyciu, ale jednocześnie nie ograniczała w niczym użytkownika.

W przypadku specyfikacji WS brak odpowiedniej implementacji oznaczałoby dla programisty bezposrednie manipulowanie nagłowkami SOAP w kodzie aplikacji. Oczywiscie tego rodzaju manipulacja jest dopuszczalna i standardowa dystrybucja .NET Framework udostępnia tego rodzaju funkcjonalność. Rozsądniejszy programista zaprojektowałby zapewne zestaw filtrów do których mógłby podpinać jakieś konkretne akcje (np. kolejkowanie komunikatów). Ale w ogólności ograniczyłoby to znacząco grupę osób stosujących specyfikacje – a zatem efekt nie spełniłby oczekiwań twórców. Należy też wziąć pod uwagę fakt, że zaawansowane specyfikacje WS są cały czas na etapie rozwoju.

Na szczęście Microsoft wziął to pod uwage i dostarczył własną implementację specyfikacji WS – zgodną z duchem wspieranych specyfikacji. Podobnie jak application building blocks. WSE to zestaw klas stanowiących implementacje poszczególnych protokołów oraz filtrów przechwytujących i modyfikujących komunikaty przychodzące i wychodzące. WSE stanowi rodzaj wtyczki do ASP.NET. ASP.NET po otrzymaniu komunikatu SOAP i przekazuje go do obróbki WSE.

Każdy filtr odczytuje obsługiwany nagłówek – o ile nagłówek istnieje, po czym dodaje odpowiedni obiekt do tzw. kontekstu SOAP (SoapContext). SoapContext reprezentuje całą informację zawartą w nagłówku SOAP. Ta operacja jest wykonywana przez wszystkie filtry – odpowiednie bloki nagłówka są przy tej okazji usuwane. Po ogołoceniu nagłówka przez filtry komunikat jest przekazywany z powrotem do ASP.NET. Po odczytaniu wszystkich nagłówków Policy Input Filter sprawdza zgodność nagłówka wiadomości z polityką usługi. Odwrotny przebieg ma budowa nagłówka komunikatu wychodzącego – najpierw za pomocą dostępnego API tworzony jest SoapContext. Następnie jest przeprowadzana weryfikacja, czy utworzony kontekst spełnia przyjętą politykę. Po czym komunikat jest przekazywany do ASP.NET. WSE runtime to tak naprawdę jeden plik DLL zawierający definicję klas wykonywanych w zarządzanym środowisku Microsoft .NET. Biblioteka WSE może być dołączona do aplikacji klienckiej umożliwiając tym samym odczyt oraz wykorzystanie informacji zawartej w nagłówkach opisanych w specyfikacjach WS – zwłaszcza jeśli wykorzystywana usługa tego wymaga.