Problemy nie tylko w technologii

Sfederowane systemy tożsamości zapewniają sposób używania jednej tożsamości w wielu systemach i usługach. Jednak z wdrożeniami takich systemów wiąże się wiele problemów spoza sfery technologii. Trudną sprawą 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, a także powszechnie akceptowanych wzorców porozumień. W wielu wypadkach któryś z udziałowców wykonuje 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 czyni strukturalizowanie takiej federacji procesem łatwym 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 helpdesku z powodu utraty hasła. Ponadto federacja tworzy wartość dodaną dla klientów firmy, zwiększając ich wygodę i redukując problemy bezpieczeństwa. Tego rodzaju korzyści są siłą napędową federacji.

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. To wymaga 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 np. 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.

Trudne elementy federacji

Oprócz zarządzania istnieją jeszcze inne aspekty, które należy uwzględnić: sprawy biznesowe, odpowiedzialność, ochrona prywatności i bezpieczeństwo.

Sprawy biznesowe obejmują szczegóły dotyczące tego kto i co wykonuje, kto ponosi poszczególne koszty oraz jaki jest podział zysków. Większość z tych spraw jest prosta i zazwyczaj zawarta w istniejących porozumieniach biznesowych.

Odpowiedzialność jest jednak problemem trudniejszym. W sprawach odpowiedzialności musi dojść ostatecznie do wspólnych ustaleń stron zmierzających do federacji. Podstawą jest ocena ryzyka w kontekście spodziewanych korzyści.

Nie istnieją zestawy formuł oceny takiego ryzyka. Jest to zazwyczaj oceniane ad hoc, w zależności od natury aplikacji, a także od tego, jak rozległe może być ryzyko.

W rozwiązaniu problemów związanych z odpowiedzialnością może pomóc audyt. Można go wykonać we własnym zakresie lub zdać się na audytora zewnętrznego. Audyt pozwala przekonać się o tym, czy partner może zapewnić bezpieczeństwo również nie swoim danym. Bardzo istotny jest fakt, aby partnerzy spełniali te same standardy bezpieczeństwa.

Ochrona prywatności czasami wymaga zmian w projektach IT, ale nie można jej ignorować w przypadku federacji. Wiele modeli federacji obejmuje coś więcej, niż tylko zwykłe uwierzytelnianie. Strona identyfikująca może zapewniać, w zależności od aplikacji, dane osobowe dla partnera federacji, obejmujące takie elementy, jak numer identyfikacyjny, data urodzenia, a nawet informacje o kartach kredytowych.

W wielu wypadkach używanie tych danych jest regulowane obowiązującymi powszechnie przepisami. Dotyczy to zwłaszcza danych finansowych czy osobowych. W wielu innych przypadkach może być konieczne zapewnienie ochrony danych o klientach w specyficzny sposób - federacja wymaga takich samych procedur ochronnych u wszystkich udziałowców.

Znaczenie reguł polityki

Ostatecznym celem federacji jest umożliwienie współdziałania zdecentralizowanego i rozproszonego systemu tożsamości w taki sposób, który zapewnia niezbędne mechanizmy obsługujące współczesne praktyki biznesowe. Wprowadzając do organizacji tożsamość federacyjną, konieczne jest poświęcenie należytej uwagi protokołom i regułom polityki.

Ważne jest też, aby wybierając konkurencyjne standardy federacji wyraźnie określić, których będzie się używać, a których nie. Takie wybory powinny być zapisane w specjalnych regułach polityki nazywanych IF (Interoperability Framework). Takie IF to nic innego, jak lista wyjaśniająca jakiego wyboru dokonała organizacja. Określa ona, które standardy są wymagalne, a które opcjonalne. Może także określać, które standardy są obsługiwane, ale nie powinny być używane w nowych wdrożeniach.

Ponieważ unifikacja będzie obejmować partnerów zewnętrznych, którzy już mogli dokonać innych wyborów, IF powinna charakteryzować się elastycznością, zapewniającą łatwe sposoby uwzględnienia wyjątków. Wyraźną korzyścią, jaką daje IF, jest możliwość uniknięcia stosowania specyficznych standardów, które mogą powodować szybką dezaktualizację projektu, gdy takie standardy ulegają zmianie.

Poza standardami technicznymi, które są krytyczne dla współdziałania, inne ważne reguły rządzą tym, jak biznes używa, kontroluje i ochrania dane związane z tożsamością. Reguły federacji powinny obejmować sposób ustanawiania obszaru zaufania z partnerem, specyfikować, jakie oceny są niezbędne oraz jak chronione będą dane.

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 (zwaną "dostawcą tożsamości"), a ośrodkiem, który polega na tym uwierzytelnieniu i zapewnia bezpieczny dostęp do aplikacji lub usługi (zwanym "dostawcą usługi"). Brama federacyjna eliminuje potrzebę używania tego samego protokołu i wersji sfederowanego zarządzania tożsamością u dostawców 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ące od wielu dostawców tożsamości. Firma A działa jako "dostawca usług" używający protokołu SAML 1.1 dla oferowania partnerom sfederowanego dostępu do swoich aplikacji webowych. Trzy firmy partnerskie - B, C i D - żądające dostępu do aplikacji firmy A działają jako "dostawcy tożsamości". Wszystkie trzy używają różnych protokołów, odpowiednio: SAML 2.0

Liberty 1.1 i Liberty 1.2.

Brama federacyjna pozwala na współdziałanie systemu zarządzania tożsamością federacyjną firmy A z systemami sfederowanej tożsamości firm B, C i D, ponieważ transluje asercje SAML 2.0, Liberty 1.1 i Liberty 1.2 na SAML 1.1, zanim prześle je do aplikacji firmy A. Natomiast w odwrotnym kierunku przedstawia się każdemu z dostawców tożsamości, używając jego protokołu zarządzania sfederowaną tożsamością. W przykładzie: brama federacyjna z firmą B rozmawia poprzez protokół SAML 2.0 z firmą C - Liberty 1.1, a z firmą D za pomocą protokołu Liberty 1.2.

Brama federacyjna pracuje w następujący sposób: jeżeli autoryzowany użytkownik z firmy C żąda dostępu do zabezpieczonej aplikacji w ośrodku A, system zarządzania sfederowaną tożsamością firmy C kieruje użytkownika, który ma asercje uwierzytelniania Liberty 1.1, do bramy federacyjnej zlokalizowanej w firmie A. Brama federacyjna weryfikuje asercje dostarczone przez zaufanego partnera i tworzy asercje SAML 1.1. Po otrzymaniu z bramy federacyjnej i zweryfikowaniu asercji SAML 1.1, firma A pozwala użytkownikowi firmy C na dostęp do żądanej aplikacji bez proszenia go o podanie identyfikatora i hasła.

Punkt startowy

Wewnętrzne projekty SSO (Single Sign-On) są dobrym punktem startowym dla tworzenia tożsamości federacyjnej, ponieważ zapewniają wybór standardów i projektów bez nacisku ze strony zewnętrznych partnerów. Problemem jest, aby takie projekty nie stały się powodem decentralizacji usług katalogowych, ale raczej wykorzystywały technologie federacji.

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żą 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 WWW. Najprościej wdrożyć dostęp do aplikacji w ramach przedsiębiorstwa, wykorzystując techniki webowe. 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 kilku nawet w ramach pojedynczego środowiska. Istnieją również różne usługi katalogowe. Wykonanie federacji w ramach przedsiębiorstwa jest więc krokiem niezbędnym przed wyjściem z nią poza zapory ogniowe.