Komunikacja i identyfikacja

Nowe API komunikacyjne WCF i mechanizmy autoryzacyjne CardSpace mają ułatwić budowę usługowych aplikacji i identyfikację ich użytkowników.

Nowe API komunikacyjne WCF i mechanizmy autoryzacyjne CardSpace mają ułatwić budowę usługowych aplikacji i identyfikację ich użytkowników.

Nowe, wchodzące w skład zaprezentowanej niedawno przez Microsoft platformy .Net 3.0, biblioteki API WCF (Windows Communication Foundation) i CardSpace mają wiele wspólnego z modną ostatnio architekturą SOA (Services Oriented Architecture). Według powszechnego przekonania SOA stanie się w najbliższym czasie główną architekturą wykorzystywaną przy konstrukcji aplikacji. Jej koncepcja zakłada, że system informatyczny podzielony jest na samodzielne usługi funkcjonujące autonomicznie i wymieniające między sobą komunikaty zgodne z tzw. kontraktem (umową między usługami). Komunikaty te zawierają wystarczającą ilość informacji do wykonania odpowiednich, wcześniej określonych czynności.

Komunikacja i identyfikacja

Standardowe bindingi Windows Communication Foundation

Jeżeli przyjrzymy się schematowi WSDL, który jest jednym z elementów Web Services, to łatwo zauważyć, że dokument ten definiuje kontrakt. W przypadku aplikacji .Net dokument taki powstaje dzięki temu, że do pewnych metod w klasie dopisany jest atrybut. Jest to wygodne, choć wielu programistów traktowało to jak po prostu inny mechanizm RPC. Innymi słowy, tworzyli klasę, a potem wszystkie metody publicznie udostępniali jako usługi Web. Z jednej strony było to łatwe do realizacji, z drugiej zwykle nie było separacji między implementacją a fasadą takiej usługi. Powodowało to, że gdy jakaś metoda miała dodatkowe pole, powstawał nowy interfejs Web niezgodny z aplikacjami klienckimi. W efekcie trzeba było równocześnie wymienić wszystkie klienty.

W samym WSDL są pewne mechanizmy, które pozwoliłyby na tworzenie różnych wersji kontraktu, ale powstaje problem ich właściwego oprogramowania, zarówno po stronie serwera, jak i klienta. Dodatkowo koncepcja WSDL w sensie dokumentu, który określa postać operacji i danych, byłaby wygodna także w innych sytuacjach, gdy wybór Web Service jako mechanizmu komunikacyjnego jest niewskazany. Występuje to np. wtedy, gdy potrzebna jest duża wydajność i przepustowość.

Właśnie te problemy chcieli rozwiązać twórcy biblioteki WCF. Jest to biblioteka komunikacyjna, która w ramach jednego API ujednolica różne sposoby komunikacji - od "gniazdek", przez sieć peer-to-peer, aż po usługi Web.

Uniwersalna komunikacja w Windows

Tworząc aplikację używającą WCF po pierwsze trzeba zdefiniować tzw. kontrakt. Określa on dokładną postać komunikatu przesyłanego między stronami. Zwykle ma postać interfejsu oznaczonego odpowiednimi atrybutami. Kontrakt definiowany jest na kilku poziomach - całego serwisu, operacji i danych. Dodatkowo można określić, jak przesyłane są wyjątki.

Komunikacja i identyfikacja

Interfejs CARDSPACE wyboru "dowodu tożsamości"

Elementy operacyjne określają metody i czynności, jakie można wykonać za pośrednictwem usługi (mniej więcej odpowiadają one metodom). Używając atrybutów, można także definiować konkretne wzorce typów operacji, np. czy jest to operacja jednokierunkowa, czy wymaga callback, czy jest asynchroniczna. Dla każdego typu kontraktu generowana jest odpowiednia struktura komunikatu. Kontrakt danych definiuje informacje potrzebne do wykonywania operacji. Przykładem takiego kontraktu może być klasa określająca, jakie informacje zawiera obiekt klient, jakie są pola itp. Oba mechanizmy pozwalają łatwo definiować, jakie elementy były dodawane lub zmieniane w kolejnych wersjach. Przykładowo, definiując DataContract, można określić kolejność serializowania danych, co pozwala, by starsza wersja klienta po prostu nie otrzymywała pewnych pól. Można także zejść niżej i samodzielnie definiować pełną postać komunikatu. WCF pozwala, aby programista miał pełną kontrolę nad sposobem serializacji i deserializacji obiektów.

Elementem, który określa

techniczny sposób przesyłania komunikatów, jest tzw. binding. Definiuje on zarówno metody serializacji obiektu - czy będzie on zapisany w formacie XML, binarnym, czy ewentualnie będzie kompresowany, jak i protokół, przy wykorzystaniu którego dany obiekt będzie przesyłany. Proszę zauważyć, że nic nie stoi na przeszkodzie, aby skonfigurować binding tak, by np. przy zastosowaniu protokołu HTTP przesyłać dane binarne. Nie ma wtedy problemów administracyjnych (komunikacja łatwo przechodzi przez różne zapory firewall itp.), a proces jest względnie szybki, bo nie ma narzutu wynikającego z konieczności generowania plików XML.

Następnie definiowany jest tzw. adres określający, w którym miejscu nasłuchuje dana usługa. Może to być konkretny port i adres TCP, URL lub też identyfikator węzła w sieci peer-to-peer. W WCF występuje także pojęcie endpoint, które obejmuje kontrakt, adres i binding, określając dokładne miejsce, w którym opublikowana jest konkretna usługa. Warto dodać, że jedynym elementem, który w WCF należy zdefiniować w kodzie, jest kontrakt i jego ewentualna implementacja. Pozostałe elementy endpoint są konfigurowane i teoretycznie - przy dobrze zaprojektowanej aplikacji - można je dowolnie ustawiać.

W przypadku gdy wykorzystywany jest mechanizm dwukierunkowego bindingu (tzw. duplex binding), czyli np. gdy serwer musi przesłać informacje do klienta w trybie callback, to wtedy po stronie aplikacji klienckiej także wystawiany jest endpoint z kontraktem określającym, jakie operacje może wykonać serwer. Taki sam mechanizm można zastosować również do usług Web. WCF wykorzystuje wtedy serwer WWW działający po stronie klienta. Jest to możliwe, bo - zaczynając od wersji Windows XP - w systemie działa specjalny moduł kernela http.sys, który na poziomie jądra obsługuje protokół HTTP. Pozwala on na współdzielenie jednego portu przez wiele aplikacji - wystarczy, aby usługi miały różne URI, co łatwo można zapewnić. W takim przypadku używa się jednak zwykle protokołów P2P lub IPv6, bo wtedy łatwiej jest oczekiwać na komunikaty, jeśli w sieci stosowany jest mechanizm NAT do translacji adresów lub inne tego typu rozwiązanie.

Sposób zachowania usługi

Ciekawą koncepcją WCF są tzw. zachowania. Pozwalają one, niezależnie od kontraktu, określać pewne wzorce działania usługi. Można definiować zasady synchronizacji, czas życia i sposób inicjacji obiektów implementujących serwis (np. czy jest to jeden obiekt dla wszystkich klientów - singleton, czy też jeden obiekt, ale dla danej sesji konkretnego użytkownika). Można też określać, czy użytkownik jest impersonalizowany.

Zachowanie jest także mechanizmem konfigurowalnym, teoretycznie niezależnym od kontraktu. Warto pamiętać, że jest to taki element, który co prawda bezpośrednio nie wpływa na definicje komunikatów, ale programista implementując rozwiązanie, zakłada, że np. operacje odbywają się w ramach transakcji. Zachowanie może powodować, że pewne określone bindingi nie będą mogły być stosowane, bo nie pozwalają na realizację transakcji.

Użycie WCF wcale nie wymusza stosowania metodologii SOA. Pakiet ten można potraktować jako zwykłą bibliotekę funkcji komunikacyjnych, a nawet stosować analogiczne rozwiązania jak w wypadku .Net Remoting, gdzie wykorzystywane są referencje do obiektów działających na zdalnej maszynie.

Weryfikacja w CardSpace

W .Net 3.0 wprowadzony został nowy mechanizm autoryzacji - CardSpace. Aby z niego skorzystać, klient powinien zostać wyposażony w pewien określony zbiór tzw. dowodów tożsamości, który może zawierać różnego typu informacje, np. imię, nazwisko, adres e-mail, datę urodzenia, płeć, numer NIP, PESEL, liczbę dzieci itd. Zawartość informacyjna konkretnego dowodu tożsamości zależy od uzgodnień między jego wystawcą a odbiorcą. Warto zauważyć, że w odróżnieniu od mechanizmów stosowanych przez Microsoft Passport, w przypadku CardSpace dane są przechowywane na komputerze klienckim. Choć pierwotnie Microsoft zapowiadał, że Windows Vista do przechowywania tych dowodów osobistych będzie wykorzystywał fizyczną, zabezpieczoną sprzętowo pamięć. Ostatecznie firma zdecydowała się na zastosowanie modułu programowego.

CardSpace jest systemem federacyjnym. Strona żądająca dowodu może określić, kto ma go wystawić, a klient definiuje, jakie dane udostępni. W ten sposób sklep internetowy może uzyskać od banku potwierdzenie wieku kupującego lub prawdziwości danych osobowych, ale pod warunkiem że klient zgodzi się je przekazać. Należy dodać, że dzięki takiemu mechanizmowi nie trzeba będzie zakładać wciąż nowych kont w każdym z odwiedzanych sklepów. CardSpace bazuje na otwartych protokołach, m.in. WS-MetadataExchange, WS-Security, WS-Trust, WS-SecurityPolicy. Przy przekazywaniu informacji generowany jest dokument zgodny np. z formatem SAML 1.0. Według niepotwierdzonych jeszcze oficjalnie informacji, Microsoft zamierza też opracować moduł dla przeglądarki Firefox umożliwiający obsługę funkcji CardSpace przez ten program.

Na razie jednak nie wiadomo, jak i przez kogo będą generowane dowody tożsamości. Choć bowiem .Net 3.0 jest wyposażone w funkcję Local Security Token Service (Local STS), która umożliwia samodzielne wystawianie takich dowodów, to - z punktu widzenia ich odbiorcy - jest to mało wiarygodny mechanizm, bo nie ma żadnej kontroli prawdziwości danych. Pojawia się więc pytanie, czy powstaną procedury i godne zaufania instytucje, które będą takie informacje publikować. W innym wypadku każdy sklep lub serwer, w którym użytkownik będzie chciał się zalogować, zażąda przedstawienia dowodu wystawionego przez własny system.

Łączenie WCF i CardSpace

WCF i CardSpace można bardzo prosto połączyć. Wystarczy w pliku konfiguracyjnym określić, jakie stwierdzenia (claims) są wymagane i kto ma je wystawiać. Gdy klient będzie chciał skorzystać z usługi, zostanie zapytany o to, jakim dowodem chce się przedstawić, a następnie odpowiednie informacje są przesyłane jako dokument XML w formacie SAML do serwera i umieszczane w kolekcji ClaimSet dostępnej dla danej usługi.

Oprócz tego WCF ma bardzo rozbudowane mechanizmy bezpieczeństwa. Komunikacja może być zabezpieczana na poziomie transportu (także sprzętowo), samego komunikatu, można dodatkowo przekazywać dane wystarczające do impersonalizacji, wykorzystać grupy Windows lub mechanizm Principal Permission. Ale warto podkreślić, że CardSpace w naturalny sposób pozwala na zdefiniowanie "łańcucha zaufania" między różnymi organizacjami - wystarczy, że usługa będzie akceptować dowody wystawione przez inne określone instytucje lub firmy.

Gdy w 2007 r. pojawi się na rynku Windows Longhorn Server, będzie on wyposażony w Active Directory STS. Nie wiadomo natomiast czy taki dodatek powstanie dla Windows 2003. Nie należy mylić STS z mechanizmem Active Directory FS (Federation Services). O ile CardSpace i STS to przede wszystkim narzędzie do wyboru tożsamości i infrastruktura do przekazania danych usługom, o tyle Active Directory FS umożliwia połączenie kilku instancji usług katalogowych w ramach federacji.

Główne zasady tworzenia aplikacji zgodnych z koncepcją SOA:
  • Boundaties are explicit - jasno zdefiniowane granice
  • Services are autonomous - usługi są autonomiczne
  • Share schema and contract and not class - współdzielony schemat/kontrakt, a nie klasa
  • Separation of sematic and structural Policy - określa zasady zgodności
W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200