Terminem "federacja" opisuje się scenariusze, 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 ramach stosunków biznesowych w zakresie uwierzytelniania swoich użytkowników. 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 polityki definiowanym przez własnych i zewnętrznych administratorów.

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

Scentralizowane systemy nie są w takich przypadkach możliwe do zastosowania. Organizacje muszą więc wybierać 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.

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 w uwierzytelnianiu swoich użytkowników i ręczą za ich tożsamość oraz uprawnienia dostępu.

Jako przykład można rozważyć firmę ubezpieczeniową, która chce udostępniać wycenę ubezpieczeń poprzez web services dla uprawnionych pracowników swoich partnerów. Jeżeli taka firma chciałaby utworzyć konto użytkownika dla każdego pracownika swojego partnera, to musiałaby utrzymywać bardzo dużą bazę danych użytkowników, co zwiększa koszty. Zdecydowanie bardziej efektywne jest rozwiązanie, w którym to pracodawca ręczy za swoich pracowników.

Standardy federacji tożsamości

Istnieje kilka standardów tożsamości federacyjnej, stosowanej w ramach różnych domen: Security Assertion Markup Language (SAML), Liberty Alliance 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.

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 federowania 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 i projekt Shibboleth.

SAML 2.0 ma duże znaczenie w dobie globalizacji, ponieważ wprowadza mechanizmy, takie jak łączenie kont, globalne logowanie, wymiana atrybutów prywatności. Brakuje mu natomiast odniesień do prac Microsoftu i IBM, które tworzą konkurencyjny protokół federacyjny o nazwie WS-Federation. Eksperci są zdania, że te dwa projekty ulegną z czasem konwergencji, ale na razie prace w tym kierunku zostały wstrzymane.

SAML jest strukturą 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. W szczególności SAML obsługuje:

asercje uwierzytelniania: zapewniające ewidencję wcześniejszych uwierzytelnień;

asercje atrybutów: listy wymaganych atrybutów użytkowników;

asercje uprawnień: autoryzujące użytkownika w zakresie dostępu do danego zasobu.

Podobny protokół, o nazwie WS-Federation, zaprojektował Microsoft przy współpracy z IBM, a jego implementacja została zawarta w Windows Server 2003 Release 2, które pojawiło się pod koniec 2005 r. Wielu dostawców - CA, Entrust, HP, IBM, Oracle, RSA i Sun - obstawia oba protokoły.

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, wtedy gdy do sfederowania tożsamości musi używać różnych zestawów protokołów. Dostawcy przewidują translatory pomiędzy tymi dwoma standardami, ale według Microsoftu mogą one wprowadzać problemy związane z bezpieczeństwem, ponieważ musi istnieć punkt pośredniczący, w którym dane są przetwarzane.

Problemy wdrażania systemów zunifikowanej tożsamości

Problemem przy tworzeniu sfederowanej tożsamości jest liczba różnych standardów: OASIS SAML Liberty Alliance ID-FF oraz Shibboleth.

OASIS, Liberty i Shibboleth podchodziły do zagadnienia federacji z trzech różnych perspektyw. SAML skupia się przede wszystkim na interakcjach biznes-biznes (SSO w ramach kooperujących organizacji), Liberty Alliance na interakcjach biznes-klient, a Shibboleth na środowiskach naukowych wymagających anonimowości. Wszystkie trzy organizacje: OASIS, Liberty Alliance i Shibboleth 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 tych wszystkich obszarów zastosowań, opracowując SAML 2.0.

SAML 2.0 zawiera wszystkie najważniejsze mechanizmy swoich poprzedników. Można go więc uznać za funkcjonalną sumę wszystkich pięciu specyfikacji. SAML 2.0 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.

W zakresie 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 odpowiada za zatwierdzenie asercji SAML przed otwarciem użytkownikowi dostępu do aplikacji.

Asercja SAML jest dokumentem XML zawierającym wiele informacji dotyczących tożsamości użytkownika. Obejmują one informacje o tym, jak użytkownik był uwierzytelniany oraz - opcjonalnie - dodatkowe atrybuty użytkownika.

Nowy protokół zlikwiduje konieczność wyboru protokołu sfederowania i wyeliminuje potrzebę uruchamiania skomplikowanych rozwiązań wieloprotokołowych.