Možná jste již v médiích zaznamenali, že Barack Obama připustil rozsáhlé technické problémy své zdravotnické reformy. Jeden z architektů protokolu OpenID Connect John Bradley k tomu na svém blogu napsal krátké shrnutí, ve kterém tvrdí, že jednou z příčin těchto problémů je zvolený způsob implementace jednotného přihlašování na hlavním webu healthcare.gov.
Velké instituce, zejména ve státní správě (samozřejmě myšleno mimo ČR), nejdou úplně rychle z dobou a pro jednotné přihlašování (anglicky „single sign-on“) v rámci svých digitálních agend používají léta prověřený protokol SAML. Platí to jak pro připravovaný systém propojení evropských digitálních identit STORK, kterého se účastníme, tak i pro systémy federální vlády Spojených států. SAML je předchůdce OpenID a psal jsem o něm i na našem blogu.
Příčinou problémů je nestandardní použití jednoho atributu protokolu SAML. To způsobuje, že poskytovatelé služeb zdravotního pojištění, kteří se chtějí napojit na centrální systém, musí aktualizovat svoje systémy, aby se nestandardnímu chování přizpůsobili.
U nás v České republice, kde v digitalizaci státní správy teprve dobíháme vyspělejší státy, a kde jsem si také užili své při startu různých centrálních registrů, může tato situace vyvolat lehký posměch. Ani ve Spojených státech se spouštění velkých projektů neobejde bez komplikací. Na druhou stranu je třeba ocenit, že tyto vyspělejší státy sáhnou radši po prověřeném standardu, než aby vymýšlely vlastní proprietární řešení. V České republice vedle mojeID, které je již používáno i městy a obcemi, nabízí jednotné přihlašování i systém datových schránek. Ten se však vydal cestou vlastního technického řešení a zatím jej využívá jen jeden subjekt.
Jaromír Talíř
Doménový prohlížeč – vaše okno do registru domén
Minulý týden jsme představili novou službu nazvanou Doménový prohlížeč. Formát tiskové zprávy, kterou jsme k tomu vydali, pochopitelně neumožňuje příliš se rozpovídat o vlastnostech této služby. Proto bychom rádi tiskovou zprávu doplnili tímto blogpostem, ve kterém Doménový prohlížeč popíši trochu podrobněji. Funkce této služby bych rozdělil na tři části. První část tvoří osobní WHOIS, druhou částí je editor údajů kontaktu souvisejících s registrem a třetí částí jsou bezpečnostní zámky na objektech v registru.
Doménový prohlížeč jako osobní WHOIS
Služba WHOIS je standardní součástí snad všech doménových registrů a v našem podání umožňuje veřejnosti nahlédnout do údajů o doménách, kontaktech, sadách jmenných serverů a sadách DNSSEC klíčů, které v registru evidujeme. Chce-li nějaký držitel zobrazit seznam všech svých domén, musí se obvykle přihlásit do systému svého registrátora a tam své domény uvidí. Situace se ale komplikuje, pokud z nějakého důvodu jsou domény zaregistrovány přes více registrátorů. A tady právě může pomoci Doménový prohlížeč.
K vyřešení problému je ale nutné jednoznačně identifikovat a autentizovat příslušný kontakt držitele v doménovém registru. Tuto možnost jsme v registru dlouho neměli. Nyní ale máme mojeID, jehož podstatnou vlastností je jeho propojení s doménovým registrem. MojeID tak vlastně kontaktům v registru přiřazuje autentizační údaje. Bez mojeID by tedy Doménový prohlížeč nemohl fungovat. Díky tomuto propojení můžeme uživateli zobrazit nejen všechny domény, kde je držitelem, ale také domény, kde je administrativním kontaktem, nebo sady jmenných serverů a sady klíčů, kde je technickým kontaktem. Další důležitou vlastností Doménového prohlížeče je, že u těchto sad jmenných serverů a sad klíčů si jejich správce může zobrazit všechny domény, které na ně jsou navázány a například pomocí toho ověřit, zda má správně nakonfigurované své jmenné servery. V seznamu domén hraje klíčovou roli sloupeček „Následující stav“, podle kterého jsou domény standardně setříděny a který ukazuje, co se v nejbližší době stane s doménami. Díky tomu je možné na první pohled vidět, které domény vyžadují držitelovu pozornost, protože mohou být deaktivovány nebo dokonce zrušeny.
Z uživatelského pohledu aplikace obsahuje standardní sadu ovládacích prvků. Seznamy objektů je možné libovolně třídit, stránkovat s volitelným počtem objektů na stránku a filtrovat přes zvolený podřetězec v názvu objektu. Pokud uživatel požaduje zobrazení velkého množství objektů, standardně se jich zobrazí jenom prvních několik tisíc. Pokud chce držitel získat všechny objekty, musí použít funkci exportu do CSV formátu, což je textový tabulkový formát. V rámci implementace uživatelského prostředí jsme se snažili o dodržení techniky „responsive design“, a tak by neměl být problém používat Doménový prohlížeč na tabletech a chytrých telefonech.
Doménový prohlížeč jako editor kontaktu
Spuštěním služby mojeID jsme se stali de-facto registrátorem některých kontaktů v doménovém registru a proto jsme v editoru profilu mojeID museli nabídnout plnou funkcionalitu, kterou každý registrátor u kontaktu umožňuje. Kromě přirozené správy osobních údajů to je také možnost změnit si heslo pro převod kontaktu k jinému registrátorovi (tzv. auth info) a možnost nastavit si příznaky zveřejňování údajů kontaktu ve službě WHOIS. Vzhledem k tomu, že mojeID po startu získalo mnohem větší popularitu mezi uživateli, kteří nejsou zároveň držitelé domén, setkávali jsme se často se složitým vysvětlováním, k čemu jsou tyto údaje dobré a proč je mají nastavovat. Rozhodli jsme se nakonec tuto situaci řešit odebráním těchto údajů z editoru profilu mojeID a vložili jsme je právě do doménového prohlížeče. Ten je primárně určen pro uživatele, kteří mají vztah k doménovému registru a význam těchto údajů znají. V záložce „Můj kontakt“ tedy uživatelé najdou kromě zobrazení údajů kontaktu také možnost zobrazit nebo změnit tyto dvě skupiny údajů. Změna hesla pro převod kontaktu má přirozeně smysl pouze pokud by uživatel již nechtěl mojeID používat a rozhodl se přejít znovu k jinému registrátorovi. Je zde jedno podstatné omezení, které ale platilo i v editoru profilu mojeID. Tyto údaje může měnit pouze uživatel, který je plně ověřen zasláním dopisu na jeho adresu. Pokud uživatel požaduje změnu i ostatních údajů, dostane se jednoduše přes tlačítko „Upravit osobní údaje“ do editoru profilu mojeID a tam může změnu provést.
Doménový prohlížeč jako rozhraní k blokacím a ke zjištění hesla pro převod objektů
Přestože primárním místem pro řešení problémů s doménami jsou registrátoři, vždy existovali požadavky, se kterými bylo nutné se obrátit přímo na nás jako správce doménového registru. Prvním problémem, který s námi držitelé domén řeší, je převod domény k jinému registrátorovi. K jeho provedení je nutné znát heslo, které by mělo být možné zjistit z rozhraní stávajícího registrátora. Je ale možné, že stávající registrátor se bude chtít odchodu zákazníka bránit a toto heslo držiteli neprozradí. V takovém případě se pak vždy mohl držitel obrátit na nás a my jsme mu heslo poskytli. Druhým typem žádosti, a zároveň jednou z prvních změn, které jsme v roce 2007 při spuštění domového registru implementovali na žádost uživatelů, je zablokování domén proti změnám. Přestože registrátoři mají v podmínkách uvedeno, že změny u domén mohou dělat pouze se souhlasem držitele nebo administrativního kontaktu, může dojít k porušení tohoto pravidla. Nemusí se jednat vyloženě o zlý úmysl registrátora, například může být jeho systém napaden. Proto jsme v doménového registru umožnili držitelům domén požádat buď o zablokování převodu k jinému registrátorovi nebo o zablokování všech změn nad doménou. Tato žádost je opět zasílána přímo k nám do registru a nikoliv prostřednictvím registrátora.
Pro řešení těchto problémů máme na našich webových stránkách formulář, kde je možné žádost vyplnit a zaslat. Pro její zpracování je ale nutné přirozeně odesílatele žádosti nějak autentizovat. K tomu jsme vždy používali dvě možnosti a to buď opatření žádosti notářsky ověřeným podpisem a její zaslání v papírové podobě, nebo zaslání žádosti emailem podepsaným digitálním podpisem. A zde opět přichází na scénu výhoda propojení mojeID a doménového registru. Kromě autentizačních údajů, pomocí kterých se může držitel vůči nám identifikovat a o kterých jsem psal výše, obsahuje služba mojeID také kontrolu údajů na srovnatelné úrovni jakou poskytne notář nebo certifikační autorita. Pokud tedy držitel splňuje podmínku nejvyššího stupně ověření, není důvod nutit ho k složitému ověřování znovu při každé žádosti přes webový formulář. Proto jsme do Doménového prohlížeče vložili takto ověřeným uživatelům i možnost provádět tyto žádosti online. Blokováni a odblokání domén je dokonce možné provádět hromadně nad více objekty.
Budoucnost
Doménový prohlížeč vnímáme jako rozhraní držitelů domén k doménovému registru a tato skutečnost nabízí velký potenciál pro jeho rozšiřování do budoucna. Rád bych zmínil některé myšlenky, které nás při těchto úvahách napadají:
- Zobrazování historie objektů – Pravidla registrace již nějaký čas umožňují oprávněným žadatelům zobrazit historii nějaké domény. Doménový prohlížeč by se tedy mohl rozšířit o historická data.
- Zobrazování komunikace s uživatelem – V průběhu života domény zasíláme držiteli spoustu informací, např. pokud si vyplní email pro notifikaci je zasílána informace o každé změně, nebo kontaktujeme držitele v případě významné změny stavu (expirace domény, deaktivace domény, atd..). Někdy posíláme email, někdy dokonce dopis. Občas naše klientské centrum řeší dotazy, zda byl email nebo dopis odeslán a kdy. Zde by každý uživatel mohl mít přehledně seznam komunikace zobrazen.
- Slučování kontaktů – Může nastat situace kdy uživatel má několik kontaktů u různých registrátorů a tak není možné je jednoduše sloučit automaticky. V doménovém prohlížeči by mohl být přehled kontaktů v registru se stejnými údaji a možnost přepojení všech domén navázaných na tyto duplicitní kontakty na kontakt, pod kterým je uživatel přihlášen. To by vyřešilo i palčivý problém některých držitelů domén, kteří nemohou svůj kontakt převést do mojeID z důvodu formátu identifikátoru kontaktu. Takto by si založili kontakt nový se stejnými údaji a poté si na něj jednoduše převedli.
Toto je jen malý výtah z toho co by se dalo dělat. Rádi bychom do diskuze o požadovaných vlastnostech zapojili i komunitu a proto nám prosím, dejte vědět, pokud máte nějaké vlastní nápady případně který z navrhovaných bodů se vám nejvíce líbí a měli bychom ho zvažovat přednostně. Budeme rádi za jakékoliv podněty, které se v komentářích objeví.
Jaromír Talíř
OpenID Connect na cestě
Je to více než rok, co jsem poprvé psal o nové verzi OpenID protokolu nazvané OpenID Connect. Jeho vývoj se od té doby samozřejmě o dost posunul. Před necelým měsícem byl dokončen další významný milník v návrhu této sady specifikací a to je určitě příležitost zmínit se o aktuálním stavu. Pro připomenutí, OpenID je otevřený protokol pro jednotné přihlašování a jeho nová verze Connect je postavena nad moderním autorizačním protokolem OAuth 2.0. Oproti předchozí verzi OpenID 2.0 jsou jeho předností například mnohem jednoduší implementace, připravenost pro mobilní platformy anebo možnost použít email jako přihlašovací jméno.
Práce na novém protokolu začala v březnu 2010 a nyní byl publikován druhý tzv. Implementers Draft – tzn. verze specifikací, která prošla připomínkováním několika implementátorů. Kromě toho, že se průběžně vyvíjené implementace testují v rámci rozsáhlých testů interoperability, existuje již několik produkčních nasazení, kde je možné Connect použít a to např. Google, PayPal nebo Ping Identity. V tuto chvíli asi nejvíc postup blokuje finalizace některých specifikací, na kterých Connect závisí a které jsou vytvářeny podobně jako OAuth 2.0 na půdě IETF. V této organizaci je bohužel odhadováni termínů velká loterie. Přesto existuje orientační plán, při jehož splnění by finální verze specifikací měla být vydána v prosinci letošního roku.
Za vývojem všech OpenID specifikací stoji OpenID Foundation, která sdružuje společnosti jako Microsoft, Google nebo Facebook; vydávání nových specifikací se zde řídí přesnými pravidly. Finální verzi musí členové nakonec odhlasovat. Nová verze OpenID není jedna ucelená specifikace. Naopak, součástí balíku je 8 dokumentů pro jednotlivé oblasti a tyto ještě navíc navazují na řadu dalších specifikací, které nejsou specifické pro OpenID a jejichž vývoj probíhá v rámci IETF. Pojďme si tedy projít jaké jsou základní stavební bloky OpenID Connect.
Spodní vrstvu tvoří víceúčelový autorizační protokol OAuth. Ten má v zásadě za úkol předat mezi třemi entitami (uživatelem, autorizačním serverem a službou) souhlas s nějakou akcí. Specifikace tohoto protokolu ve verzi 2.0 vznikala v rámci pracovní skupiny OAUTH při IETF a po dvou letech práce nakonec vyšla loni na podzim v podobě dvou standardů RFC6749 a RFC6750. Bylo kolem toho hodně dusno, protože jeden z autorů původní verze protokolu, který tento protokol do IETF přinesl, dost ostře s finální verzí nesouhlasil. Nakonec hlasitě zkritizoval všechno, co bylo dosaženo, včetně fungováni IETF a od druhé verze protokolu se distancoval.
Pracovní skupina vydáním dvou RFC neskončila a pracuje na dalších rozšířeních protokolu. Pro Connect jsou nejdůležitější dvě. První z nich přidává automatickou registraci služeb. V základní verzi protokolu se totiž předpokládá, že každá služba bude svým autorem manuálně registrována k autorizačnímu serveru. Jedna z vlastností OpenID je, že služby mohou využívat předem neznámý OpenID server, což je možné právě pouze s využitím automatické registrace.
Druhé rozšíření přidává k základní verzi protokolu přenos tzv. prohlášení o identitě (assertion). Autorizační server v něm kromě své identifikace uvede i jednoznačnou identifikaci přihlášeného uživatele. Právě díky této identifikaci pak může služba ve své vlastní evidenci uživatele najít a umožnit mu přihlášení. Podobně jako velké množství dalších specifikací vznikajících v IETF i zde se začal prosazovat jazyk JSON na úkor XML. Connect bude také využívat prohlášení v jazyku JSON a označované jako JWT (JSON Web Token).
Aby bylo ono prohlášení zmíněné v předchozím odstavci důvěryhodné, musí být podepsané. Jazyk JSON je ovšem poměrně mladý a tak neobsahuje některé vlastnosti, které jsou například v XML již dlouhá léta běžné. Jednou z těchto vlastností jsou právě digitální podpisy, které v XML řeší prověřené rozšíření xmldsig . Tento nedostatek se v IETF snaží napravit pracovní skupina JOSE. Skupina pracuje na čtyřech dokumentech a to JSON Web Algorithms (JWA), JSON Web Encryption (JWE), JSON Web Key (JWK) a JSON Web Signature (JWS). Bohužel ale neschopnost konsenzu finální vydání RFC oddaluje a skupina autorů OpenID Connect je z toho poměrně rozladěna.
Poslední klíčovou závislostí, která vzniká v IETF, tentokrát v pracovní skupině APPSAWG, je protokol webfinger. Tento protokol hraje roli ve fázi OpenID komunikace označované jako „discovery“. Služba se při ní snaží z poskytnutého identifikátoru zjistit, jaká je adresa OpenID serveru se kterým má pro přihlášení komunikovat. Rozhodnutí používat webfinger místo vlastního řešení SWD (Simple Web Discovery) bylo poměrně významnou změnou ve specifikacích OpenID Connect a došlo k ní letos v lednu. Protokol webfinger bude univerzální protokol pro zjišťování dodatečných informací o nějakém zdroji na internetu. Např. pro přihlášení uživatele provede služba po zadání uživatelského jména user@example.com standardní http dotaz na example.com/.well-known/webfinger?resource=acc://user@example.com. Výsledek ve formě JRD (JSON Resource Descriptor) bude obsahovat mimo jiné i adresu OpenID serveru, se kterým se spojit.
Pro zájemce o podrobnější informace o OpenID Connect doporučuji souhrnnou prezentaci jednoho z autorů. Jak je vidět, autoři OpenID Connect si dali nelehký úkol vytvořit standard, který bude skládat obecné technologie do použitelného celku. Historický vývoj specifikací pěkně ilustruje následující obrázek:
OpenID Connect je technologie, od které si svět správců identit hodně slibuje a jejíž vývoj byl také oceněn významnou cenou na loňské konferenci European Identity & Cloud Conference. Jeho vývoj se posouvá, byť možná pomalým tempem, ke svému cíli. Nezbývá než doufat, že tato technologie své příznivce nezklame a podaří se jí po jejím dokončení rychle rozšířit mezi služby na internetu.
Jaromír Talíř
ICANN 45: kostarický a český NIC podepsali memorandum o spolupráci
V Torontu včera začal 45. ICANN meeting, který hned na úvod přinesl jednu pro nás velice příjemnou zprávu. Tou je podepsání dohody o spolupráci s kolegy z kostarického doménového registru. Oboustranně schválené memorandum se vztahuje na spolupráci a výměnu zkušeností při správě domén nejvyšší úrovně.
Naše branže je poměrně specifická a dá se říci, že každý správce registru si ten svůj “byznys” řeší po svém bez ohledu na to, jak to dělají ti druzí. K výměnám zkušeností dochází především prostřednictvím mailových konferencí nebo v rámci setkávání jako jsou právě ICANN meetingy; hlavně tyto dvě cesty nabízejí jedinečnou možnost, jak sdílet informace. Uzavřít s někým užší spolupráci není běžné, naopak, je to vzácnost, která přináší nejen nové zkušenosti, ale může přispět i k řešení velice specifických problémů a situací.
Spolupráce mezi námi a Kostarikou nevznikla jen tak sama od sebe. Se správci registru této země jsme ve spojení už delší dobu. Naše první kontakty začaly u FREDa. Kostaričané jsou totiž jedněmi z těch, kteří tento náš registrační systém zavedli a naplno ho využívají. Na březnovém ICANNu 43 v kostarickém San José také došlo k prvnímu vzájemnému setkání s kolegy z NIC Internet Costa Rica, na němž jsme mimo jiné probírali i vzájemné zkušenosti s implementací DNSSECu. Tato jednání měla pokračování v Praze, kde se konalo hned následující setkání tohoto celosvětového správce sítě Internet. Zde jsme se setkali v rámci workshopu věnovanému opět FREDovi.
Podepsané memorandum je tedy logickým pokračováním naší spolupráce, která by v budoucnu mohla obohatit obě strany.
Jaromír Talíř
5 let s FREDem
V toku nových událostí je dobré čas od času najít chvilku na to se zastavit a podívat se zpátky do minulosti. Jako ideální příležitost se jeví různá výročí a jedno takové právě oslavil náš registrační systém FRED.
Dnes je tomu přesně 5 let, co jsme nasadili FREDa do správy české domény .CZ. 28. září 2007 došlo k zastavení tehdejšího systému a odstartování migračního procesu. Dojeli jsme do sídla tehdejšího správce, firmy T-Systems Pragonet, a převzali CD obsahující kompletní data systému. Po návratu zpět jsme tato data nahráli no připraveného prostředí a spustili transformační skripty pro nový systém. Výsledek transformace jsme následně kontrolovali jednak automaticky dvěma nezávisle napsanými testovacími skripty a pak samozřejmě manuálním testováním. Prvním kritickým momentem byla publikace vygenerovaného zónového souboru pro CZ doménu do internetu. K tomu se váže úsměvná historka. V momentu, kdy kolega Ondřej Surý odstartoval tento proces, ozvala se mu na telefon sestra, že jí doma nejde internet a jestli neví co s tím má dělat. Zatímco jsme ho křísili, zjistili jsme, že se samozřejmě jedná o problém čistě lokálního charakteru. Prodloužený víkend jsme strávili konfigurací systému a testováním všech funkcí. V pondělí 1. 10. v 10 hodin jsme pak otevřeli systém pro nové registrace.
Stávající systém se od toho z před pěti let již značně liší. Některá původní rozhodnutí týkající se návrhu FREDa jsme museli přehodnotit a změnit, museli jsme reagovat na provozní statistiky a také jsme realizovali některé nové nápady. FRED ale nezůstal jen před hranicemi naší země. V průběhu pěti let ho do své správy domény zaintegrovali v Angole, Tanzanii, Kostarice, Faerských ostrovech a v Estonsku. To nás těší a zavazuje zároveň. Snad až uplyne dalších pět let, budeme moci hodnotit uplynulé období stejně pozitivně :).
Jaromír Talíř
Ohlédnutí za IETF 83
Jelikož jsem v předchozích dvou blogpostech o OpenID a WHOISu nalákal čtenáře na IETF 83, sluší se přinést nějaký report o tom, jak tato konference splnila očekávání. Dá se říct, že více než dostatečně.
Jak už je na IETF zvykem, je neděle věnovaná tutoriálům. Mezi ně byl trochu narychlo zařazen i tříhodinový tutoriál na OpenID Connect. To ještě více umocnilo fakt, že tato konference byla problémům digitálních identit věnovaná víc než jsem sám čekal. V zajímavé souhrnné prezentaci bylo zmíněno i probíhající vzájemné testování existujících implementací. Zájemcům o OpenID Connect bych určitě doporučil blogy jeho autorů, zejména články OpenID Connect in a nutshell a Designing a Single Sign-on system using OAuth 2.0. A pokud někdo stále nerozumí rozdílům mezi OpenID a OAuth, existuje i Dummy’s guide. Na závěr byl prezentován i projekt AccountChooser jako nástroj pro poskytovatele služeb, kteří chtějí implementovat jednotné přihlášení napříč technologiemi. Jak udělat správně uživatelské prostředí na straně poskytovatele služeb je zjevně oříšek a nikdo není spokojen s tím co se nazývá NASCAR UI – desítky barevných tlačítek s různými poskytovateli, mezi kterými si uživatel musí nalézt toho svého.
Z pondělních pracovních skupin zaujala NETMOD, jejíž cíl je vydefinovat univerzální datové modely pro vzdálenou konfiguraci různých prvků pomocí protokolu NETCONF. Na datovém modelu pro konfiguraci routingu totiž pracuje Láďa Lhotka z našich laboratoří. Odpolední technické „plenary“ začalo připomenutím druhého dne IPv6, na který se připravujeme i my. Potom už byly hlavními tématy TLS, problémy certifikačních autorit a zabezpečení webu obecně, které se lehce vyhrotilo při kritice tvůrců prohlížečů spočívající v tvrzení, že napadené nebo pochybné certifikační autority neodstraňují z prohlížečů flexibilně.
Avizovaná panelová diskuze o OpenID a OAuth pořádaná organizací ISOC v úterý před polednem byla pro auditorium, ve kterém seděli zástupci různých (číselných i doménových) registrů, spíše seznamovací. Její obsah nejspíš jen vyvolal v posluchačích otázky, které jsme si my položili již dříve a odpověděli na ně v podobě služby MojeID. V navazující pracovní skupině KITTEN, o které jsem se zmiňoval dříve v souvislosti s použití OpenID pro zabezpečení dalších internetových protokolů, se pouze probral stav existujících dokumentů bez nějakého zásadního posunu. To na WEIRDS se očekávala bouřlivá diskuze o podobě nového WHOIS protokolu. Překvapivě se ozvali pouze jednotlivci, kteří mají obavy o zbytečně vynaložené úsilí. Navržený „charter“ pro připravovanou pracovní skupinu tedy bude poslán ke schválení příslušným orgánům IETF. V podvečer ještě zasedla pracovní skupina DNSEXT. Na ní Ondra Surý z našich laboratoří prezentoval navrhovanou úpravu protokolu IXFR. Tato pracovní skupina se pravděpodobně setkala naposledy; její odsouhlasené rozpuštění již čeká pouze na administrativní proceduru.
Středeční program nabídl mimo jiné pracovní skupinu TLS. Ta probírala rozšíření mechanismů pro získání certifikátů při navazování TLS spojení, např. z DNS, jak bylo schváleno v rámci pracovní skupiny DANE. Tato pracovní skupina již všechny svoje dokumenty dokončila a jsou v procesu schvalování, takže pro ni nebyl důvod se tentokrát scházet.
A opět ty identity. Na čtvrteční ráno byl naplánován BOF týkající se protokolu SCIM (Simple Cloud Identity Management). Velcí poskytovatelé cloudových služeb by si rádi standardním způsobem synchronizovali data o uživatelích. Navrhli tedy protokol, který má standardizovány operace pro založení, zobrazení, změnu a zrušení (CRUD) vzdáleného kontaktu spolu s univerzální datovou strukturou v XML a JSONu. Jestli vám to připomíná EPP, které používáme v našem doménovém registru, tak mně také. To jen ukazuje, že staré nápady jsou neustále recyklovány a možná není daleko doba, kdy místo EPP protokolu budeme také používat nějaký REST protokol nad HTTP. Následovala druhá panelová diskuze týkající se OpenID, OAuth a tentokrát i BrowserID. Je více než zřejmé, že BrowserID nemůže OpenID aktuálně plnohodnotně nahradit. Pracovní skupina OAUTH poté řešila hlavně tzv.“rechartering“, tzn. změnu svých cílů. Pro OpenID Connect bude důležité, jestli si pracovní skupina vezme za své některé osiřelé specifikace, na kterých je závislý jako např. Simple Web Discovery. Proti tomu se zvedl částečný odpor, neboť se opět jedná o alternativní přístup k něčemu, na co již existují v IETF jiné standardy host-meta a webfinger.
Závěrečnou tečku za konferencí udělala v pátek pracovní skupina DNSOP. Hlavním tématem bylo TTL a jeho snižování nebo zvyšování. Inženýři z Verisign navrhují jeho výrazné zvýšení jako ochranný mechanismu proti případné nedostupnosti autoritativních serverů. Jejich japonští kolegové naopak doporučují výrazné snížení jako ochranný mechanismus z důvodu rychlého zotavení z případné chyby např. v souvislosti s technologií DNSSEC. K tomu se samozřejmě ještě přidává zákaznický pohled, neboť uživatelé samozřejmě chtějí vidět svoje požadované změny okamžitě. Jednoznačná odpověď asi neexistuje.
Jaromír Talíř
FREDovo dopoledne na ICANN 43
V souvislosti s posledním setkáním ICANN bychom chtěli ještě v krátkosti zmínit události, které v Kostarice potkaly náš registrační systém FRED.
Správci národních domén jsou v rámci ICANN seskupeni v organizaci ccNSO, a to proto, aby při prosazování svých zájmů mluvili pokud možno jedním hlasem. První den celé konference má tradičně tato organizace svůj „TechDay„, na kterém reprezentanti jednotlivých registrů ukazují produkty ze svých „kuchyní“; tady bychom mohli s trochou nadsázky říct, že první polovina dne patřila FREDovi. Shodou okolností totiž po sobě prezentovali technická řešení svých registrů nejprve Estonci, potom Kostaričani a nakonec zástupci Faerských ostrovů. Příjemné pro nás bylo zjištění, že nám FRED neudělal ani v jednom případě ostudu.
V průběhu týdne jsem měl ještě možnost prodiskutovat náš systém s ředitelem registru Rwandy. FREDa mají nasazeného v testovacím provozu a čekají na převedení domény .rw do jejich správy. Kolegové ze zmíněných registrů udělali FREDovi skutečně dobrou reklamu. Krátce po skončení konference se mi totiž ozval správce domény ostrovů Komoro (.km), že zvažují využití systému pro jejich technické řešení.
I s ohledem na tyto události zvažujeme uspořádat v rámci červnového setkání ICANN v Praze specializovaný workshop, kde by bylo možné seznámit potenciální zájemce o tento náš produkt podrobněji. To by FREDovi mohlo pomoci rozšířit se i do dalších destinací, které na automatizovanou správu domény teprve přecházejí.
Jaromír Talíř
Quo vadis WHOIS?
Jedním z témat proběhnuvšího zasedání organizace ICANN byly problémy související se službou WHOIS. Jedná se o službu, kterou nabízejí prakticky všechny doménové registry a která slouží ke zjišťování informací o zaregistrovaných doménách a jejich držitelích. Z pohledu veřejnosti je to prakticky jediná možnost jak tyto informace, často nutné pro řešení sporů nebo bezpečnostních incidentů, získat. V zásadě se téma WHOISu na zasedání probíralo ve dvou rovinách. První rovinnou byla validita dat v registru a druhou problémy vlastního přístupového protokolu definovaného podle RFC 3912.
ICANN v rámci svých pravomocí definuje pravidla pro fungování generických domén nejvyšší úrovně (gTLD) jako jsou .com, .org nebo .net a to včetně pravidel pro získávaní a zveřejňování údajů o držitelích v nich registrovaných poddomén. Kvalita těchto údajů je v registrech jednotlivých domén různá a obdobně se liší přístup k zacházení s těmito daty. ICANN proto na konci roku 2010 ustanovil skupinu nazvanou WHOIS review team, která měla situaci zanalyzovat. Výsledkem jejich práce je zpráva, která mimo jiné ICANN vyzývá, aby situaci řešil a zpřesnil validitu údajů o 50 % během 12 měsíců. Registry národních domén si pravidla co, kdy a jak zveřejňovat stanovují sami, což ale neznamená, že je nízká validita dat také netrápí. K vidění bylo několik prezentací, které nabízely různé cesty jak zajistit, aby data o držitelích domén byla validní. O cestě, kterou zvolilo Estonsko a která vychází z předávání bankovní informace o vlastníkovi účtu, z něhož se zaplatila doména, jsme již psali v souvislosti s naším registračním systémem FRED, který v Estonsku používají. Vlastní cestu prezentovalo také Turecko. U nás se snažíme jít cestou, že ověřeným kontaktům nabízíme něco navíc a to možnost vlastní správy údajů a sdíleného přihlašování v rámci služby mojeID.
Veřejnost má k těmto údajům přístup kromě obvyklých webových vyhledávacích stránek také pomocí stadardního protokolu podle RFC 3912. O tom, že tento protokol překročil hranice svých možností, se diskutuje již dlouho. Během podzimu loňského roku ale tato situace akcelerovala zejména díky aktivitě adresních registrů. Uvnitř ICANN na problematiku poukázala také zpráva č.51 výboru SSAC (Security and Stability Advisory Committee). Pěkný souhrn poskytla i prezentace z aktuálního setkání. V čem je největší problém? Prakticky všichni se shodují na následujících třech bodech:
- stávající WHOIS protokol umožňuje přesun balíku dat ze serveru na klienta. Neexistuje žádný standardizovaný model pro přenášená data a každá implementace si to tedy dělá po svém.
- neexistuje žádná standardizovaná podpora pro různé jazyky. Protokol neumožňuje vyspecifikovat kódování předaných údajů
- neexistuje žádná možnost autentizace klientů s tím, že by se různým skupinám nabízela různá data
Vyřešení tohoto problému si na svá bedra naložilo IETF. Na první informativní schůzce (BOF) při posledním zasedání se ale strhla bouřlivá diskuze. Problém je, že doménový svět se již o změnu jednou pokusil. Pracovní skupina CRISP zhruba mezi roky 2003 a 2007 vygenerovala jako náhradu WHOISu protokol IRIS, který se ale vůbec neprosadil. Zástupci adresních registrů poměrně silně ventilovali svoje obavy, že kvůli doménám opět skončí tento pokus neúspěšně. Jestli se tyto dvě skupiny dohodnou na ustanovení společné pracovní skupiny se ukáže příští týden na IETF 83. Podle diskuze v mailové konferenci to spíš směřuje ke kompromisu. Jak by finální výsledek mohl vypadat napovídají existující prototypy adresních registrů (ARIN, RIPE,…). Bude se jednat zřejmě od REST službu postavenou na HTTP protokolu s definovaným adresním schématem (např. whoisserver/contact/id) a v odpovědi se bude vracet XML nebo JSON struktura s výsledkem. Ale jsme teprve na startu, takže nebudu předbíhat…
Jaromír Talíř
OpenID bude jedno z významných témat blížícího se IETF 83
Ve svém nedávném blogpostu o identitách jsem zmiňoval finišující proces standardizace protokolu OAuth 2.0 směřující do podoby RFC a novou iniciativu v podobě protokolu OpenID Connect. Tyto technologie a digitální identity vůbec budou zdá se jedním z důležitých témat blížícího se setkání IETF 83. Jako první se iniciativy chopil ISOC, který na příští úterý ohlásil panelovou diskuzi na téma Authentication and Authorization: Next steps for OpenID and OAuth. Vzápětí se na čtvrteční program konference dostala sada prezentací následovaná otevřenou diskuzí na téma Beyond HTTP Authentication: OAuth, OpenID, and BrowserID. Na oboje jsem velice zvědavý, stejně tak na výsledek, které obě akce přinesou.
Na IETF se tyto technologie objevují ještě v jednom ne úplně nevýznamném kontextu. V pracovní skupině KITTEN (Common Authentication Technology Next Generation) se například řeší, jak využít OpenID, OAuth nebo SAML pro autentizaci v běžných internetových protokolech používajících standardy GSS a SASL. Nemusí tak být úplně nesmyslná představa, že jednou bude možné se pomocí OpenID přihlašovat i do LDAPu, IMAPu a dalších. Třeba to nebude trvat dlouho, nechme se překvapit.
Jaromír Talíř
Digitální identity a nové dítko na poli standardů – OpenID Connect
Přestože je téma digitální identity (a souvisejících distribuovaných „single sign-on“ přihlašovacích mechanismů) staré možná jako internet sám, troufám si tvrdit, že jeho největší okamžiky teprve přijdou. Po úspěších centrální správy identit, které v současnosti ukazují veřejné služby jako Facebook, nebo Google+, přirozeně pokukují propagátoři různých forem e-governmentu. V něm mohou některé mechanismy fungovat na podobných principech, přičemž přidaná hodnota je určitě validita údajů identit, které veřejné služby mohou jen těžko dosáhnout. Nesmělé náznaky v podobě elektronických občanek u nás, připravované rozhraní k datovým schránkám, ale i aktivity vlád v celém světě (německý projekt de-ident, americká strategie pro důvěryhodné identity v kyberprostoru NSTIC, nebo projekt evropské identity STORK) naznačují, že tato oblast v blízké době zažije velké změny. Bylo by jistě užitečné, kdyby jednotlivé implementace místo proprietárních řešení vycházely z konsensuálních standardů, které i v této oblasti existují a není jich málo.
Jednou z platforem, na které kooperují autoři těchto standardů, je například Internet Identity Workshop. V rámci pravidelných konferencí této platformy, které se konají dvakrát ročně si zástupci nejrůznějších standardizačních organizací vyměňují informace o novinkách ve svých produktech. Na následujících řádcích bych rád shrnul nejvýznamnější standardy na tomto poli a upozornil na nejnovější aktivitu, která se objevila v průběhu minulého roku.
Asi nejstarším zástupcem protokolů této kategorie je SAML. Jeho první verze pochází z roku 2002 a zatím poslední verze z roku 2005. Za tento, na jazyku XML založený, protokol nese odpovědnost standardizační organizace OASIS, známá svými dalšími „XML aktivitami“ jako Docbook nebo DITA. SAML se poměrně pevně usadil v akademickém světě. Například u nás je to protokol, na kterém funguje Česká akademická federace identit známá pod zkratkou EduID, provozovaná sdružením CESNET. Takže pokud máte účet v systému své vysoké školy, s velkou pravděpodobností můžete používat SAML pro přihlašování u systémů poskytovatelů služeb, které jej podporují. Těch bohužel není mnoho a zejména jsou to opět akademické instituce. Jedním z těchto poskytovatelů služeb by, alespoň podle dokumentace, měly být i GoogleApps.
V roce 2005 se na poli standardů objevil protokol OpenID. Jeho jádro prošlo vývojem a ustálilo se na verzi 2.0 z konce roku 2007. V průběhu dalších zhruba tří let si získal velkou popularitu a podporovali ho i velcí hráči jako Google nebo Microsoft. Za účelem rozvoje tohoto standardu vznikla organizace OpenID Foundation, která sdružuje jak zástupce poskytovatelů identit, tak poskytovatelů služeb. U nás byl dlouho jediným větším průkopníkem této technologie Seznam.cz. Předloni jsme si OpenID jako komunikační protokol zvolili i my s naší službou ověřených identit mojeID. Důležitou vlastností tohoto protokolu je možnost standardizované výměny atributů identity.
Při práci na implementaci OpenID do služby Twitter vznikla další významná technologie pojmenovaná OAuth. Na rozdíl od OpenID má tato technologie jako cíl umožnit poskytovatelům služeb zabezpečený přístup k nějaké obecně libovolné sadě funkcí, kterou jiná služba nabízí. První draft byl publikován v roce 2007 a jeho vývoj se v průběhu roku 2010 přesunul na půdu asi nejvýznamnější internetové standardizační organizace IETF. V této době probíhá práce na dokončení verze 2.0 standardu, jehož finální vydání ve formě RFC je „snad“ otázkou příštích několika týdnů. Po Twitteru přijal tuto technologii za vlastní také Facebook a nakonec ji do repertoáru svých autentizačních mechanismů přidal i Google.
Co se týká srovnáni OAuth a OpenID tak OAuth sice nabízí asi jen polovinu vlastností které má OpenID, ale na druhou stranu to dělá mnohem lépe. Vzhledem k tomu vzniklo v průběhu posledních dvou let několik pokusů, jak zkombinovat to nejlepší z nich do ideálního výsledku. Těchto několik pokusů se nakonec spojilo dohromady a v polovině roku 2011 byl prezentován výsledek v podobě specifikace nazvané OpenID Connect. Toto řešení ve své „spodní“ části využívá OAuth 2.0 a obaluje ho vlastnostmi specifickými pro OpenID. Zajímavou změnou je i následování trendu a nahrazení jazyka XML na příslučných místech jazykem JSON. Od prosince je návrh standardu v připomínkovém řízení a pokud vše půjde hladce, mohli bychom se už letos dočkat jeho finální verze. Za touto specifikací stojí všichni velcí hráči jako Facebook, Google i Microsoft což jí dává poměrně dobré vyhlídky na její budoucí rozšíření.
Jak je vidět, ve světě digitálních identit je hodně živo a my věříme, že minimálně u nás nechá služba mojeID v této diskuzi viditelný otisk. Rodina použitelných specifikací je široká a rozhodně neumírá. Nové generace těží ze zkušeností svých předchůdců a většinou přidávají nové pohledy a nové myšlenky. Z pohledu mojeID samozřejmě nepřestáváme sledovat aktuální vývoj. Charakter této služby nijak nebrání tomu použít několik přístupových technologií paralelně a tím nabídnout poskytovatelům služeb větší výběr možností implementace. Pokud zjistíme vzrůstající poptávku po některém ze zmiňovaných protokolů, pokusíme se této poptávce vyhovět.
Jaromír Talíř