Pravidla v CzechIdM

V tomto článku si povíme něco o pravidlech v našem Identity Management systému CzechIdM. Ukážeme si, co jsou to pravidla, jaké druhy pravidel v CzechIdM používáme a k čemu slouží. Je důležité zmínit, že máme na mysli například pravidla definující politiku hesel (tomu je věnován článek “Pravidla pro vytváření hesel v CzechIdM”) a podobně. Na pravidla zde nahlížíme z programátorského pohledu.

Co jsou to pravidla v CzechIdM

Pod pojmem pravidla rozumíme v CzechIdM XML soubory, ve kterých je zapsán Java kód. Jedná se prakticky o funkce, které jsou zapsány v podobě BeanShell skriptů. V tomto formátu se pravidla importují do databáze CzechIdM. Importovaná pravidla mohou být dále volána z jiných pravidel, mohou je využívat workflow (procesy zapsané v jPDL) nebo mohou být jinak specificky použita v CzechIdM (o tom již dále).

Z předešlého odstavce je zřejmé, že se pravidla v CzechIdM hojně využívají. V následující kapitole si je proto klasifikujeme dle použití a blíže si je popíšeme, a to včetně příkladů.

 Druhy pravidel v CzechIdM

Obecná pravidla

Obecná pravidla nekladou oproti ostatním kategoriím pravidel žádná omezení na vstupní a výstupní parametry. Tato pravidla slouží především pro dekompozici kódu, stejně jako například metody v Javě. Nejčastěji jsou volána z workflow, ale mohou být spouštěna například i z JSF stránek prezentační vrstvy.

Níže je uveden příklad obecného pravidla. Jak je vidět, jedná se o Java kód zapsaný v obyčejném XML (proto &amp; místo znaku &). Kód se vždy zapisuje do tagu <rule-definition>, přičemž se jako atribut tagu musí uvést název příslušného pravidla. Tento název se zároveň musí shodovat s názvem XML souboru, kde je pravidlo zapsáno. Jiné tagy se pro definici pravidel nepoužívají. Samotný Java kód vzorového pravidla není nikterak složitý. Na začátku pravidla se importují všechny požadované třídy, které nejsou součástí balíčku “java.lang”. Poté se prostřednictvím BeanShell interpretu načtou vstupní parametry, což je v tomto případě “userView” (UserView je třída, která zapouzdřuje údaje o identitě a jejich účtech na připojovaných systémech). Výstupem tohoto pravidla je poté celé jméno uživatele dané identity. Jak je vidět, tak výstup z pravidla je stejný jako výstup klasické Java metody, tedy prostřednictvím příkazu “return”.

<?xml version="1.0" encoding="UTF-8"?>
<rule-definition xmlns="urn:jbpm.org:bcv_rule-1.0" name="getFullName">
 import eu.bcvsolutions.idm.data.view.View;

 View userView = this.interpreter.get("userView");
 String firstName = userView.get("firstName");
 String lastName = userView.get("lastName");

 String fn = (firstName != null) &amp;&amp; (!firstName.trim().equals("")) ? firstName.trim() + " " : "";
 String ln = (lastName != null) &amp;&amp; (!lastName.trim().equals("")) ? lastName.trim() : "";
 return fn + ln;
</rule-definition>

Transformační pravidla

Tato pravidla nacházejí uplatnění při načítání/ukládání dat z/do koncových systémů. Nejjednodušší bude, když si to opět demonstrujeme na příkladu. Předpokládejme, že chceme k CzechIdM napojit personální systém. V CzechIdM namapujeme atributy zaměstnanců na atributy identit, tj. vytvoříme schéma pro koncový systém. V personalistice je použit binární atribut “enabled”, který značí, zda je zaměstnanecký účet aktivní. V CzechIdM však používáme atribut “disabled”, tedy znegovanou hodnotu atributu použitého v personalistice. Jak tento “problém” vyřešit? Jednoduše. V mapovací tabulce schématu nastavíme mezi dané atributy pravidlo, které vždy hodnotu zneguje, a je jedno, jestli se z personalistiky údaje načítají nebo do ní zapisují.

Na předchozím obrázku je vidět mapovací tabulka mezi CzechIdM a vzorovým personálním systémem. Povšimněte si, že lze použít rozdílná pravidla pro čtení z koncového systému a pro zápis.

“Before” a “after” provisioning pravidla

Tato dvě pravidla souvisí s tzv. provisioningem identit s účty na koncových systémech. V těchto pravidlech se specifikují akce, které se mají provést před nebo po skončení provisioningu. Mezi vstupy těchto pravidel patří například název identity, název odpovídajícího účtu, název koncového systému, název použitého schématu, mapa atributů daného koncového systému, se kterými mohou daná pravidla pracovat, a typ provedené operace, což může být:

• ADD – byla vytvořena nová identita,
• SET – byl přidán nový atribut,
• CHANGE – změna hodnoty atributu,
• REMOVE – byla odstraněna stávající identita,
• DISABLE – identita byla zablokována,
• ENABLE – identita byla odblokována,
• UNLINK – byla zrušena vazba (spárování) mezi identitou a účtem, atd.

After provisioning pravidla nemají žádnou návratovou hodnotu. Příkladem může být pravidlo, které po zablokování účtu na koncovém systému (dle seznamu výše se tedy jedná o typ operace DISABLE) aktualizuje hodnotu ještě jiného atributu koncového systému, např. datum a čas zablokování. Oproti tomu before provisioning pravidla mají vždy návratovou hodnotu. Tou může být buď seznam změněných atributů koncového systému, nebo hodnota null, která značí, že se provisioning má přerušit.

Korelační pravidla

Korelační pravidla se používají při rekoncilaci a synchronizaci koncového systému s CzechIdM. Korelační pravidlo dostane na vstupu jedinečný identifikátor účtu na koncovém systému, atributy koncového systému mapované na atributy identity (dle specifikovaného schámatu), název schématu, název samotného koncového systému a typ prováděné operace (určuje, zda se jedná o synchronizaci či rekonciliaci). Dle vstupních hodnot poté pravidlo navrací název identity, která odpovídá danému účtu na koncovém systému. Pokud žádná identita účtu neodpovídá, tak pravidlo navrací “null”. Korelační pravidla se však nevolají pro každý účet na koncovém systému. Nejdříve se zjistí, zda není daný účet již přiřazen nějaké identitě CzechIdM (dle account indexu). Pokud přiřazen již je, tak se rovnou přejde do stavu ASSIGNED (viz. níže). Pokud není přiřazen k identitě, tak se se spustí korelační pravidlo. Pokud pravidlo navrací null (neexistuje odpovídající identita), tak se přejde do stavu MISSING_IDENTITY. V opačném případě navrací pravidlo název korelované identity a přejde se do stavu MATCHED. Nakonec zbývají identity, ke kterým neexistují účty na koncovém systému (stav MISSING_ACCOUNT).

Stavy při rekoncilaci/synchronizaci:

• MISSING_IDENTITY – značí, že chybí odpovídající identita v CzechIdM,
• MISSING_ACCOUNT – značí, že chybí odpovídající účet na koncovém systému,
• MATCHED – pro daný účet existuje odpovídající identita, ale vazba mezi účtem a identitou ještě neexistuje ,
• ASSIGNED – vazba mezi účtem a identitou již existuje .

Pravidla pro blokování účtů na koncových systémech

Jak název napovídá, tak tato pravidla slouží pro blokování účtů na koncových systémech. Způsoby blokace účtů na připojovaných systémech (včetně použití blokujících pravidel) již byly kolegou popsány v článku “Blokování účtů v CzechIdM”, a proto se jimi zde nebudeme více věnovat.

Pravidla pro nastavování nových hodnot atributů

Tato pravidla slouží k nastavování nových hodnot u atributů identit (dle daného schématu) při jejich aktualizaci. Tato pravidla se nastavují u rolí, protože právě k rolím se přiřazují schémata pro koncové systémy, tj. role definují účty na koncových systémech. U role se tedy vybere požadované schéma koncového systému a u požadovaných atributů schématu se nastaví pravidla. Pravidla mohou aktualizovat hodnotu na základě předchozí hodnoty, přičemž existují 4 strategie, které se pro daný atribut mohou nastavit:

• WRITE_IF_NOT_EXISTS – k aktualizaci atributu dojde, pokud předtím neměl nastavenu žádnou hodnotu,
• OVERWRITE_IF_MODIFIED – k aktualizaci dojde, pokud došlo k modifikaci předchozí hodnoty,
• OVERWRITE_FIRST_TIME – hodnota atributu bude poprvé přepsána,
• OVERWRITE_ALWAYS – hodnota bude vždy přepsána.

Notifikační pravidla

Notifikační pravidla se vážou k rolím a jejich přidělování identitám v CzechIdM. Pokud má role definováno notifikační pravidlo, tak se po přidělení role identitě toto pravidlo spustí. Kód, který toto pravidlo vykoná, může být zcela libovolný, ale primárním účelem těchto pravidel, jak již název napovídá, je něčí notifikace. Ukažme si to prakticky na příkladu. Mějme roli s názvem “Notebook”. Přidělení této role identitě značí, že příslušná osoba (například zaměstnanec) má dostat pracovní notebook. Bylo by vhodné informovat např. IT oddělení, aby pro zaměstnance notebook připravili. A přesně k tomu se může použít notifikační pravidlo, které například odešle příslušné osobě informativní email, aby notebook připravila.

Závěr

Popsali a ukázali jsme si, k čemu slouží v CzechIdM pravidla. Na zlepšování CzechIdM, stejně jako na rozšiřování jeho možností, stále pracujeme. Proto Vám budeme vděčni za návrhy, jak tento systém dále vylepšit. Vaše návrhy a případné dotazy mi můžete posílat na emailovou adresu info@bcvsolutions.eu.

Další témata