Platforma Windows Azure - AppFabric

Autor: Grzegorz Glonek

Opublikowano: 2011-06-13

Pobierz i uruchom Windows Azure SDK 1.6

Wprowadzenie

Ostatnim elementem składającym się na platformę Azure jest Platform AppFabric, udostępniający infrastrukturę pozwalającą na dwustronną komunikację pomiędzy aplikacjami umieszczonymi w chmurze i tymi uruchomionymi lokalnie, a także pomiędzy aplikacjami lokalnymi działającymi u różnych klientów.

Budowa

W tej usłudze można wydzielić dwa moduły, zaprezentowane na rysunku 1.

Rys.1.Struktura Windows Azure Platform AppFabric.

Pierwszym z nich jest szyna usług (service bus), pozwalająca na udostępnienie usług między aplikacjami działającymi lokalnie w dwóch różnych przedsiębiorstwach. Chcąc zrealizować takie zadanie, napotykamy zazwyczaj przynajmniej jeden z dwóch problemów. Po pierwsze, sieci wewnętrzne w firmach zazwyczaj wykorzystują NAT, co sprawia, że usługa taka nie posiada stałego, publicznego adresu IP – przez to nie można określić, z jakim adresem ma się komunikować aplikacja klienta, któremu chcemy udostępnić usługę. Jeżeli jednak sieć firmowa nie korzysta z mechanizmu NAT, problemem może stać się komunikacja przez zabezpieczenie firewall. Wymagałoby to odblokowania przez administratora dodatkowych portów do komunikacji, a to mogłoby z kolei łamać wewnętrzne procedury bezpieczeństwa w firmie. Szyna usług zawarta w Platform AppFabric ma za zadanie rozwiązać problem takiej właśnie komunikacji. Rejestruje ona końcówkę (endpoint) upublicznioną przez usługę działającą lokalnie w firmie i tworzy w chmurze dedykowaną końcówkę dla tej usługi. Następnie usługa tworzy połączenie z szyną, które jest wciąż podtrzymywane, co sprawia, że nie ma już problemu z komunikacją poprzez NAT, ponieważ taki ruch sieciowy zawsze będzie kierowany do właściwej aplikacji. Poza tym odpowiedzi na komunikację rozpoczętą przez usługę wewnątrz przedsiębiorstwa nie są blokowane przez firewall, co rozwiązuje kolejny z potencjalnych problemów. Klient, chcąc teraz skomunikować się z taką usługą, łączy się z szyną i na podstawie listy zarejestrowanych w niej usług komunikuje się z odpowiednią końcówką stworzoną w chmurze. Następnie przekazuje wszystkie żądania do usługi lokalnej i przesyła jej odpowiedzi do klienta. Dodatkowo, jeżeli okaże się to możliwe, tworzy bezpośrednie połączenie pomiędzy klientem a usługą, dzięki czemu zwiększa wydajność komunikacji.

Innym aspektem korzystania z szyny jest zwiększenie bezpieczeństwa, ponieważ adres udostępnianej usługi pozostaje dla klientów zewnętrznych niewidoczny. Jedynym adresem, jaki znają jest adres szyny, na której istnieje końcówka komunikująca się z aplikacją wewnątrz przedsiębiorstwa. Cały proces komunikacji między usługą lokalną, szyną i klientem przedstawiony jest na rysunku 2.

Rys.2.Schemat działania szyny usług Platform AppFabric.

 Drugim modułem wchodzącym w skład Platform AppFabric jest element odpowiedzialny za kontrolę dostępu do usług (access control– AC). Klient, zanim zacznie komunikować się z konkretną usługą, musi uzyskać token generowany przez ten moduł. Aby go uzyskać, klient musi dokonać autentykacji, co może zrobić na trzy sposoby. Po pierwsze, może wysłać do AC jawny identyfikator za pośrednictwem protokołu HTTP lub HTTPS. Identyfikator ten musi być uprzednio zarejestrowany w module kontroli dostępu, aby było wiadomo, w jaki sposób postępować z daną aplikacją. W tym przypadku wszystkie niezbędne dane muszą zostać wprowadzone do modułu przez administratora. Drugim sposobem jest przesłanie przez klienta do AC kolekcji swoich danych podpisanych 32-bitowym kluczem. Kolekcja ta jest prostym zbiorem par klucz-wartość. Moduł kontroli sprawdza poprawność tego klucza, a następnie na podstawie przesłanych przez aplikację informacji generuje odpowiedni token. Kolekcja ta zawiera następujące pola:

• Issuer – pole obowiązkowe zawierające klucz identyfikujący, użyty do podpisania SWT.
• Audience – pole opcjonalne, używane do identyfikacji czy na pewno AC jest odbiorcą tego SWT.
• ExpiresOn – pole opcjonalne określające okres ważności przesyłanych danych.
• AdditionalClaims – pole opcjonalne, zawierające dodatkowe parametry, które mogą być użyte przez AC do wygenerowania tokena.
• HMACSHA256 – pole obowiązkowe; stanowi ono podstawę sprawdzenia poprawności przesyłanych danych do AC.

Ostatnią metodą jest wykorzystanie formatu SAML (Security Assertion Markup Language) oraz usług federacyjnych. Aby było to możliwe, musi zostać nawiązana federacyjna relacja zaufania pomiędzy aplikacją kliencką a AC, a następnie to serwer, na którym uruchomiona jest usługa federacyjna, generuje token SAML, który autentykuje aplikację kliencką.

Po przeprowadzeniu autentykacji moduł kontroli dostępu tworzy kolekcję par klucz-wartość zawierającą informacje na temat aplikacji klienckiej. Wszystkie te informacje są podpisane generowanym przez AC kluczem i zostają zwrócone do klienta. Następnie, wykorzystując te dane, klient komunikuje się bezpośrednio z usługą i to ona decyduje, w jaki sposób obsłużyć zapytanie (w szczególności odmówić praw do wykonywania jakichkolwiek operacji przez danego klienta). Cały ten proces przedstawia rysunek 3.

Rys.3.Schemat działania kontroli dostępu w Platform AppFabric.

Podsumowanie

W tym artykule zapoznaliśmy się z budowa i działaniem ostatniego z głównych modułów platformy Windows Azure.

Wiedząc już, z czego zbudowana jest chmura Widnows Azure i jak ona działa, z kolejnego artykułu dowiemy się, w jakich sytuacjach warto w ogóle korzystać z chmur.

---

          

Grzegorz Glonek (MCP, MCTS)

Absolwent Wydziału Fizyki Technicznej, Informatyki i Matematyki Stosowanej Politechniki Łódzkiej. Uczestnik konkursu ImagineCup. Wraz z drużyną fteams zdobył w 2009 roku drugie miejsce na finałach światowych tego konkursu w kategorii Software Design : InteroperabilityAward oraz pierwsze miejsce w finałach krajowych kategorii Software Design w 2010 roku. Obecnie zatrudniony w polskim oddziale firmy Microsoft na stanowisku Software Development Engineer in Test.