Následující text velmi stručně popisuje federaci identit (zkráceně občas také: federaci) jako celek a věnuje se jejím výhodám pro uživatele, jejich organizace i provozovatele služeb. Každá mince má dvě strany, a tak se text věnuje i nevýhodám federace identit, které lze minimalizovat kvalitní dokumentací a technickou podporou.

Proces přihlášení ke každé aplikaci sestává ze dvou kroků, které je třeba postupně provést:

1. autentizace – ověření totožnosti uživatele (dochází k ověření správnosti hesla k zadanému uživatelskému jménu),
2. autorizace – rozhodnutí, zda ověřený uživatel má získat povolení k přístupu.

Bez federativního přihlašování musí každá aplikace řešit oba předchozí kroky. Musí tedy mít databázi uživatelů, kteří jsou oprávněni k přístupu. Zde je kladen velký důraz na správnou a bezpečnou implementaci ukládání uživatelských údajů a zejména hesel. Dále je potřeba řešení problému spojeného se zapomenutím hesla a jeho následným obnovením.

Uživatelé mají mít pro každou službu z důvodu bezpečnosti jiné heslo, mnohdy mají i jiné uživatelské jméno, což je v dnešní době s velkým množstvím různých služeb velmi náročné na zapamatování. Často proto dochází k použití jednoho hesla pro více služeb, což je bezpečnostní riziko v případě odcizení nebo uhádnutí hesla útočníkem.

Federované přihlašování přináší výhody jak koncovým uživatelům, tak provozovatelům služeb. Zároveň tento koncept zvyšuje celkovou bezpečnost pro obě strany.

Provozovatelé služeb nemusí řešit ukládání uživatelských informací a bezpečnou správu uživatelských hesel, se kterými nepřijdou ani do styku. Výhodou také je, že při případném zapomenutí hesla se uživatel obrací nikoliv na provozovatele služby, ale na svou domovskou organizaci. Správce služby navíc definuje, jaký typ uživatelů smí službu použít a o implementaci těchto pravidel se postarají samotné organizace uživatelů. Navíc veškeré uživatelské údaje, které služba obdrží, jsou vždy aktuální a uživatel (resp. jeho domovská organizace) je udržuje pouze na jednom místě.

Uživatelům stačí jedno přihlašovací jméno a heslo ke všem službám. Nemusí si pamatovat spousty různých hesel a k nim mnohdy rozdílné přihlašovací jméno. Zároveň vždy zadávají své přihlašovací údaje na důvěrně známé adrese – na webové stránce své domovské organizace. Uživatelské přihlašovací údaje tedy nikdy neopouští domovskou organizaci, takže např. napadená služba je nemůže získat z přihlašovacího formuláře. V případě kompromitace uživatelských přihlašovacích údajů, stačí provést změnu hesla anebo zablokování účtu na jednom místě a to v organizaci uživatele.

Připojení do federace identit s sebou nese i jisté nevýhody:

• technické zázemí,
• uživatelské atributy (a zejména jejich uvolňování).

Pod technickým zázemím pro provozovatele služeb máme na mysli software nazývaný poskytovatel služby (Service Provider, SP) jako např. Shibboleth SP nebo SimpleSAMLphp v konfiguraci SP, který zajišťuje vše potřebné, aby se uživatelé mohli hlásit ke službám.

Pod technickým zázemím pro organizace máme na mysli adresářový server s uživatelskými informacemi (buď LDAP anebo Active Directory), na který se napojí software označovaný jako poskytovatel identity (Identity Provider, IdP) jako např. Shibboleth IdP.

Dále je nutné, aby organizační IdP uvolňovalo službám potřebné uživatelské atributy (údaje jako jméno, příjmení, e-mailová adresa atd.), protože bez nich není možné na službě jednotlivé uživatele od sebe rozlišit a nabídnout tak uživatelské profily, historii hledání, ukládání dat atd.

Chce-li uživatel využít nějakou službu, jde na odpovídající adresu služby (krok 1). Tam se mu po zvolení přihlášení zobrazí „rozcestník“ WAYF (Where Are You From?) s výpisem organizací (krok 2), z něhož vybere svou domovskou organizaci a dojde k přesměrování na přihlašovací stránku dotyčné organizace (krok 3). Po zadání správného uživatelského jména a hesla je uživatel přesměrován zpět na službu jako přihlášený uživatel a může službu začít používat (krok 4).

Federace identit je složena primárně ze dvou druhů entit:

1. poskytovatelů služeb (Service Provider, SP),
2. poskytovatelů identit (Identity Provider, IdP).

SP nebo také jen služba je např. webové rozhraní pro přístup k elektronické poště, kalendáři, elektronickým zdrojům jako články, knihy atd.

IdP je v organizaci napojená na uživatelskou databázi (např. LDAP nebo AD), kde jsou o uživatelích uloženy informace (nazýváme je atributy) jako křestní jméno, příjmení, e-mailová adresa apod.

Každá organizace může mít ve federaci identit:

• žádné nebo jedno IdP,
• žádné nebo více SP.

Organizace tedy může poskytovat pouze služby jiným uživatelům, ale vlastní uživatele vůbec nemít (pouze jedno nebo více SP). Nebo může pouze zprostředkovávat svým uživatelům přístup ke službám jiných organizací (pouze jedno IdP). Třetí možností je, že organizace poskytuje své služby a zároveň zprostředkovává svým uživatelům přístup ke službám jiných organizací (jedno IdP a jedno nebo více SP).

Každá organizace smí mít ve federaci eduID.cz pouze jediné IdP – nemá smysl, aby jich bylo více a uživatelé z dané organizace museli přemýšlet, které IdP zvolit pro přihlášení ke konkrétní službě.

Federace identit může mít jednu ze dvou architektur:

1. Mesh,
2. Hub & Spoke.

Architektura Hub & Spoke lze dále rozdělit dle přihlášení:

1. distribuované,
2. centralizované.

Česká akademická federace identit eduID.cz používá architekturu mesh. Znamená to, že každá entita musí mít informace (tzv. metadata) o ostatních entitách ve federaci identit. Jelikož nemá smysl, aby mezi sebou komunikovaly entity stejného typu, stačí, aby SP měla informace o IdP a naopak, aby IdP měla informace o SP.

Jak funguje přihlášení pomocí federace identit si můžete vyzkoušet na portálu attributes.eduid.cz, který po úspěšném přihlášení vypíše seznam atributů a jejich hodnot, které obdržel od poskytovatele identit. Nemáte-li účet v žádné organizaci z české akademické federace identit eduID.cz, můžete vyzkoušet přihlášení pomocí účtu v tzv. Hostelu. To je poskytovatel identity, kde je možné si vytvořit účet. Účet v Hostelu je možné takzvaně ověřit a získat přístup k více službám. Uživatelům z organizací, které mají vlastní IdP ve federaci, silně nedoporučujeme používat Hostel právě kvůli nutnosti periodického ověřování účtu.