Například univerzity tak mohou vzájemně pouštět ke svým materiálům studenty a zaměstnance spolupracujících organizací.
Shibboleth vychází z předpokladu, že každý uživatel má určitou domácí instituci, a ta provozuje autentizační služby, například v podobě LDAP serveru. Cílem je, aby uživatel byl autentizován u svého domácího systému, přestože projevil zájem o stránky umístěné někde jinde. Prostředky provádějící vlastní ověření uživatele a poskytující informace o něm jsou zde označovány termínem poskytovatel identity (Identity Provider, IdP).
Druhým významným účastníkem komunikace je poskytovatel služeb (Service Provider, SP). Tento pojem označuje WWW server, o jehož chráněné stránky uživatel projevil zájem. Shibboleth definuje postupy a poskytuje softwarové nástroje, jak ověřit uživatelovo přístupové právo pro cílové stránky.
Zároveň řeší i otázku soukromí. Ve valné většině případů totiž poskytovatel služeb nepotřebuje znát konkrétní identitu přicházejícího uživatele. Mnohdy stačí daleko obecnější informace typu „ano, to je náš uživatel“ či „studuje u nás mineralogii“. Proto Shibboleth omezuje sortiment informací podávaných poskytovatelům služeb a dokonce umožňuje uživatelům, aby si individuálně nastavili, co o nich smí prozradit.
Technologickým základem Shibbolethu je Security Assertion Markup Language (SAML). Vzhledem k tomu, že Shibboleth řeší jen autentizaci WWW služeb, využívá z něj pouze vybranou podmnožinu, konkrétně profily Browser/POST a Browser/Artifact určené pro tento účel.
Základní myšlenkou je, že při prvním pokusu o přístup ke chráněným stránkám je uživatel automaticky přesměrován na svého poskytovatele identity. Zde prokáže svou totožnost a vrátí se zpět na původní server. Detaily se poněkud liší v závislosti na profilu. Pro Browser/POST vypadá komunikace následovně:
Transakce začíná požadavkem (1) na určité stránky (cílový zdroj). Pokud poskytovatel služeb uživatele dosud nezná, bude odpovědí WWW serveru přesměrování (2) vedoucí na poskytovatele identity. Lokátor tohoto přesměrování v sobě obsahuje informace o poskytovateli služeb, požadované stránce i adresu, kam se má uživatel vrátit s odpovědí.
Uživatelův klient se proto obrátí na svého domácího poskytovatele identity (3), který ověří jeho totožnost. Pokud se na něj již daný klient nedávno obracel (po přesměrování z jiného serveru), pravděpodobně už tu má vytvořen bezpečnostní kontext, který bude využit i tentokrát. Odtud přístup Single Sign-On: jednou se prokážete a následně se tato informace automaticky využije, aniž byste museli opakovat své uživatelské jméno a heslo. Výsledkem činnosti poskytovatele identity je WWW stránka (4) s formulářem, který ve skrytých položkách obsahuje informace pro poskytovatele služeb – identifikaci zdroje a SAML odpověď s výsledkem autentizace.
Cílová adresa, jež má zajistit zpracování formuláře, se nachází opět u poskytovatele služeb. Konkrétně se jedná o jeho službu vyhodnocující autentizační informace (Assertion Consumer Service). Doporučuje se, aby odeslání formuláře (5) zajistil automaticky JavaScript ihned po načtení stránky a uživatel měl život co nejpohodlnější. Když poskytovatel služeb z dat uvedených ve formuláři vidí, že autentizace dopadla úspěšně, vytvoří bezpečnostní kontext (identifikovaný prostřednictvím cookie) a přesměruje (6) uživatele na původně požadovaný zdroj.
Klient proto v kroku (7) zopakuje svůj původní požadavek (1), tentokrát však již opatřený cookie odkazujícím se na bezpečnostní kontext. Proto mu bude požadovaná stránka poskytnuta (8). Bude-li požadovat další stránky stejné aplikace, má už k dispozici cookie, a dostane je proto rovnou. Celá operace tedy proběhne jen jednou, když poprvé vstupuje do určitého chráněného prostoru.
Schéma Browser/Artifact je o něco složitější. První tři kroky jsou stejné, poskytovatel identity ale nepředá klientovi celou SAML odpověď. Pouze identifikátor (artefakt), jehož prostřednictvím je možné ji získat. Jeho reakcí je tentokrát přesměrování, které klienta pošle zpět k poskytovateli služeb a v URL nese potřebný artefakt. Assertion Consumer Service pak kontaktuje přímo poskytovatele identity a vyžádá si SAML odpověď identifikovanou artefaktem. Závěr je stejný – pokud vše dobře dopadne, vytvoří se bezpečnostní kontext a uživatel je přesměrován na původní stránku.
Toto schéma je vhodné pro paranoidnější poskytovatele služeb, protože si SAML odpověď získají sami, nikoli prostřednictvím uživatelova klienta. Jistě netřeba dodávat, že SAML odpověď je opatřena digitálním podpisem ručícím za její pravost a všeobecně je značná pozornost věnována zabezpečení veškerých procedur.
Popsané základní schéma ale dostačuje jen v případě, kdy poskytovatel služeb pouští dovnitř všechny uživatele daného poskytovatele identity. SAML odpověď totiž v podstatě jen říká „potvrzujeme, že je to náš uživatel“. Nesděluje který, ani o něm neposkytuje žádné podrobnější informace. Pokud je poskytovatel služeb potřebuje, musí si požádat o atributy – například jaký je uživatelův vztah k organizaci (zaměstnanec/student/…) či který obor studuje. Uživatel je přitom identifikován dočasně přiděleným kódem, poskytovatel služeb se nedozví jeho totožnost (pokud to nemá dovoleno). Zjištění a vyhodnocení atributů má na starosti Assertion Consumer Service. Při profilu Browser/Artifact k tomu využije své spojení s poskytovatelem identity, při Browser/POST si je musí navázat.
Další možnou komplikací je, že poskytovatel služeb nemusí vědět, odkud uživatel pochází, a na kterého poskytovatele identit se tudíž obrátit. Proto vstupuje do hry další prvek nazvaný WAYF (Where Are You From). Ve druhém kroku uživatel není odkázán na konkrétního poskytovatele identity, ale na obecnou službu WAYF. Ta nějak zjistí, kam uživatel patří (typické řešení: předloží mu formulář s nabídkou spolupracujících institucí a uživatel si sám vybere, informace se do budoucna opět uloží do cookie, aby se dotaz neopakoval), a přesměruje jej na patřičného poskytovatele identity. Díky tomu není nutné, aby všichni poskytovatelé služeb znali všechny poskytovatele identit. Stačí, když se všichni budou odkazovat na společnou WAYF službu.
Shibboleth je určen pro kooperativní prostředí, kdy se instituce sdružují a sdílejí prostředky i politiky přístupu k nim. Takováto skupina institucí je označována jako federace. Je také třeba, aby struktura atributů nesoucích informace o uživatelích byla jednotná. Shibboleth pro tento účel používá definici eduPerson, jež je rozšířením standardní třídy inetOrgPerson pro LDAP definované v RFC 2798. Rozšíření se týká především atributů potřebných pro vzdělávací instituce a také pro vzdálené ověřování.
Vedle obecné koncepce však Shibboleth představuje i konkrétní sadu programů, které jej implementují. Jsou k dispozici balíčky pro poskytovatele identit i poskytovatele služeb, a to pro různé operační systémy. Najdete je i s podrobnou dokumentací na stránkách projektu. Má sice americký původ, ale v současnosti již začíná vystrkovat prstíčky do Evropy a uvažuje se o jeho zavedení pro spolupráci mezi univerzitami starého kontinentu.
