Role v CzechIdM – část I.

V tomto článku si popíšeme nové řešení přiřazování rolí v CzechIdM, které nám nabízí nové možnosti, administrátorům ušetří část práce a především normalizuje vlastnost IdM, kterou jsme jinak téměř pro všechny zákazníky vyvíjeli samostatně.

Časově omezené role s karanténou.

Časově omezené role s karanténou.

Původní stav

CzechIdM je RBAC (Role based access control) provisioning system, který na základě definovaných rolí pracuje s účty na koncových systémech. Pomocí těchto rolí přiřazených uživatelské identitě pak IdM spravuje celý životní cyklus účtu, tedy zakládání, aktivaci, aktualizaci údajů, deaktivaci a odstranění.

Do této chvíle jsme v CzechIdM vždy přiřazovali roli přímo identitě bez jakýchkoliv omezení. To se ovšem v praxi ukázalo jako nedostačující, jelikož ve většině našich projektů je potřeba manipulovat s rolemi mnohem pružněji. Typicky je životní cyklus identity v IdM řízen nějakým autoritativním zdrojem dat, například personálním systémem.

Uveďme příklad nástupu nového zaměstnance. Uchazeč o pracovní pozici úspěšně absolvuje přijímací pohovor a dohodne si datum nástupu za dva týdny. Administrativní pracovník firmy pak připraví podklady jeho smlouvy a v personálním systému vytvoří tomuto nově příchozímu zaměstnanci záznam o nástupu, délce trvání úvazku atd. Stále jsou to tedy téměř dva týdny do zaměstnancova nástupu, ale po synchronizaci IdM s autoritativním systémem jsme už dostali záznam o novém uživateli a měli bychom mu tedy vytvořit identitu a té přiřadit požadované role. Jenže vlastník této identity začíná pracovat až za dva týdny a my nechceme, aby už teď měl přístup například do firemního LDAPu!

Tyto situace jsme prozatím řešili tak, že jsme psali projektově specifická pravidla a workflow, data uchovávali v extended atributech identity, vytvářeli speciální časově spouštěné úlohy atd. Jedním z důsledků je samozřejmě opakování téměř stejné práce pro mnoho našich řešení. Dalším je nedostatečně otestovaná implementace tohoto řešení. Workflow a pravidla píšeme v BeanShellu, který sice testovatelný do určité míry je, ale v rámci celého projektově specifického řešení není snadné izolovat jedinou funkčnost a proto možnost testování jednotek kódu téměř odpadá. Dále můžeme zmínit například nemožnost naplánování přidělení a odebrání role administrátorem IdM. Následky? Monitor oblepený papírky s upomínkami, plné kalendáře událostí o založení účtů, obcházení správného procesu vytvoření identity nebo zapomínání vůbec identity vytvářet.

Časově omezené přidělování rolí

Z výše uvedených důvodů jsme se tedy rozhodli časově omezené přidělování rolí standardizovat. Samotná implementace datové vrstvy znamenala vytvoření jediné vazební třídy *UserRoleDetail* mezi entitami *Identity* a *AbstractRole*. Hlavní část implementace zahrnovala úpravu *UserView*, které nyní obsahuje nový DTO objekt s detailními informacemi o přiřazených rolích.

Používání původního řešení rolí však bylo provázáno velkou částí kódu, proto jsme museli zaručit, že nová funkcionalita bude kompatibilní s dřívějšími releasy CzechIdM. Tato zpětná kompatibilita je ve výchozím stavu zaručena, znamená však malý overhead při vytváření UserView, protože je navíc prohledáván seznam přiřazených rolí, ne jen jejich detailů, které obsahují všechny dostačující informace. Jakmile provedeme na takovéto „staré“ identitě operaci checkin, její jsou upraveny pro podporu časového omezení a podpora původních vydání (a zároveň uvedený overhead) není potřeba.

Co to pro nás znamená? Nemusíme psát na chyby náchylné migrační SQL skripty nebo workflow, stačí zavolat operace checkout a checkin na všechny identity v IdM a máme hotovo. Samotná podpora zpracování rolí v původním formátu se poté vypne v konfiguračním souboru *idm_configuration.properties* v adresáři META-INF EJB modulu, kde se proměnná „legacySupport“ nastaví na logickou hodnotu „false“.

Samotné vytvoření záznamu o přidělení role s časovým omezení pro nás teď znamená jednak přidání názvu role do UserView.roles, ale také nový záznam v UserView.roleDetail, ve kterém jsou definovány právě potřebná časová omezení. Názvy všech potřebných atributů jsou uvedeny jako konstanty ve třídě UserView.

O přidělení a odebrání role se pak starají dvě naplánované úlohy. Ty mají za úkol vyhledat všechny záznamy o rolích, pro které platí nějaké časové omezení (např. datum odebrání role je v minulosti) a předat identitu, která tyto role vlastní, ke zpracování. Všechna časová omezení jsou snadno modifikovatelná v business konstantách. Jedinou nutností pro zprovoznění této funkcionality po instalaci CzechIdM je vytvoření naplánované úlohy, která bude spouštět workflow „process.roles.expirations“.

Závěr

V tomto článku jsme si ukázali některé nevýhody původního řešení přidělování rolí v CzechIdM a ukázali si část nového řešení, které podstatnou část těchto neduhů odstraní. Nové role v IdM jsme ale pouze načali a zbytek řešení si představíme v některém z následujících článků. Pokud byste měli k článku nějaké dotazy, nápady na rozšíření nebo se chtěli podělit o své zkušenosti s vývojem podobné feature, neváhejte mě kontaktovat na info@bcvsolutions.eu.