Tag Archives: Synchronizace

Jak zrychlit načítání dat z personálního systému VEMA?

Pří správě uživatelských účtů Identity Managerem je vždy jeden, nebo více systémů, autoritativní zdroj informací o uživatelích. Údaje o uživatelích jsou v pravidelných intervalech načítány a dále se propagují do dalších systémů. Jelikož počet takových uživatelů může být velký, tak je neefektivní je načítat všechny, protože u většiny uživatelů nedojde k žádné změně. Ideální řešení je takové, že Identity Manager načítá z autoritativního systému pouze ty uživatelské záznamy, které byly od posledně modifikovány. To však lze pouze v případě, že daný systém u záznamů uživatele ukládá čas poslední modifikace. Personální systém Vema, který je u našeho zákazníka pro CzechIdM autoritou pro identity, neposkytuje pouze změnové záznamy. Proto jsme si museli poradit sami a to jednoduše. V databázi Oracle, kam se provádí z personalistiky full-export, jsme zajistili evidenci změn a tyto změny poskytujeme do CzechIdM. Tím bylo možné rapidně zrychlit načítání autoritativních dat. Proces, který dříve trval až 13 hodin, byl nahrazen procesem, který trvá řádově minuty! Pojďme se na to podívat blíže.

Počáteční stav

Zdrojem autoritativních dat je personální systém Vema. Z personálního systému se provádí každý den full-export do Oracle DB, ze které si je mohou načítat externí aplikace. Export probíhá tak, že se nejprve smažou všechna data včetně samotných databázových tabulek, opět se vytvoří databázové tabulky a následně se do nich vloží aktuální data personálního systému. CzechIdM načítá data o uživatelích právě z exportní Oracle databáze. Na základě načtených dat inicializuje personální procesy a propaguje změny na další napojené systémy. Například při nástupu nového zaměstnance CzechIdM načte jeho popisné údaje z Oracle databáze, založí mu identitu v CzechIdM a na základě jeho funkčního zařazení mu přidělí role, dle kterých se pro něho automaticky vytvoří účty na dalších systémech zákazníka (založí se mu email, účet v docházkovém systému atd.). S tím, jak se rapidně navyšujel počet načítaných uživatelů a počet napojených koncových systémů, tak se samozřejmě prodlužuje i samotný proces rekonciliace. Bylo tedy potřeba od něho upustit a přejít k synchronizaci. Problémem však bylo, že personální systém neexportuje s uživatelskými daty informace o času jejich poslední modifikace. Dříve, než se podíváme, jak jsme daný problém vyřešili, tak si pro jistotu vysvětlíme co znamenají výše uvedené pojmy rekonciliace a synchronizace. :-)

Synchronizace vs rekonciliace

Pojem rekonciliace v původním významu označuje proces usmíření, uvedení věcí do souladu. Tato definice poměrně přesně popisuje rekonciliaci i z pohledu Identity Managementu. Při rekonciliaci se prochází všechny uživatelské účty na koncovém systému a na základě definovaných akcí se aktualizují identity uživatelů v Identity Manageru. V našem konkrétním případě, kde koncovým systémem je personalistika, se na základě načtených dat aktualizují identity uživatelů, případně se vytváří identity nové pro nově evidované zaměstnance. Jelikož je personální systém v tomto případě systémem autoritativním, tak se popisné atributy automaticky propagují do koncových systémů, na kterých mají uživatelé založeny účty. Zde lze vidět analogii k původnímu významu slova rekonciliace. Identity manager uvede do souladu atributy uživatele na jeho účtech na koncových systémech s atributy, jenž jsou uvedeny dle personálního systému. Synchronizace, na rozdíl od rekonciliace, neprochází všechny uživatelské účty na koncovém systému. Místo toho si zjistí, které účty byly modifikovány od poslední synchronizace a dále pracuje pouze s nimi. V našem případě, kde mluvíme o napojování personálního systému, je hlavní výhodou synchronizace vůči rekonciliaci doba jejího běhu. V personálním systému je evidováno tisíce uživatelů, ale denně se jich aktualizuje pouze několik desítek, maximálně stovek. Doba běhu synchronizace je tedy řádově nižší než u rekonciliace.

Implementace synchronizace

Vraťme se však od strohé teorie k řešení našeho problému. Chceme nahradit proces rekonciliace personálního systému synchronizací. Data načítáme z přechodové Oracle databáze prostřednictvím databázových view, jenž pro nás integrují data z vícero tabulek. A co je hlavní, tak v datech není uvedeno, kdy byl daný záznam naposledy modifikován! První, co potřebujeme, je evidovat u všech tabulek obsahujících záznamy uživatelů informaci, kdy byl daný záznam aktualizován. Jelikož se tabulky při exportu z personálního systému mažou, tak si vytvoříme jejich kopie, které budou navíc obsahovat sloupec s informacemi o poslední modifikaci daného řádku (sloupec “modif_time”). Dále je potřeba realizovat to, že při exportu dat z personalistiky do databáze se nám budou aktualizovat data v našich tabulkách – “kopiích” s tím, že se nám případně aktualizuje sloupec “modif_time”, pokud se daný řádek v “kopii” liší od aktuálně exportovaného. Použití databázových triggerů není úplně šťastné, když se databázové tabulky při exportu mažou. Rozhodli jsme se tedy pro implementaci databázové procedury, která se bude volat vždy po skončení exportu. Ve výpisu níže je uvedena část této procedury, která se týká jedné z exportních tabulek, tabulky VEMA_UZIVATEL. Příkazem MERGE vložíme do naší “kopie” (tabulka CZECHIDM_UZIVATELE) záznamy pro nové uživatele a aktualizujeme atributy u záznamů, které se liší mezi tabulkami VEMA_UZIVATEL a CZECHIDM_UZIVATELE. Zároveň u příslušných záznamů aktualizujeme atribut “modif_time” v tabulce CZECHIDM_UZIVATELE. Následně zavoláním příkazu DELETE smažeme v tabulce CZECHIDM_UZIVATELE ty záznamy, které se již nevyskytují v tabulce VEMA_UZIVATEL. Obdobně je to realizováno i u ostatních exportních tabulek, které se týkají uživatelů a jejich atributů.

 /* Uzivatel */
 MERGE INTO VEMAEXPORT.CZECHIDM_UZIVATELE IDM
 USING (
 SELECT VEMA.JMENOZD, VEMA.PRIJMZD, VEMA.TITULYP, VEMA.TITULYZ, VEMA.OSCIS, VEMA.IDCIS, VEMA.LOKALITA FROM VEMAEXPORT.VEMA_UZIVATEL VEMA
 LEFT JOIN VEMAEXPORT.CZECHIDM_UZIVATELE IDM
 ON (VEMA.OSCIS = IDM.OSCIS)
 WHERE
 (IDM.OSCIS IS NULL) OR 
 (VEMA.JMENOZD || VEMA.PRIJMZD || VEMA.TITULYP || VEMA.TITULYZ || VEMA.OSCIS || VEMA.IDCIS || VEMA.LOKALITA) <> 
 (IDM.JMENOZD || IDM.PRIJMZD || IDM.TITULYP || IDM.TITULYZ || IDM.OSCIS || IDM.IDCIS || IDM.LOKALITA)) VEMA
 ON (VEMA.OSCIS = IDM.OSCIS)
 WHEN MATCHED THEN 
 UPDATE SET 
 IDM.JMENOZD=VEMA.JMENOZD, 
 IDM.PRIJMZD=VEMA.PRIJMZD, 
 IDM.TITULYP=VEMA.TITULYP, 
 IDM.TITULYZ=VEMA.TITULYZ, 
 IDM.IDCIS=VEMA.IDCIS, 
 IDM.LOKALITA=VEMA.LOKALITA, 
 IDM.MODIF_TIME=sysdate 
 WHEN NOT MATCHED THEN
 INSERT (OSCIS, JMENOZD, PRIJMZD, TITULYP, TITULYZ, IDCIS, LOKALITA, MODIF_TIME)
 VALUES (VEMA.OSCIS, VEMA.JMENOZD, VEMA.PRIJMZD, VEMA.TITULYP, VEMA.TITULYZ, VEMA.IDCIS, VEMA.LOKALITA, sysdate); 

 /* Smazeme data, co byla smazana ve VEMA_* tabulce */
 DELETE FROM VEMAEXPORT.CZECHIDM_UZIVATELE WHERE (OSCIS) IN (
 (SELECT OSCIS FROM VEMAEXPORT.CZECHIDM_UZIVATELE WHERE (JMENOZD, PRIJMZD, TITULYP, TITULYZ, OSCIS, IDCIS, LOKALITA)
 NOT IN
 (SELECT JMENOZD, PRIJMZD, TITULYP, TITULYZ, OSCIS, IDCIS, LOKALITA FROM VEMAEXPORT.VEMA_UZIVATEL))
 );

Nakonec upravíme naše databázová view, aby se data načítala z našich “kopií” místo původních exportních tabulek a aby navracela u každého uživatele timestamp poslední modifikace přes všechny tabulky, které drží informace o uživateli. Příklad takového view je ve výpisu níže.

CREATE OR REPLACE FORCE VIEW "VEMAEXPORT"."CZECHIDM_UZIVATEL_VIEW" ("JMENO", "PRIJMENI", "TITULY_P", "TITULY_Z", "OSCIS", "IDCIS", "LOKALITA", "BUDOVA", "KANCELAR", "PSC", "LOGIN", "EMAIL", "TELEFON", "TELEFON_WEB", "MOBIL", "MODIF_TIME") AS 
 select distinct
 U.JMENOZD, 
 U.PRIJMZD, 
 U.TITULYP,
 U.TITULYZ,
 U.OSCIS,
 U.IDCIS,
 U.LOKALITA,
 (select L.ULICEN || ' ' || L.CP || ', ' || L.POSTA from CZECHIDM_LOKALITA L where L.LOKALITA=U.LOKALITA),
 (select L.NAZEV from CZECHIDM_LOKALITA L where L.LOKALITA=U.LOKALITA),
 (select L.PSC from CZECHIDM_LOKALITA L where L.LOKALITA=U.LOKALITA),
 (select C.KOD from CZECHIDM_SPOJENI C where (C.OSCIS=U.OSCIS and C.CISSP=1 and C.TYPSP='login')),
 (select C.KOD from CZECHIDM_SPOJENI C where (C.OSCIS=U.OSCIS and C.CISSP=2 and C.TYPSP='e-mail')),
 (select C.KOD from CZECHIDM_SPOJENI C where (C.OSCIS=U.OSCIS and C.CISSP=3 and C.TYPSP='telefon')),
 (select C.KOD from CZECHIDM_SPOJENI C where (C.OSCIS=U.OSCIS and C.CISSP=4 and C.TYPSP='telefonweb')),
 (select C.KOD from CZECHIDM_SPOJENI C where (C.OSCIS=U.OSCIS and C.CISSP=6 and C.TYPSP='mobil')),
 (select MAX(MODIF_TIME) from (
 SELECT U1.OSCIS AS OSCIS, L1.MODIF_TIME FROM CZECHIDM_UZIVATELE U1 LEFT JOIN CZECHIDM_LOKALITA L1 ON U1.LOKALITA=L1.LOKALITA
 UNION
 SELECT U1.OSCIS AS OSCIS, U1.MODIF_TIME AS MODIF_UZIVATEL FROM CZECHIDM_UZIVATELE U1
 UNION
 SELECT V.OSCIS AS OSCIS, V.MODIF_TIME AS MODIF_VYNETI FROM CZECHIDM_VYNETI V
 UNION
 SELECT Z.OSCIS AS OSCIS, Z.MODIF_TIME AS MODIF_VYNETI FROM CZECHIDM_ZASTUP Z
 UNION
 SELECT S.OSCIS AS OSCIS, S.MODIF_TIME AS MODIF_VYNETI FROM CZECHIDM_SPOJENI S
 UNION
 SELECT PS.OSCIS AS OSCIS, PS.MODIF_TIME AS MODIF_VYNETI FROM CZECHIDM_PRAC_SMLOUVY PS
 UNION
 SELECT PZ.OSCIS AS OSCIS, PZ.MODIF_TIME AS MODIF_VYNETI FROM CZECHIDM_PRAC_ZARAZENI PZ
 ) WHERE OSCIS=U.OSCIS)
 from CZECHIDM_UZIVATELE U;

Tímto máme realizovány všechny požadavky na straně databáze. Nyní již zbývá pouze nakonfigurovat synchronizaci personálního systému v CzechIdM a vypnout zdlouhavou rekonciliaci. :-) Jak toho docílit je hezky popsáno v příspěvku První krůčky s CzechIdM  Kapitola 3: Nastavení synchronizace a rekonciliace systému jednoho z kolegů.

Výsledek

A jaký je výsledek? Proces rekonciliace, který v tomto konkrétním případě trval několik hodin, byl nahrazen synchronizací, jenž běží většinou několik málo minut.

Závěr

V tomto příspěvku jsme si popsali rozdíly mezi synchronizací a rekonciliaci koncového systému. Dále jsme si na praktickém příkladu ukázali, jak je možné implementovat synchronizaci nad systémem, který na první pohled synchronizaci neumožňuje. Pokud byste měli nějaké dotazy, tak mne neváhejte kontaktovat na info@bcvsolutions.eu.

CzechIdM umí synchronizovat i bez programování

Za několik málo dní nastane pro CzechIdM velká událost, kterou ještě nebudu prozrazovat. Nicméně se snažíme CzechIdM na tento krok do neznáma připravit tak, aby jej zvládl a obstál se ctí. S tímto velkým krokem souvisí fakt, že se snažíme CzechIdM rozšířit tak, aby jej administrátor pouze nainstaloval a vše mohl nakonfigurovat v grafickém rozhraní, případně v konfiguračních souborech. Do nedávna musel administrátor mnoho věcí programovat v Javě resp. BeanShellu, mezi které patřila i synchronizace a rekonciliace napojených systémů. Udělali jsme zásadní rozhodnutí a nyní si oboje může administrátor nakonfigurovat, nebo naprogramovat, pokud preferuje tuto variantu. Pozn.: Nadále pro jednoduchost budu mluvit jen o synchronizaci, nicméně je tím myšlena i rekonciliace. V opačném případě bude uvedeno explicitně.

Workflow pro každý účet

Jak už jsem výše uvedl, administrátor musel pro každý napojený systém naprogramovat synchronizačním workflow, které v praxi bylo pro mnohé systémy velmi podobné. Výhodou tohoto řešení byla a stále ještě je, veliká variabilita, kdy s účtem a spárovanou identitou můžete dělat úplně cokoliv vás napadne. Jsou systémy, kde takovéto řešení je jediné možné, ale těch je velice málo. Naopak nevýhodou je fakt, že se pro každý synchronizovaný účet a identitu spouští workflow stále dokola, což má neblahý vliv na výkon, kdy vytváření jeho kontextu je řádově pomalejší než implementace v kódu.

Standardní implementace

Jestliže je workflow oproti klasickému kódu o tolik pomalejší, proč jej nevyužít pro synchronizaci? Zvlášť, když by bylo možné takto nakonfigurovat synchronizaci daleko rychleji, pohodlněji? Proto jsme zpracovali rozsáhlou analýzu problému a ujasnili si tak, co synchronizace v rámci workflow ve většině případů dělá. Po velké diskuzi nad tímto tématem jsme se pustili do implementace a nyní vám můžu hrdě a s radostí oznámit, že vše je dokončeno. Implementaci si v tuto chvíli nechám pro sebe a rovnou se vrhnu na jednoduchý modelový příklad, na kterém si vše ukážeme. Po tomto příkladu bude následovat rychlý přehled dalších funkcí, kterým se bude věnovat některý z dalších článků.

Používané termíny

Nejprve si musíme ujasnit některé termíny, které budu dále v příkladu používat:

  • účet – jeden účet na koncovém systému
  • identita – osoba v CzechIdM (může mít více účtů)
  • synchronizace – proces, kdy se zpracovávají jen změněné účty na jednom systému
  • rekonciliace – proces, kdy se zpracovávají všechny účty na jednom systému
  • korelace – podmínka, na jejímž základě se pokouší synchronizace přiřadit účet konkrétní identitě
  • stav synchronizace – stav spárování účtu s identitou; může být:
    • ASSIGNED – účet je již přiřazen konkrétní identitě
    • MATCHED – účet a identita si odpovídají na základě korelace
    • MISSING_IDENTITY – existuje účet na koncovém systému, ale v CzechIdM neexistuje odpovídající identita
    • MISSING_ACCOUNT – existuje identita, která by měla na základě role mít účet na koncovém systému, ale nemá jej. Tento stav může nastat pouze u rekonciliace.

Modelový příklad

Neuvedu zde suchý výčet všech možností synchronizace, ale vše ukážu na jednoduchém případě. Výčet a popis všech možností bude uveden v dalším článku, na který se můžete již teď těšit. Nyní tedy k modelovému příkladu – předpokládejme dva koncové systémy na kterých existují účty a CzechIdM, které jsme si čerstvě nainstalovali a nyní chceme napojit oba systémy. První koncový systém je Personalistika, ve které primárně vznikají účty při příchodu nového zaměstnance. Naopak po jeho odchodu se účet smaže a pokud měl účet na druhém systému s názvem Doména, tak se také smaže.

Vidíme, že se nám tu již tvoří seznam požadavků na synchronizaci, tak si jej zde uvedeme trochu podrobněji:

  1. Pokud vznikne nový účet na systému Personalistika, vznikne odpovídající identita.
  2. Synchronizace systému Personalistika bude probíhat každých 10 minut.
  3. Pokud nebude existovat účet na systému Personalistika, smaže se identita a přiřazený účet na systému Doména.
  4. Ze systému Personalistika se budou načítat veškeré atributy kromě emailu.
  5. Pro nově vytvořenou identitu se vytvoří účet na systému Doména.
  6. Domovská organizace z personálního systému bude top:zaměstnanci, ale pouze při vytvoření identity.
  7. Atribut identity email se bude vždy aktualizovat ze systému Doména a následně se bude zapisovat do systému Personalistika.
  8. Pokud existuje účet na systému Doména a neexistuje odpovídající účet v systému Personalistika, tento účet je určen k zablokování a budeme o něm informovat administrátory.
  9. Rekonciliace systému Personalistika bude probíhat jednou denně.
  10. Synchronizace systému Doména není nutná a proto bude probíhat jen kontrolní rekonciliace jednou denně, která bude aktualizovat email u identity.

Nastavení systémů

Předpokládáme, že oba systémy jsou napojeny pomocí DatabaseTable konektoru a vše potřebné pro připojení je již hotové.

Nastavení atributů systému Personalistika

Na následujícím obrázku je patrné jaké atributy jsou na systému Personalistika a jak jsou mapovány do CzechIdM. Je zde několik důležitých atributů kromě jména a příjmení. Jedná se hlavně o atributy “DISABLED”, který slouží k indikaci zablokovaného účtu a “PASSWORD” kde je uloženo heslo k účtu. Dalo by se říct, že toto je již notoricky známé nastavování atributů systému a proto jej zde nebudu dále rozvádět.

Atributy_schematu_personalistika

Nastavení synchronizace systému Personalistika

Zde můžeme již vidět první nový formulář nastavení, který slouží k nastavení akcí při synchronizaci, konkrétně systému Personalistika. Jak můžeme vidět, pro každý stav synchronizace můžeme nastavit výkonnou akci a informativní akci. Výkonná akce upravuje účet nebo identitu a informativní akce informuje o stavu nebo výsledku. O dalších možnostech nastavení se budete moci dočíst v některém z dalších článků. Nyní se vrátíme k seznamu požadavků a vysvětlíme si, čím v tomto případě zajístíme jejich splnění.

Nejprve tedy první požadavek: Pokud vznikne nový účet na systému Personalistika vznikne odpovídající identita. Nový účet je značen stavem MISSING_IDENTITY, proto pro tento stav zvolíme možnost CREATE_IDENTITY, která nám identitu vytvoří a na základě mapování doplní.

Druhý požadavek zní: Synchronizace systému Personalistika bude probíhat každých 10 minut. Toto nastavíme jednoduše pomocí časovače, jak je uvedeno na obrázku.

Ostatní stavy synchronizace jsou nastavené tak, jak nepřímo plyne ze čtvrtého požadavku: Ze systému Personalistika se budou načítat veškeré atributy kromě emailu. Aby se toto skutečně mohlo dít i v čase, kdy se data v systému Personalistika mění, je nutné mít nastavené u stavu ASSIGNED volbu UPDATE_IDENTITY, která aktualizuje identitu. Pro stav MATCHED pak nastavíme LINK_AND_UPDATE, který dělá to samé jako UPDATE_IDENTITY, ale navíc spáruje účet s identitou.

Jako perlička je uvedena informativní akce pro stav MISSING_IDENTITY a to REPORT_ONLY_IF_ERROR, která odešle email pokud dojde během vytváření identity k chybě. Administrátor tak okamžitě zjistí, že došlo k chybě a může sjednat nápravu.

Nastaveni_synchronizace_systému_personalistika

Nastavení rekonciliace systému Personalistika

Synchronizaci již máme nastavenou, teď tedy k rekonciliaci, díky které je možné splnit čtvrtý požadavek: Pokud nebude existovat účet na systému Personalistika, smaže se identita a přiřazený účet na systému Doména. Chybějící účet je signalizován stavem MISSING_ACCOUNT, který může nastat pouze u rekonciliace, proto zde nastavíme možnost DELETE_IDENTITY. Ta nám zaručí smazání identity, který chybí účet na systému Personalistika a zároveň smazání všech ostatních účtů na koncových systémech.

Opět je zde přidána jedna perlička – nastavená hromadná akce REPORT_ONLY_IF_ERROR. Hromadná akce se spouští vždy po dokončení synchronizace nebo rekonciliace a volba REPORT_ONLY_IF_ERROR zaručí, že jakmile u jakéhokoliv účtu dojde k chybě, bude odeslán e-mail na zadanou adresu. Narozdíl od informativní akce, kde se odešle e-mail pro každou identitu, kde nastala chyba, zde se odešle pouze jeden e-mail s celkovým přehledem.

Nastaveni_rekonciliace_systému_personalistika

Nastavení mapování atributů pro systém Personalistika

Nyní se podíváme na mapování atributů pro systém Personalistika. Možná vás mate, že už jsme jednou atributy pro tento systém nastavovali, ale je to tak správně. Toto mapování totiž určuje, jak se budou vyplňovat atributy u identity, jakmile se má identita vytvářet nebo aktualizovat. Oproti tomu nastavení atributů u systému pouze určuje, jak se atributy z koncového systému budou předávat do CzechIdM a naopak.

V tomto mapování určíme jednoduše čím a jak se budou vyplňovat atributy identity při jejím vytváření ze systému Personalistika. Zde splníme požadavky:

  • Ze systému Personalistika se budou načítat veškeré atributy kromě emailu
  • Pro nově vytvořenou identitu se vytvoří účet na systému Doména
  • Domovská organizace z personálního systému bude top:zaměstnanci, ale pouze při vytvoření identity.

První bod zajístíme tím, že zde atribut “email” neuvedeme a nebude se tedy do identity doplňovat. Ostatní atributy se do identy dostanou díky nastavení zdroje RESOURCE_ATTRIBUTE, který značí, že se atribut načte z koncového systému. Pouze musíme vyplnit jakým atributem na koncovém systému se má hodnota vyplňovat. Důležitým atributem je atribut “name”, který je identifikátorem identity.

Druhý bod je o trochu těžší, ale po vysvětlení se bude vidět jeho elegance – účet na koncovém systému je vždy definován rolí, kterou má identita přiřazenou. Chceme-li zakládat účet při založení identity, přiřadíme jí roli pro daný systém a tím pádem se účet na koncovém systému (zde Doména) vytvoří automaticky. Je nutné zároveň identitě přiřadit roli pro systém Personalistika, kde je synchronizace spouštěna, aby se účet mohl s identitou spárovat. Pro splnění druhého bodu tedy musíme atribut “roles” vyplňovat ze zdroje CONSTANT, neboli konstantou, která je uvdena vedle. Zde je uvedený seznam rolí oddělených znakem “|” a jako datový typ je zde “List<String>”.

Třetí bod splníme tím, že atribut “homeOrganisation” u identity budeme vyplňovat opět konstantou jako v předchozím případě, jen s tím rozdílem, že hodnota bude “top:zaměstnanci”. Druhá část tohoto bodu je zajištěna tím, že se zvolí strategie zápisu CREATE, což značí, že se atribut bude v tomto stavu aplikovat pouze při vytvoření identiy a při aktualizaci se bude ignorovat.

Mapovani_atributu_synchronizace_personalistika

Nastavení atributů systému Doména

Na následujícím obrázku je patrné jaké atributy jsou na systému Doména a jak jsou mapovány do CzechIdM. Je zde několik důležitých atributů kromě jména a příjmení. Jedná se hlavně o atributy “DISABLED”, který slouží k indikaci zablokovaného účtu a “PASSWORD” kde je uloženo heslo k účtu. Dalo by se říct, že toto je již notoricky známé nastavování atributů systému a proto jej zde nebudu dále rozvádět.

Atributy_schematu_domena

Nastavení rekonciliace systému Doména

Abychom splnili požadavky pro napojený systém Doména musíme rekonciliaci nastavit následujícím způsobem. Zrekapitulujeme si požadavky:

  • Atribut identity email se bude vždy aktualizovat ze systému Doména a následně se bude zapisovat do systému Personalistika
  • Pokud existuje účet na systému Doména a neexistuje odpovídající účet v systému Personalistika, tento účet je určen k zablokování a budeme o něm informovat administrátory.

První bod znamená, že se musí identita vždy aktualizovat a proto pro stav ASSIGNED je nastavena akce UPDATE_IDENTITY. Pro stav MATCHED je nastaveno opět LINK_AND_UPDATE. Zároveň pokud chybí účet na systému Doména ale identita má roli přiřazenou, tak dojde ke stvu MISSING_ACCOUNT a protože chceme účet vytvořit, nastavíme CREATE_ACCOUNT.

Druhý bod je opět stejně jednoduchý – stav o kterém se zde bavíme je MISSING_IDENTITY a proto zde nastavíme možnost DISABLE_ACCOUNT, která účet zablokuje na základě politiky blokování účtu na systému. Jelikož by tento stav nastávat neměl, chceme informovat administrátory a proto nastavíme jako informativní akci REPORT a vyplníme e-mailovou adresu.

Nastaveni_rekonciliace_systému_domena

Nastavení mapování atributů pro systém Personalistika

Opět je pro rekonciliaci nastavit mapování atributů ze systému do identity. Je zde řádově méně položek, jelikož Doména je autoritativní zdroj jen atributu email, který se tím pádem načte při každé rekonciliaci do identity. Dalším uvedeným atributem jsou přiřazené role. Jelikož může nastat situace MATCHED, kdy identita odpovídá účtu na základě korelace a zároveň identita nemusí mít přidelenou roli, tak jí tímto způsobem identitě přiřadíme. Stačí, když nastavíme typ zápisu APPEND, což zajistí, že uživateli roli přidá, pouze pokud ji nemá a zároveň ponechá všechny ostatní přidělené role.

Mapovani_atributu_reconciliace_domena

Drobná poznámka před koncem

Takto uvedený postup, kdybyste vše nastavili a spustili, by fungoval zcela správně, pouze pokud by na sytému Doména nexistoval jedinný účet. Pokud by existoval účet, který by měla identita měla vytvářet, dojde k nekonzistenci dat. Pokud byste chtěli takto postupovat, stačí při první synchronizaci systému Personalistika do atributu “roles” nepřidávat roli pro systém Doména. Následně spustit rekonciliaci systému Doména, kde by u všech identit nastal stav MATCHED a role by se identitě přidala. Poslední krok by byl přidáním role do atributu “roles” u synchronizace systému Personalistika.

Závěr

Ukázali jsme si na názorném příkladu, jak by probíhalo nastavení jednoduché synchronizace a rekonciliace u dvou systémů. Představte si, jak byste takové věci složitě programovali – není to úleva, že nyní již nemusíte? :-) O dalších možnostech nastavení si budete moct přečíst v dalším článku.

V případě jakýchkoliv připomínek či dotazů mě kontaktujte na info@bcvsolutions.eu.

Standardní synchronizace v CzechIdM – základní souhrn

Za několik málo dní nastane pro CzechIdM velká událost, kterou ještě nebudu prozrazovat. Připravujeme CzechIdM na tento krok do neznáma tak, aby jej zvládl a obstál se ctí. Velkým úkolem je i zjednodušení instalace a konfigurace. Cílem je, aby administrátor CzechIdM pouze nainstaloval, aby vše mohl nakonfigurovat v grafickém rozhraní, případně v konfiguračních souborech.

Do nedávna musel administrátor mnoho věcí programovat v Javě resp. BeanShellu, mezi které patřila i synchronizace a rekonciliace napojených systémů. Udělali jsme zásadní rozhodnutí – nyní si administrátor může synchronizaci i rekonciliaci nastavit jednoduše v admin rozhraní CzechIdM.

czechidm-synchronisation

Workflow pro každý účet

Administrátor dříve musel pro každý napojený systém naprogramovat synchronizačním workflow, které v praxi bylo pro mnohé systémy podobné. Výhodou tohoto řešení je veliká variabilita, s účtem a spárovanou identitou můžete dělat úplně cokoliv vás napadne. Jsou systémy, kde takovéto řešení je jediné možné, ale těch je velice málo.

Naopak nevýhodou synchronizačního workflow je fakt, že se pro každý synchronizovaný účet a identitu spouští workflow stále dokola, což má neblahý vliv na výkon, kdy vytváření jeho kontextu je řádově pomalejší než implementace v kódu

Implementace synchronizace

Jestliže je workflow oproti klasickému kódu o tolik pomalejší, proč nevyužít právě nativní kód pro synchronizaci? Zvlášť, když by bylo možné takto nakonfigurovat synchronizaci daleko rychleji a pohodlněji?

Proto jsme zpracovali rozsáhlou analýzu problému a ujasnili si tak, co synchronizace v rámci workflow ve většině případů dělá. Po velké diskuzi nad tímto tématem jsme se pustili do implementace.

Nyní vám můžu hrdě a s radostí oznámit, že CzechIdM nabízí standardní synchronizaci přímo v admin GUI. Pro tuto chvíli si nechám pro sebe veškeré možnosti nastevení a jak je vše realizováno. To si budete moci dočíst v některém z dalších článků.

Přínosy standardní sycnhronizace

Jeden z velkých přínosů už byl uveden již výše – nenutíme administrátora programovat, nýbrž se snažíme aby naopak CzechIdM sloužilo právě administrátorovi. Co je tedy konkrétním přínosem?

  • Rychlé a jednoduché nastavení synchronizace
  • Přehledné reportování výsledků
  • Odolnost proti chybám při synchronizaci
  • Rozsáhlé možnosti plnění atributů u identity
  • Přizpůsobivost pro velké množství scénářů synchronizace

Přehled jak vše probíhalo

Prvotní návrh, jak vše implementovat spočíval ve dvou dokumentech. V prvním byla jen představa, co by se nám líbilo. Druhý dokument pak již obsahoval konkrétní návrh, jak vše implementovat. U druhého dokumentu jsme ve více lidech trávili relativně mnoho času, ale výsledkem byl detailní soupis, podle kterého bylo možné vše okamžitě realizovat. Po této analýze nastala pro programátory oblíbená doba implementační. Souběžně s každou fází probíhala i dokumentační část a nemalá část času padla i na projektové řízení, které opět probíhalo souběžně.

Kdybych to měl shrnout, tak z celkového stráveného času nejvíce zabrala implementace – cca 50%. Vše je přehledně vidět v následující tabulce.

Implementace: 53%  (5MD GUI včetně workflow + 12MD samotná implementace v kódu)
Analýza: 16% (5MD – dokumenty s prvotním návrhem a následnou analýzou)
Testování: 15% (5MD – včetně přípravy všech testovacích dat)
Dokumentace: 6% (2MD – od dokumentace kódu až po tutorial jednoduchého nastavení)
Projektové řízení: 6% (2MD – veškeré práce spojené s řízením projektu a rozhodováním)
Ostatní: 4% (2MD – vše co se nevešlo jinam, ale přesto souvisí s úkolem)

Závěr

Na této nové funkčnosti pracovali v průběhu času všichni vývojáři v našem týmu a tímto jim děkuji za skvěle odvedenou práci. V případě jakýchkoliv připomínek či dotazů ohledně synchronizace mě kontaktujte na jan.effenberger@bcvsolutions.eu.