Uwierzytelnianie w świecie serwisów
W czasach, gdy korzystanie z architektury z wieloma serwisami to codzienność, coraz częściej pojawia się problem ochrony dostępu do zasobów przez nie udostępnianych. Rozwiązania naiwne bardzo szybko stają się nieskalowalne, a ich rozwijanie i utrzymywanie bardzo uciążliwe. Na szczęście istnieje skuteczna alternatywa, którą mieliśmy okazję wypróbować w Medicalgorithmics - podczas prototypowania komponentów służących do integracji naszego systemu PocketECG z systemem szpitalnym jednej z klinik.
Aby uzyskać dostęp do zasobów wystawianych przez serwis, klient musi standardowo dostarczyć serwisowi danych do uwierzytelnienia, a serwis - zweryfikować, czy uzyskane dane są wystarczające z punktu widzenia zdefiniowanych reguł dostępu. Generuje to szereg problemów. Na przykład, przy próbie uwierzytelniania z wykorzystaniem nazwy użytkownika i hasła, serwis musi mieć dostęp do bazy danych z użytkownikami - mimo, że jego funkcjonalność nie musi w żaden sposób dotykać użytkowników i ich danych. Problem nasila się, gdy takich serwisów będziemy mieć wiele, a powyższa logika powinna być dostępna w każdym z nich, co znacząco komplikuje zależności pomiędzy projektami. A co, jeśli będziemy chcieli zmienić rodzaj uwierzytelnienia, przykładowo - rezygnując z haseł na rzecz certyfikatów?
W tym i wielu innych przypadkach pomocny będzie federacyjny model tożsamości (federated identity) i uwierzytelniania (federated authentication). Ich działanie dobrze zilustruje przykład. Wyobraźmy sobie, że chcemy wybrać się do kina. Film zawiera sceny przemocy, więc osoby poniżej 18 roku życia nie będą na niego wpuszczane. Skąd bileter w kinie będzie wiedział, czy może sprzedać bilet danemu klientowi? Zostanie mu przedstawiony token (dowód osobisty), wystawiony przez państwo - zaufaną przez kino instytucję. Na tej podstawie bileter oceni, czy klient jest uprawniony do uczestnictwa w seansie. W tej sytuacji możemy wyróżnić trzy podmioty: klient, kino oraz państwo, które wydaje każdemu obywatelowi dokument poświadczający informacje o właścicielu. Można powiedzieć, że pomiędzy kinem, a państwem zawarta jest jednostronna relacja zaufania. Dla kina nie jest ważny sposób, w jaki państwo wydało dokument, a jedynie to, że dokument wystawiła zaufana instytucja i zawiera informacje wystarczające do określenia pełnoletności klienta.
W schemacie uwierzytelniania federacyjnego wyróżniamy podmiot nazywany zwyczajowo Security Token Service (STS) - jego rolę w powyższym przykładzie spełnia państwo. STS jest odpowiedzialny za całą logikę związaną z uwierzytelnieniem w danej domenie. Wystawia podpisane cyfrowo tokeny zawierające zbiór cech (claims). Pozostałe podmioty w domenie (na poniższym diagramie - usługi A i B, a na przykładzie wyżej - kino) są skonfigurowane tak, aby ,,ufać’’ tokenom podpisanym przez STS. Jeśli dany podmiot wymaga uwierzytelnienia i autoryzacji dostępu do zasobu, czynności te dokonywane są na podstawie cech zawartych w tokenie. Co więcej - podobnie jak z dowodem osobistym - raz uzyskany token może być użyty wielokrotnie, dzięki czemu unikamy redundantnych żądań o uwierzytelnienie.
Poniższy diagram przedstawia uwierzytelnianie federacyjne w ramach jednej domeny/systemu:
Uwierzytelnianie federacyjne sprawdza się nie tylko w scenariuszu ograniczonym do jednej domeny. Jego użyteczność jest tym bardziej widoczna w przypadku uwierzytelniania pomiędzy różnymi obszarami lub systemami. Wyobraźmy sobie sytuację, w której chcemy umożliwić klientom zewnętrznej firmy logowanie się do naszego systemu i korzystanie z jego zasobów - to właśnie tego typu scenariusz był szczególnie interesujący dla Medicalgorithmics.
Nawet przed wdrożeniem rozporządzenia RODO trudno oczekiwać, że nieznana firma przekaże nam swoje dane o klientach lub swoich użytkownikach, włączając w to dane osobowe, czy hasła - tylko po to, by użytkownicy obcego systemu mogli uwierzytelniać się tymi samymi poświadczeniami w obu systemach. Dzięki relacji zaufania między naszym STS, a komponentem STS w zewnętrznym systemie, agenci komponentów służących do integracji z zewnętrznymi klinikami uwierzytelniają się w naszym STS danymi dla nas niedostępnymi - tylko na podstawie tokenu ze swojego STS. W ten sposób uzyskują token naszego STS, na którego podstawie komponenty naszego systemu mogą ocenić jakie - i czy w ogóle - operacje i usługi może wykonać dany lekarz.
Na diagramie widzimy uwierzytelnianie federacyjne między dwoma domenami/systemami.
Schemat uwierzytelniania federacyjnego jest świetnym rozwiązaniem jeśli planujesz integrację wielu komponentów lub rozproszenie swojego oprogramowania na wiele podsystemów - z utrzymaniem spójnego, wydzielonego modelu uwierzytelniania dla wszystkich podsystemów. Na szczęście platforma .NET umożliwia bezproblemową i wygodną implementację tego typu rozwiązań przy pomocy standardowych technologii, takich jak WCF, czy ASP.NET.