Łączenie tożsamości w systemach rozproszonych

SAML 2.0 zawiera wszystkie najważniejsze mechanizmy swoich poprzedników. Specyfikacja wyróżnia dwie podstawowe role w federacji: "dostawca usługi" jest jednostką udostępniającą aplikacje lub zasób użytkownikowi, natomiast "dostawca tożsamości" jest odpowiedzialny za uwierzytelnienie użytkownika. Dostawca usługi i dostawca tożsamości wymieniają komunikaty pozwalające na jednokrotne logowanie (SSO) i jednokrotne wylogowanie. Wymiana takich komunikatów może być inicjowana przez dostawcę tożsamości lub dostawcę usługi.

Łączenie tożsamości w systemach rozproszonych

Federacja w działaniu

W ramach SSO dostawca tożsamości odpowiedzialny jest za utworzenie asercji SAML, zawierającej dane o tożsamości użytkownika, i następnie bezpieczne wysłanie jej do dostawcy usługi. Dostawca usługi jest odpowiedzialny za zatwierdzenie asercji SAML przed otwarciem użytkownikowi dostępu do aplikacji.

Asercja SAML jest dokumentem XML zawierającym informacje dotyczące tożsamości użytkownika: m.in. jak użytkownik był uwierzytelniany oraz - opcjonalnie - dodatkowe atrybuty użytkownika.

Protokół likwiduje konieczność wyboru protokołu sfederowania i eliminuje potrzebę uruchamiania skomplikowanych rozwiązań wieloprotokołowych.

Trudną sprawą, leżącą poza sferą technologii, jest zarządzanie procesami i powiązaniami biznesowymi w sposób zapewniający, że sfederowanie jest bezpieczne i umożliwia odpowiednią ochronę prywatności.

Brak jest powszechnie akceptowanych dobrych praktyk, jak również powszechnie akceptowanych wzorców porozumień. W wielu przypadkach któryś z udziałowców stosuje federację po raz pierwszy, a implikacje prawne nie zawsze są oczywiste.

Niektóre sfederowania są relatywnie proste i w konsekwencji łatwe do zarządzania. Na przykład jeżeli oferuje się usługę online, federacja największych klientów w ramach systemu tożsamości daje realne korzyści. Fakt posiadania powiązań biznesowych z klientami ułatwia strukturalizowanie takiej federacji i takie przedsięwzięcie rzadko stwarza ryzyko finansowe lub naruszenia reguł prawnych.

Delegowanie administrowania tożsamością do klienta oznacza np., że nie trzeba się już martwić o użytkowników zgłaszających się do help desku z powodu zagubienia hasła. Ponadto federacja tworzy wartość dodaną dla klientów firmy, zwiększając ich wygodę i redukując problemy bezpieczeństwa.

Kiedy jednak użytkownik zostanie uwierzytelniony w innym ośrodku jako jedna ze stron wchodzących do akcji o realnych konsekwencjach finansowych, sytuacja staje się bardziej skomplikowana. Tego rodzaju problemy wymagają odpowiednich regulacji i określenia zakresu odpowiedzialności.

Na przykład federacja w ramach portali dla pracowników wnosi problem: kto jest właścicielem danych o tożsamości i kto ma ostateczny głos, gdy dane te nie są zgodne. Problemy przynależności danych nie są ograniczone do partnerów zewnętrznych - integracja pomiędzy systemami kadrowymi i finansowymi wewnątrz jednej organizacji może czasami być bardziej skomplikowana i trudna.

Problemy regulacji prawnych mogą być jeszcze większe, kiedy ma się do czynienia z danymi finansowymi lub innymi wrażliwymi informacjami. Firmy globalne mają jeszcze większy problem - często muszą spełniać wymagania, czasami sprzeczne, dotyczące ochrony danych osobowych obowiązujące w różnych krajach świata.

Portale pracowników wnoszą także problem współodpowiedzialności finansowej. Kiedy dana firma uwierzytelnia pracownika dla jednego ze swoich licznych poddostawców, to w efekcie ręczy za tę osobę. Jeżeli jednak coś pójdzie nie tak i powstaną z tego tytułu jakieś straty, to kto będzie za nie odpowiedzialny? Federacja wymaga, aby pracodawca brał pewną odpowiedzialność za swoich pracowników.

Brama federacyjna łączy standardy

Łączenie tożsamości w systemach rozproszonych

Brama federacyjna

Jedną z metod federacji w ramach różnych systemów standaryzacji jest zastosowanie bramy federacyjnej, łączącej różne standardy tożsamości federacyjnej.

Brama federacyjna zapewnia usługi translacji protokołów na styku między organizacjami używającymi różnych protokołów sfederowanej tożsamości.

Podstawą tożsamości federacyjnej jest relacja zaufania pomiędzy organizacją, która uwierzytelnia użytkownika (dostawcą tożsamości), a ośrodkiem, który polega na tym uwierzytelnieniu i zapewnia bezpieczny dostęp do aplikacji lub usługi (dostawcą usługi). Brama federacyjna eliminuje potrzebę używania tego samego protokołu i wersji sfederowanego zarządzania tożsamością u dostawcy tożsamości i usługi.

Jako przykład można podać sposób działania bramy federacyjnej operującej w ośrodku dostawcy usługi, która musi przetwarzać żądania zapewnienia dostępu do aplikacji pochodzącej od wielu dostawców tożsamości. Firma działająca jako "dostawca usług" używa np. protokołu SAML 1.1 do oferowania partnerom sfederowanego dostępu do swoich aplikacji webowych. Firmy partnerskie, żądające dostępu do aplikacji dostawcy usług, działają jako "dostawcy tożsamości" i używają różnych protokołów: SAML 2.0, Liberty 1.1 i Libery 1.2.

Brama federacyjna pozwala na współdziałanie systemu zarządzania tożsamością federacyjną dostawcy usług z systemami sfederowanej tożsamości firm z nich korzystających, ponieważ transluje asercje SAML 2.0, Liberty 1.1 i Liberty 1.2 na SAML 1.1, zanim prześle je do aplikacji dostawcy usług. Natomiast w odwrotnym kierunku dostawca usług przedstawia się każdemu z dostawców tożsamości, używając jego protokołu zarządzania sfederowaną tożsamością. Sposób pracy bramy federacyjnej przedstawia rysunek.

Tożsamość federacyjna oznacza możliwość dostępu do informacji rozproszonych w różnych organizacjach, używających bezpiecznych sieci. Jednym z mechanizmów, który to zapewnia, jest SSO, gdzie pojedyncza nazwa użytkownika i pojedyncze hasło służy do uzyskania dostępu do wielu aplikacji. Standardowa specyfikacja ma umożliwić wymianę danych, weryfikujących tożsamość, pomiędzy różnym wyposażeniem sieciowym.

Wiele aplikacji, dla których wprowadza się SSO, to aplikacje webowe. Najprościej wdrożyć dostęp do aplikacji w ramach przedsiębiorstwa, wykorzystując techniki przeglądarkowe. W przypadku federacji aplikacje wykorzystujące przeglądarkę są w zasięgu ręki, ponieważ produkty tożsamości od dostawców, takich jak Oracle, RSA, Novell i innych, są często związane z kodem po stronie serwerowej.

Projekty federacji w ramach organizacji stają przed jeszcze jednym dużym wyzwaniem: wymuszają zrobienie porządku w infrastrukturze. Pierwszym krokiem jest jej scalenie. Często bowiem w przedsiębiorstwie istnieje trudna do zidentyfikowania liczba źródeł tożsamości, identyfikatorów użytkowników, haseł (często kilka nawet w ramach pojedynczego środowiska). Istnieją również różne usługi katalogowe.


TOP 200