Łączenie tożsamości w systemach rozproszonych

Firmy często utrzymują i przechowują informacje o użytkownikach (pracownikach, klientach, partnerach) w różnych bazach danych i katalogach. Z jednej strony takie bazy są krytycznymi komponentami infrastruktury zarządzania tożsamością w organizacji. Z drugiej - biznes musi opierać się na współpracy z innymi organizacjami.

Firmy często utrzymują i przechowują informacje o użytkownikach (pracownikach, klientach, partnerach) w różnych bazach danych i katalogach. Z jednej strony takie bazy są krytycznymi komponentami infrastruktury zarządzania tożsamością w organizacji. Z drugiej - biznes musi opierać się na współpracy z innymi organizacjami.

Scentralizowane systemy nie są w takich przypadkach możliwe do zastosowania. Firmy poszukujące sposobu udostępniania swoich zasobów partnerom biznesowym i ich pracownikom muszą przede wszystkim znaleźć sposób na "zjednoczenie" tożsamości należących do różnych organizacji użytkowników.

Organizacje mogą więc zdecydować się na podejście zdecentralizowane, określane jako "federated identity management". Systemy tożsamości federacyjnej łączą dwa lub więcej oddzielnych systemów zarządzania tożsamością w celu wykonywania wspólnych zadań uwierzytelniania i autoryzacji oraz współużytkowania atrybutów tożsamości.

Co to jest federated identity?

Łączenie tożsamości w systemach rozproszonych

Tożsamość federacyjna

Terminem "federacja" opisuje się sytuacje, w których żadna z organizacji tworzących grupę partnerską nie zarządza wszystkimi użytkownikami i zasobami w środowisku rozproszonych aplikacji. Administratorzy w różnych domenach muszą natomiast zarządzać lokalnie taką polityką bezpieczeństwa, która wspiera transakcje zachodzące pomiędzy ich sferami działania.

W świecie rozproszonych usług sieciowych termin ten określa zaufane relacje pomiędzy zdecentralizowanymi domenami ochrony i polityki. Federacja pozwala połączyć systemy tożsamości różnych organizacji, jednostek biznesowych, platform i aplikacji. Wymaga też, aby jedna organizacja zaufała innej w zakresie uwierzytelniania swoich użytkowników w ramach relacji biznesowych. W środowisku sfederowanym użytkownik może logować się we własnej domenie i uzyskiwać transparentny dostęp do zasobów w domenach zewnętrznych, takich jak domeny zarządzane przez partnerów, dostawców czy klientów, podlegające różnym regułom polityk definiowanym przez własnych i zewnętrznych administratorów.

Zarządzanie tożsamością federacyjną pozwala na używanie tej samej nazwy użytkownika, hasła i innych mechanizmów uwierzytelniania, do wykonania pojedynczej rejestracji w systemie i uzyskania dostępu do aplikacji i danych rezydujących w systemach komputerowych innych organizacji. Partnerzy w takim systemie zarządzania tożsamością zależą od siebie nawzajem przy uwierzytelnianiu swoich użytkowników i ręczą za ich tożsamość oraz uprawnienia dostępu.

Różne standardy federacji tożsamości

Istnieje kilka standardów tożsamości federacyjnej: Security Assertion Markup Language (SAML), Liberty Aliance i Web Services Federation Language (WS-Federation). Mogą być one używane do eliminowania konieczności powielania repozytoriów informacji o użytkownikach, pozwalając jednocześnie organizacjom mieszać produkty spełniające te standardy i pochodzące od różnych dostawców.

SAML umożliwia wydawanie referencji dotyczących uwierzytelniania i uprawnień, ważnych w ramach sfederowanych organizacji. Jest to struktura dla wymiany asercji XML w informacjach związanych z bezpieczeństwem, tak aby użytkownicy byli uwierzytelniani tylko raz, a inni uczestnicy mogli polegać tylko na tej informacji. SAML 2.0, zatwierdzona jako oficjalny standard w marcu 2005 r. przez OASIS (Organization for the Advancement of Structured Information Standards), jest de facto standardem fedrowania tożsamości, który pozwala różnym organizacjom na współużytkowanie danych dotyczących autoryzacji i uwierzytelniania poza granicami sieci korporacyjnej. Jest wspierany przez Liberty Alliance oraz projekt Shibboleth.

Podobny protokół o nazwie WS--Federation zaprojektował Microsoft przy współpracy z IBM, i pod koniec 2005 r. zaimplementował w Windows Server 2003 Release 2. Zestaw protokołów WS-Federation ma zapewnić pełny zakres standardów związanych z bezpieczeństwem, wiadomościami i transakcjami.

Protokoły WS-Federation konkurują ze specyfikacją SAML 2.0, która skupia się głównie na tworzeniu bezpiecznej, sfederowanej tożsamości w ramach różnych organizacji. Według Microsoftu WS-Federation jest lepiej dostosowana do radzenia sobie z rozproszonymi środowiskami Web Services w zakresie gwarantowanej wymiany wiadomości oraz obsługi i bezpieczeństwa transportu danych. SAML 2.0 nie zapewnia gwarantowanej wymiany wiadomości czy obsługi transportu.

Problem dla użytkownika powstaje wówczas, gdy do sfederowania tożsamości musi używać różnych zestawów protokołów. Dostawcy przewidują translatory pomiędzy wymienionymi dwoma standardami, ale mogą one stwarzać problemy związane z bezpieczeństwem, ponieważ musi istnieć punkt pośredniczący, w którym dane są przetwarzane.

Wielu dostawców - CA, Entrust, HP, IBM, Oracle, RSA czy Sun - stawia na oba protokoły.

Problemy wdrażania zunifikowanej tożsamości

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 leżących również poza sferą technologii.

Problemem technicznym przy tworzeniu sfederowanej tożsamości jest liczba różnych standardów.

OASIS, Liberty i Shibboleth podchodziły do zagadnienia federacji z trzech różnych perspektyw. SAML skupia się przede wszystkim na interakcjach biznes-biznes, Liberty Alliance na interakcjach biznes-klient, a Shibboleth na środowiskach naukowych wymagających anonimowości. Wszystkie trzy organizacje połączyły swoje wysiłki w celu utworzenia jednego standardu, zastępującego ich wcześniejsze dokonania w tym zakresie. Zmodyfikowano i rozszerzono specyfikację SAML w celu wsparcia wszystkich obszarów zastosowań, opracowując SAML 2.0.


TOP 200