Základní motivací pro vznik mobility je umožnit uživateli z nějaké organizace A zcela transparentní přístup do sítě v organizaci B, která musí pochopitelně participovat na roamingu. Tento princip lze zobecnit na umožnění přístupu uživatelů k síti prakticky odkudkoli. Mobilita je nejvíce patrná na příkladu bezdrátových sítí WiFi, je ovšem třeba si uvědomit, že nejde jen o bezdrátové sítě, ale také o přístup k běžným kabelovým sítím nebo třeba k počítačům v terminálových halách. Uživatel bude zkrátka disponovat jedinou identitou (ověřovací údaje budou uchovány v jeho domácí instituci), která jej bude opravňovat k přístupu ke všem participujícím sítím. Vize do budoucna dokonce předpokládají, že budou uživatelé používat jednotný autentizační mechanizmus ke všem službám sítě (mail, www, přihlášení k síti, ...). Tomuto systému se říká SSO (Single Sign On).

Koordinací roamingu v rámci české sítě národního výzkumu (NREN - National Research and Education Network) se ujala společnost CESNET, která je současně provozovatelem této sítě. Pro označení roamingového systému byl zvolen termín eduroam, kterým by měly být v budoucnu označeny všechny spolupracující sítě. Je to také vhodné vodítko pro uživatele. Pokud někdo uvidí na webových stránkách nějaké organizace, na zdi počítačové učebny nebo na pracovní ploše terminálu logo eduroam (obr. 1), je mu hned jasné, že se může připojit v rámci roamingu. Rovněž pro SSID (identifikátor radiové sítě) se počítá s použitím termínu eduroam nebo nějaké jeho derivace.

Označení eduroam pro roamingový systém jsme převzali na základě doporučení TERENA Mobility-TF, což je pracovní skupina zabývající se koordinací roamingu mezi jednotlivými NREN v celoevropském měřítku. Logo bylo vytvořeno Pavlem Satrapou. Jsou k dispozici různé velikosti a formáty.

Klíčovou roli v roamingovém systému hraje autentizační a autorizační infrastruktura (AAI), do které jsou napojeny všechny lokální autentizační systémy spolupracujících organizací. AAI musí zajistit především výměnu ověřovacích údajů o uživatelích, a to za dodržení přísných bezpečnostních kritérií. Uživatel v síti vystupuje s jedinou identitou a ověřovací údaje jsou uchovány v autentizačním systému domovské organizace. Pokud se tento uživatel tedy bude chtít připojit do jiné (tzv. hostující) sítě, musí si tato vyžádat jeho ověření v domácí síti. Tento přenos autentizačních údajů zajistí právě AAI.

Vybudování univerzální a dostatečně zabezpečené AAI je však složitý a časově náročný úkol. Pro potřeby mobility a roamingu byly pracovní skupinou TERENA Mobility-TF nadefinovány modelové autentizační mechanizmy (802.1x, VPN, web - jsou popsány dále) a roli AAI sehrává hierarchická struktura RADIUS serverů. Tento systém sice není dostatečně obecný (limitující je především použití protokolu RADIUS), ale pro účely mobility zcela postačuje.

Autentizace pomocí 802.1x je založena na schopnosti přístupového zařízení (AP nebo switch) ovládat provoz na L2 úrovni. Klient se připojí na port zařízení (u AP virtuální, u switche fyzický), tento port je ve stavu “zavřeno”. Je povolen pouze autentizační protokol EAP. Speciální program (suplikant), běžící na straně klienta, zahájí ověření přes EAP protokol. Suplikant vyšle na AP žádost o autentizaci, AP naváže spojení na RADIUS server a zprostředkuje ověření suplikantu vůči RADIUSu. Pokud je uživatel lokální, proběhne ověření přímo na RADIUS serveru, se kterým komunikuje AP. Pokud jde o návštěvníka, bude autentizační požadavek transportován přes strukturu RADIUS serverů až na domácí síť uživatele (detaily níže). Tento mechanizmus je zachycen na obrázku 2.

O výsledku (přístup povolen/zamítnut) informuje RADIUS server přímo AP, ten v závislosti na odpovědi povolí či zakáže provoz na daném portu. Tento mechanizmus pracuje na druhé síťové vrstvě a umožňuje kromě prostého otevření/zavření portu také jeho přepnutí do určité VLANy. V závislosti na ověřovacích údajích pak může klient dostat přístup např. do zaměstnanecké sítě, do sítě pro hosty nebo na Internet.

Základní myšlenka autentizace pomocí VPN tunelů spočívá v tom, že pokud se uživateli podaří připojit na VPN koncentrátor, musel se ověřit a je tudíž skutečně tím, za kterého se vydává. Problém ověření je v této metodě přesunut na VPN brány (viz. Obr. 3). Koncepce počítá s tím, že je hostující síť chráněna firewallem a ten povolí přístup pouze na definovanou množinu VPN bran (co spolupracující organizace, to jedna brána). Uživatel připojený do sítě tedy musí navázat VPN spojení do své domácí sítě, jinak se nikam nedostane.

Potenciální nevýhoda této metody spočívá v neoptimálním datovém toku (př.: Uživatel přijede do instituce A a chce využívat její síťové služby. Pakety však putují od něj k jeho domácí síti a zpět. Toto může činit problémy např. u IP telefonie, kdy je každé zpoždění kritické). Další komplikací je správa filtrovacích tabulek. Aby tento systém fungoval, musí být povolen přístup na VPN bránu každé spolupracující organizace. Pokud by nebylo přidělování IP adres pro VPN koncentrátory koordinováno, došlo by k zahlcení filtrovacích tabulek a neskutečnému chaosu. Řešením je mít jednotný adresový prostor pro VPN brány. Potom stačí na firewallech povolit pro každou zemi jeden agregovaný IP blok. V ČR je pro tyto účely vyčleněn segment IP adres z rozsahu CESNETu. Každé instituci se pak na základě žádosti přidělí adresa z této množiny. Protiváhou těmto nevýhodám je ovšem velmi vysoká míra bezpečnosti.

Ověření přes webové rozhraní je založeno na tom, že hostující síť je chráněna přístupovým prvkem (firewall), který neautentizovanému uživateli (na základě IP a MAC adresy) povolí pouze přístup http protokolem na autentizační stránku. Ostatní provoz je zakázán a všechny www dotazy jsou přesměrovány na přístupový prvek. Zde je uživatel vyzván k zadání svého jména a hesla. Poté, co jsou tyto údaje zkontrolovány na AAA serveru (ten může a měl by být součástí centrální AAI), je na firewallu přístup uživatele do sítě odblokován.

Nevýhodou tohoto způsobu je poněkud nižší míra bezpečnosti než u VPN nebo 802.1x řešení. Na druhou stranu web autentizace nevyžaduje na straně klienta žádný speciální software ani žádné speciální nastavení. Je proto vhodný jako prostředek “poslední záchrany”. Pokud se uživateli nepodaří připojit pomocí 802.1x nebo VPN, spustit prohlížeč a napsat jméno s heslem by neměl být problém. Rovněž se tímto způsobem dají s výhodou řešit přístupy uživatelů, kteří na roamingu nespolupracují (nemají se kde ověřit, protože nejsou uživateli žádné organizace zapojené v centrální AAI). Pro tyto případy se nadefinuje dočasný účet, který použijí externí uživatelé pro připojení. Schéma funkce viz. Obr. 4.

Při ověřování na bázi 802.1x a webu sehraje roli AAI hierarchická struktura RADIUS serverů (obr. 5). Každá instituce spolupracující na roamingu bude mít svůj RADIUS server, který dokáže ověřit uživatele z této instituce. Tyto uživatelské účty mohou být vedeny buďto přímo na RADIUS serveru, nebo na jiné platformě (LDAP, SQL, ...) a RADIUS použít pouze jako rozhraní. Tyto “organizační” RADIUS servery budou v rámci dané země propojeny k “národnímu” RADIUSu, který zajistí předávání požadavků na ověřování mezi institucemi. Tento server pro ČR je v současné době v provozu a jeho chod zajišťuje CESNET. Směrování ověřovacích požadavků mezi servery je založeno na koncepci tzv. realmů (viz. Definice RADIUS protokolu - RFC 2138). Uživatelské jméno má pak tvar uname@realm. Realm může být libovolný řetězec, ale z praktických důvodů se volí stejný jako doménové jméno instituce. Příklad kompletního uživatelského jména uživatele z CESNETu pak může být furman@cesnet.cz. Národní RADIUS server je tedy zkonfigurován tak, aby dokázal zpracovat/přesměrovat všechny dotazy na realm “.cz”. Podle zbývající části (v našem příkladu “cesnet”) určí, na který organizační RADIUS server bude požadavek směrován. Tato koncepce je defacto neomezeně škálovatelná, takže i v rámci jedné organizace může být více “podrealmů”.

Analogicky k národnímu existuje i tzv. top-level RADIUS server, na který jsou napojeny národní RADIUSy jednotlivých zemí. Tento server provozuje společnost SURFNet (operátor holandské NREN).

Z důvodu nepříliš kvalitního zabezpečení protokolu RADIUS je velmi doporučováno dodatečně zapouzdřit spojení mezi jednotlivými RADIUS servery do IPSec tunelu.

Mobilní přístup k sítím by měl být pro uživatele maximálně jednoduchý a transparentní. V ideálním případě by uživatel neměl poznat rozdíl mezi navštívenou a domácí sítí. V praxi tomu ovšem tak nebude (alespoň zpočátku jistě ne). Uživatel by si měl tudíž před každou cestou důkladně prostudovat informace o síti, do níž se chystá. Zejména pak použité ssid a autentizační mechanizmy. Tyto informace zpřístupní každá organizace participující na roamingu na speciálních webových stránkách, které budou odkazovány z centrálního mobility portálu, který provozuje CESNET, a měly by obsahovat minimálně:

• Kontaktní informace na lokální správce
• Použité ssid a autentizační mechanizmy
• Název, adresu a odkaz na oficiální stránky instituce

Zpřístupnění a sdílení informací je pro fungování roamingu skutečně klíčové. Je potřeba mít na paměti, že podmínky pro přístup k síti se v různých institucích velmi silně odlišují (např. v závislosti na použitém HW). Není tudíž možné mít všechny sítě zkonfigurovány stejně, informace o lokálním technickém nastavení je proto pro potencionálního návštěvníka naprosto nezbytná.

Technické komplikace také způsobuje fakt, že současné AP (access pointy) dovedou vysílat pouze jedno ssid (ostatní nejsou vidět - tato nepříjemnost by se měla v budoucnu odstranit). Pro efektivní použití všech tří autentizačních mechanizmů je potřeba použít alespoň dvě ssid (jedno na 802.1x a druhé na VPN a webové autentizaci). Uživatel tedy uvidí jen ssid, na kterém je poskytován preferovaný typ autentizace na dané instituci (typicky ssid=”eduroam” a autentizace přes 802.1x). Pokud se ovšem uživatel bude chtít ověřit jiným způsobem, nezbude mu než si ssid nastavit ručně. Preferovaný tvar druhého ssid by měl rovněž obsahovat slovo eduroam (např. eduroam-simple, eduroam-VPN, ...). Vlastní připojení k síti by již nemělo činit problémy a v závislosti na typu ověření by mělo vypadat takto:

Uživatel zapne suplikant, kde vyplní své uživatelské jméno ve tvaru user@realm, své heslo a po ověření se dostane k síti.

Uživatel spustí VPN tunel ke svému domovskému koncentrátoru, který má adresu z definovaného bloku a tudíž povolenou na lokálním firewallu. Pokud se mu podaří připojení ke koncentrátoru, znamená to, že je ověřen a může přistupovat do sítě (dostane se tunelem do své domovské sítě).

Po připojení k síti se uživatel nedostane jinam, než na ověřovací stránku, kde vyplní jméno a heslo. Pokud bude ověřen, odblokuje se na firewallu jeho IP a MAC adresa a on může do sítě.

— Jan Tomášek 13.06.2006 20:31 doplněno varování o plánovaném ukončení eduroam-simple
— Jan Furman 16.07.2004 dokument byl vytvořen