Azure AppFabric i Access Control Service – uwierzytelnianie za pomocą zewnętrznych dostawców 

Autor: Piotr Zieliński

Opublikowano: 2011-03-22

Wprowadzenie

W dzisiejszym internetowym świecie użytkownicy muszą kłopotać się ogromną ilością loginów i haseł. Większość serwisów wymaga stworzenia nowego konta i tym samym hasła. Istnieje kilka popularnych serwisów\dostawców takich jak Yahoo, Google, Facebook czy Windows Live ID. Zamiast zmuszać użytkownika do stworzenia nowego konta przekierowalibyśmy go do strony logowania np. na Windows Live. Dodatkowo zewnętrzny serwis oszczędziłby nam pracy związanej z zaprojektowaniem bezpiecznego systemu uwierzytelnienia. Użytkownicy zadowoleni będą z obsługi takiej strony, a my jako programiści nie będziemy musieli zajmować się z testami związanymi z bezpieczeństwem.

Dzięki Access Control Service (ACS) stanie się to jeszcze łatwiejsze, ponieważ programiści nie muszą zagłębiać się w szczegóły protokołów poszczególnych dostawców – wszystko zrobi za nas ACS!

Wymagania

Aby zaimplementować aplikację przedstawioną w tym artykule, należy zaopatrzyć się dodatkowo w:

• Windows Identity Foundation Runtime,
• Windows Identity Foundation SDK,
• Konto założone na https://portal.appfabriclabs.com. W chwili obecnej ACS dostępny jest w dwóch wersjach. Oficjalna i wspierana wersja (https://appfabric.azure.com/) o mniejszej funkcjonalności oraz wersja rozwojowa (https://portal.appfabriclabs.com), gdzie dostępne są między innymi mechanizmy pozwalające na federację z większą liczbą dostawców. Wersja appfabriclabs obsługuje dodatkowe formaty tokenów i np. wspiera „z pudełka” integrację z Active Directory (za pośrednictwem (AD Federation Services).

Jak to działa?

Zanim przejdziemy do implementacji, warto zapoznać się z działaniem ACS od strony teoretycznej. W architekturze ACS wyróżnia się trzy podstawowe elementy:

• Relying party (RP),
• Identity provider (IP),
• Federation Provider (FP).

Relying party (RP) stanowi element, do którego próbujemy się zalogować, czyli np. nasza strona www. Natomiast Identity provider (IP) odpowiedzialny jest za uwierzytelnianie i wydanie specjalnego tokena.  Przykładem IP jest Windows Live ID – usługa odpowiada za proces logowania, a RP (nasz serwis) wyłącznie z niego korzysta (ufa mu). Podstawowy model z RP i IP może wyglądać więc następująco:

Użytkownik chcący skorzystać z chronionych zasobów na stronie (RP) najpierw uzyskuje token z IP, a potem przekazuje go do RP, który ufa IP. Użytkownicy więc wpisują loginy i hasła w IP, a nie w RP.

Przedstawiony powyżej model nie zawiera Federation Provider. Co w przypadku, gdy chcemy skorzystać z kilku IP jednocześnie? Na przykład chcemy zaprojektować stronę, na której użytkownicy mogą logować się za pomocą kont z Yahoo, Facebook, Google lub Windows Live. Uzależnienie RP od każdego z IP jest nieeleganckim i skomplikowanym rozwiązaniem. Federation Provider jest elementem pośrednim między Relying Party a Identity Provider. RP za pomocą tego samego protokołu łączy się z FP, a następnie FP jest odpowiedzialny za uzyskanie prawidłowego tokena z jakiegoś IP. Ponadto FP ze względu na to, że stanowi element pośredni może dokonywać normalizacji na tokenach wydawanych z różnych źródeł, np. poprzez dodanie jakiegoś pola, którego spodziewa się aplikacja.

Token oprócz czystej informacji o zalogowaniu przechowuje dodatkowe dane, tzw. żądania (claims). Żądanie to dowolna informacja, np. imię, nazwisko, rola, lista modułów, do których dany użytkownik ma dostęp itp. Zadaniem IP oraz FP jest przydzielenie odpowiednich żądań danemu użytkownikowi.

Konfiguracja ACS

Aspekty teoretyczne powinny być już jasne. Jeśli coś jeszcze jest niezrozumiałe, to po implementacji wszystko powinno stać się intuicyjne. Zanim przejdziemy do pisania aplikacji, powinniśmy najpierw skonfigurować odpowiednio ACS za pomocą webowego panelu administratora:

1. Wchodzimy na https://portal.appfabriclabs.com i podajemy dane konta Azure:

   

2. Klikamy jakiś projekt (lub go tworzymy, jeśli nie mamy żadnych).

3. Jeśli nie utworzono jeszcze Service Namespace, klikamy na Add Service Namespace i tworzymy jedną przestrzeń. Następnie klikamy na Access Control:

   

4. Klikamy na Manage Access Control.

5. Następnie możemy przejść do konfiguracji ACS. Większość rzeczy jest wyjaśnionych po prawej stronie w Getting Started:

   

6. Teraz musimy dodać Identity Provider, czyli elementy odpowiedzialne za autoryzację. Klikamy więc w menu na Identity Providers i dodajemy stosownych dostawców.

   

   Warto zauważyć, że oprócz Windows Live ID mamy do dyspozycji kilka innych IP:

   

7. Następnie musimy dodać Relying Party, podając m.in. jego adres (np. https://localhost/Website), nazwę oraz parametry typu adres strony, która powinna pojawić się w przypadku błędu lub prawidłowego zalogowania. Można również wybrać format tokena (np. SAML 2.0).

   

8. RuleGroups służą do generowania wspomnianych żądań.  Wystarczy przejść do odpowiedniej strony i kliknąć Generate w celu utworzenia żądań dla każdego z dostawców:

   

Utworzenie aplikacji ASP.NET oraz jej konfiguracja

Po konfiguracji AppFabric można stworzyć lokalnie aplikację ASP.NET i podłączyć do niej stosowny STS (Security Token Service – usługa odpowiedzialna za wydawanie tokenów). Wykonujemy zatem poniższe kroki:

1. z menu głównego Visual Studio wybieramy File->New->WebSite,

2. wybieramy HTTP, Local IIS, a następnie wybieramy jakąś stronę – ważne, aby skorzystać z IIS, a nie Development Server, ponieważ nie pod wszystkimi pulami (Application Pool) system będzie działać,

3. klikamy w Solution Explorer na projekcie ASP.NET i z menu kontekstowego wybieramy Add STS Reference (musi zostać najpierw zainstalowany Windows Identity Foundation).

   

4. Zaznaczamy UseanExisting STS i podajemy adres do metadanych, który możemy znaleźć w panelu Azure (Application Integration):

   

5. Przechodzimy wszystkie kroki kreatora i klikamy Finish.

Aby przekonać się, że uwierzytelnianie faktycznie działa, uruchamiamy aplikację. Po naciśnięciu F5 w VS natychmiast zostaniemy przekierowani do strony logowania:

Wybieramy jedno z dostępnych kont, np. Windows Live ID – powinniśmy zostać przekierowani do strony logowania Windows Live. W zależności od wybranego dostawcy (Yahoo, Google, Live) pojawi się inny formularz uwierzytelniania.

Z poziomu kodu mamy dostęp do wszystkich żądań skonfigurowanych w panelu ACS:

Microsoft.IdentityModel.Claims.ClaimsIdentity identity = null;

identity = Page.User.Identity as Microsoft.IdentityModel.Claims.ClaimsIdentity;

// identity.Claims[0].Value

Zakończenie

ACS znacząco ułatwia proces uwierzytelniania w aplikacjach webowych. Twórcy podobnych rozwiązań z pewnością wiedzą, ile pracy trzeba poświęcić na zapoznanie się z SDK poszczególnych dostawców, a następnie na gruntowane przetestowanie zaimplementowanego rozwiązania pod kątem bezpieczeństwa. Aplikacje oparte na ACS ułatwiają korzystanie z serwisu użytkownikom (nie muszą zakładać nowych kont) oraz programistom (nie muszą się martwić o przechowywanie informacji poufnych).