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ą:
- kto powinien przetwarzać (jest odbiorcą) dany blok (role). Rola w rozumieniu SOAP to powiązanie URI węzła
pośredniczącego, bądź końcowego odbiorcy z abstrakcyjną funkcjonalnością (np. Walidacją, autoryzacją –
przyznaniem uprawnień, ...). Sam SOAP definiuje tylko 2 role: Next – każdy węzeł poza pierwotnym nadawcą,
oraz UltimateReceiver;
- czy dany fragment nagłówka musi być przetworzony czy też nie (mustUnderstand);
- relay – czy bieżący węzeł powinien przekazać nierozpoznane opcje dalej, czy też powinien je usunąć.
Każdy węzeł bierze pod uwagę te atrybuty w trakcie przetwarzania nagłówka:
- 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.
- 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.
- Właściwe przetwarzanie komunikatu – opcjonalne bloki mogą być pominięte.
- 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):
- Zorientowanie na komunikaty – usługi komunikują się ze sobą wyłącznie za pośrednictwem komunikatów. Zatem
długość życia komunikatu musi często przekraczać czas transmisji – np. w przypadku zagubienia komunikatu;
- Komponowanie protokołów – unikanie monolitycznych rozwiązań w zakresie protokołów – protokoły mogą być
dowolnie dołączane w razie potrzeb;
- Autonomiczność usług – punkty końcowe konwersjacji są tworzone niezależnie od siebie, są też w różny
sposób zarządzane oraz zabezpieczane.
- W pełni zarządzana przezroczystość – usługi (a dokładnie wystawcy usług) dowolnie mogą regulować, które
elementy usługi są widoczne, a które pozostają niewidoczne.
- Integracja na poziomie protokołu komunikacji – zależności między autonomicznymi usługami ograniczają się
jedynie do komunikatów i ich zawartości – nie istnieją żadne inne sposoby wiązania (coupling) aplikacji – w
sensie w innych technologii implementacji.
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:
- URI przeznaczenie komunikatu – ultimate receiver;
- Source endpoint – usługa, która zainicjowała komunikat (sprawdzić, czy nie zmianę w nagłówku);
- 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ć:
- maksymalny rozmiar komunikatu (co może mieć znaczenie np. dla urządzeń przenośnych, albo ze względów
wydajnościowych);
- Okresy dostępności usługi.
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:
- Bilateralne uwierzytelnienie usługi wobec klienta, oraz klienta wobec usługi;
- Poufność transmisji;
- Niezaprzeczalność.
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:
- UsernameToken służący do przekazywania credentials w sposób prosty – <nazwa
użytkownika>/<hasło>;
- BinarySecurityToken – do przekazywania biletów Kerberos oraz certyfikatów X.509.
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:
- żetony uwierzytelniające klienta wobec usługi na których podstawie usługa jest w stanie określić
uprawnienia wołającego;
- informację, czy komunikat został zaszyfrowany, czy podpisany – i jeśli tak to przy pomocy jakiej metody.
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:
- oparte o tradycyjny sposób <nazwa użytkownika>/<hasło>,
- oparte o infrastrukturę klucza publicznego wykorzystującą standard X.509
- oparte o protokół Kerberos.
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):
- wsse:X509v3 – informuje, że binarnym żetonem jest certyfikat X.509 ver. 3
- wsse:Kerberos5TGT – żetonem jest Ticket Granting Ticket protokołu Kerberos
- wsse:Kerberos5ST – Service Ticket protokołu Kerberos 1.
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:
- Pierwszym sposobem jest ustalenie współdzielonego klucza tajnego (shared secret) przez zaufaną trzecią
stronę – security token service. W takim przypadku strona inicjująca połączenie pobiera shared secret (żeton)
i przekazuje go drugiemu uczestnikowi komunikacji.
- Drugi sposób to ustalenie shared secret oraz kontekstu bezpieczenstwa przez jedną ze stron komunikacji i
przekazanie go stronie przeciwnej.
- Trzeci sposób to znana z SSL/TLS negocjacja klient i usługa ustalają sposób najwłaściwszy dla obydwu
stron sposób zabezpieczenia.
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:
- żetonów bezpieczeństwa,
- integralności komunikatów,
- poufności komunikatów,
- widoczności zawartości komunikatów dla pośredników,
- ograniczenia dotyczące nagłówka bezpieczeństwa, oraz
- czas życia komunikatu.
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:
- żądania,
- przyjmowania,
- wystawiania,
- odnawiania, i
- walidacji żetonów bezpieczeństwa.
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.