Každá platforma, která to s firemním nasazením myslí vážně, musí přesvědčivě odpovědět na tři otázky: kdo co vidí, kdo co může měnit a kdo o obojím rozhoduje. Poctivá odpověď je vždycky vrstevnatá — ne proto, že by pravidla sama byla složitá, ale proto, že složité jsou skutečné organizace. Vedoucí zákaznické podpory čte všechno ve svém regionu a většinu toho i upravuje, ale na pole s platy v záznamech zaměstnanců nesmí. Mladší analytik vidí tatáž data v očištěné podobě. Auditor má přístup jen pro čtení k pečlivě vybranému výseku a externí partner se dostane jen k záznamům, které se výslovně týkají jeho účtu. Náš model oprávnění je navržený tak, aby taková pravidla vyjádřil čistě, aniž by se z něj stalo bludiště výjimek.
Základem jsou role: pojmenované sady oprávnění, z nichž každé uděluje určitou schopnost. Uživatel je zařazen do jedné nebo více rolí a dědí sjednocení jejich oprávnění — s ohledem na prioritu, ke které se za chvíli vrátíme. Role se dají duplikovat, takže obvyklý začátek nové role vypadá takto: zkopírujte nejbližší existující roli a upravte ji. Definice rolí tak zůstávají přehledné a je snadné pochopit, čím se jedna role liší od druhé.
Samotná oprávnění se zadávají v matici. Každá přidělitelná schopnost je řádek, každá role sloupec. Buňky říkají ano, ne, nebo konkrétní oprávnění s vymezeným rozsahem. Protože matice pokrývá všechny typy, moduly, vlastnosti, dotazy, pohledy i systémové schopnosti, je jediným místem, kam se podívat na jakoukoli otázku ohledně oprávnění. „Může vedoucí podpory upravovat záznamy Tiket?“ je jedna buňka. „Vidí čtenář HR vlastnost Plat u typu Zaměstnanec?“ je jiná. Tahle jednotnost se cení, když počet rolí v prostředí roste — je to plocha, kterou lze auditovat, ne hrst příznaků roztroušených po kódu.
Model drží výrazným jemně odstupňovaný rozsah. Oprávnění existují na úrovni modulu, typu, vlastnosti, dotazu, pohledu i akce. Role může vidět typ, ale ne ho upravovat; vidět většinu jeho vlastností, ale ne citlivou podmnožinu; spouštět určité dotazy, ale ne jiné; používat některé pohledy, ale ne ty administrátorské. To dává implementátorům přesný nástroj — a ten je potřeba u regulované agendy a citlivých dat. Skrýt jen vlastnost plat u typu Zaměstnanec před nemanažery je jediná buňka, ne architektonický projekt.
Když má uživatel víc rolí, konflikty řeší priorita rolí. Při neshodě dvou rolí o témže oprávnění se vyhodnocuje dřív a má navrch role s vyšší prioritou. Okrajové případy tím zůstávají předvídatelné: zkušený uživatel, který je zároveň v úzké, omezující roli, o svůj vyšší přístup nepřijde, protože seniorní role stojí nad tou úzkou. Priorita je výslovná a nastavitelná; chování není nijak skryté.
Přednost zákazu pokrývá případ, kdy chcete udělit „všechno“, ale přesto vyseknout konkrétní výjimku. Role může mít na typu zastřešující oprávnění ALL a k tomu navíc konkrétní zákaz pro jedinou citlivou vlastnost. Matice si poradí s obojím, takže široké pravidlo i úzká výjimka vedle sebe fungují bez pnutí.
Několik systémových rolí je zabudovaných, protože většina prostředí chce stejnou výchozí sadu. Superuser pro neomezený přístup. Editor pro široké čtení i zápis. Reader pro čtení. Publisher pro obvyklý případ správy veřejně dostupného obsahu. Tenant Admin pro delegovanou správu — role, která provozovateli umožní dát zákazníkovi pravomoc spravovat si vlastní prostředí (uživatele, role, pozvánky), aniž by mu předával klíče od celé platformy. Tahle delegace je pro škálovatelný provoz důležitá: zákazníci si běžný den zvládnou obsloužit sami a nemusí každá změna uživatelů čekat ve frontě u provozovatele platformy.
Volná úprava (free edit) je drobnost, která se hodí: u vysoce důvěryhodných rolí jako Superuser a Editor nabízí platforma režim, kdy obvyklé pojistky na úrovni vlastností ustoupí plnému přístupu k úpravám. Je to výslovná volba pro danou roli, ne výchozí stav, a existuje proto, aby údržbu vlastní konfigurace platformy — kde má uživatel z podstaty sahat na všechno — nebrzdila pravidla po jednotlivých vlastnostech, jež se na administrátora stejně nevztahují.
Veřejné stránky mají vlastní režim. Obsah zpřístupněný nepřihlášeným návštěvníkům řídí paralelní sada oprávnění, která stojí mimo běžný systém rolí — táž implementace tak může nést interní pravidla přístupu i pravidla pro veřejnost, aniž by se navzájem pletla. Podrobně to popisuje článek o veřejných stránkách.
Výkon řeší jedno nenápadné rozhodnutí v návrhu: vyhodnocená oprávnění se pro každého uživatele ukládají do mezipaměti, takže se matice nepočítá od nuly při každém načtení stránky. Když se role změní, mezipaměť se odpovídajícím způsobem zneplatní. Uživatelé si mezipaměti nevšimnou; všimnou si jen toho, že oprávnění reagují svižně — přesně jak mají.
Přes REST API platí stejná oprávnění. Integrace přihlášená jako konkrétní uživatel vidí přesně to, co by viděl on — nic víc, nic míň. Je to jemný, ale podstatný bod: systém oprávnění není záležitost rozhraní, je to záležitost platformy, a každá cesta k datům ho respektuje jednotně. Obrázek doplňují odkazy na článek o systémových oprávněních, o přihlašování a o přizpůsobení pro zákazníka. Ale práce se odehrává v matici — a pro většinu prostředí je to jedna obrazovka, kterou si nastaví na začátku a málokdy se k ní musí vracet.