Systémy

Napojení a správa systémů slouží ke dvěma účelům a to

• získávání dat - synchronizace
• propagace dat - provisioning

Systémy je tak možné rozdělit na zdrojové, tedy ty ze kterých čerpáme data do CzechIdM a spravované (koncové), do těch data z CzechIdM plníme. Jeden napojený systém je možné využít k získávání i propagaci dat zároveň. Například personální systém, ze kterého čerpáme data o zaměstnancích, ale zpět propisujeme email a login generovaný v CzechIdM.

Konfiguraci napojení systému zahájíme na záložce Napojené systémy.Zde vybereme základní informace jako:

• Název systému –naše pojmenování
• Použít vzdálený konektor server – konektory v CzechIdM běží v serveru, většinou je použit lokální server poskytovaný přímo CzechIdM. Výjimkou jsou konektory, které volají nějaké příkazy lokálně a tedy musí být umístěny tam, kde jsou příkazy volány. Například Exchange konektor používá volání PoweShell příkazů přímo na nějkterém DC v AD doméně. Tedy je třeba použít vzdálený konektor server, ve kterém je umístěn náš konektor.
• Politiky hesel – obě volby jsou popsány v kapitole 2.8.1
• Popis – náš volitelný popis systému. Bývá dobrým zvykem popsal účel napojeného systému například: „Personální systém – načítání pracovních míst a útvarů“.
• Readonly – takto označené systémy umožňují pouze čtení. Buď tak značíme zdrojové systémy v CzechIdM nebo systémy, které jsou řízené, avšak nechceme do nich po nějakou dobu provisionovat data. V takovém případě veškerá provisionovaná data padají do fronty provisioningu. Frontu a historii provisioningu zobrazíme Napojené systémy → detail systému (lupa) → Provisioning.Viz. kapitola Audit.
• Neaktivní – Neaktivní systémy nepovolují ani čtecí operace. Pokud se má do takového systému provisionovat, pak operace končí ve frontě stejně jako v případě Readonly systému. Rozdílem však je, že Neaktivní systémy nemají v logu provisioningu spočítány hodnoty atributů, dopočítaly by se až při odblokování systému.

Následně je potřeba na záložce Konfigurace vybrat konektor, kterým se vybraný systém napojí. Samotné nastavení konfigurace napojení systému se pak vždy liší podle zvoleného konektoru.

Mezi základní poskytované konektory patří:

• Database Table Connector – slouží pro napojení jedné tabulky v databázy
• Scritped SQL Connector – slouží pro napojení libovolné DB podporující JDBC.
• Ldap Connector – napojení LDAP.
• CSVDirConnector – vstup/výstup z textového souboru formátu CSV

Další konektory lze libovolně doplňovat buď z volně dostupných zdrojů (AD a Exchange konektor), vlastní implementací nebo poptávkou dodavatele CzechIdM. Konektory využívají široce rozšířený framework connId dříve openICF Connector Framework. Systém konektorů zajišťuje napojení na systém bez nutnosti úpravy samotného spravovaného systému. Využívány jsou totiž jejich standardní poskytovaná rozhraní.

Schéma reprezentuje seznam atributů nějakého objektu v napojeném systému. Vyjmenováním atributů do schématu systému dáváme možnost CzechIdM řídit jejich načítání či plnění. Schéma pro systém nalezneme na záložce Napojené systémy, kde vybereme požadovaný systém a v detailu systému zvolíme záložku Schéma systému.

První možností je vygenerovat schéma systému automaticky, pro to slouží tlačítko Generovat schéma. Tato volba zajistí načtení všech dostupných atributů tak, jak je CzechIdM dostane od použitého konektoru. Automatické generování je možné pouze, pokud ho podporuje konektor, který jsme daná systém zvolili. Ze standardních konektorů tuto funkci podporují například Database Table connector a LDAP connector.

Další možností je naklikat spravované objekty a jejich atributy ručně.

Následně postupujeme po jednotlivých atributech, které pro práci potřebujeme.. U všech vyplníme jejich názvy na systému a jejich datové typy. Dále je u každého z napojovaných atributů zvolit některé z následujících nastavení:

• Je povinný
• Je možné ho číst;
• Obsahuje více hodnot
• Je možné ho vytvořit
• Je možné ho upravit
• Standardně je vracen

Napojené atributy schématu jsou pak vidět v tabulce, jako v následujícím příkladu:

Obrázek 18: Napojené atributy schématu

Kliknutím na znak lupavedle názvu atributu získáme pohled do detailu atributu na daném schématu. Máme zde možnost nastavit následující volby:

• Atribut náleží objektu – Read only atribut zobrazující informaci, pro jaký typ objektu je atribut dostupný
• Název atributu – název atributu v napojeném. Například název sloupce, pokud je napojený systém DB tabulka.
• Datový typ – Typ atributu tak, jak jej vrací použitý konektor. Nejčastěji se jedná o java.lang.String, java.lang.Integer.
• Je povinný – takto označené atributy jsou posílány do koncového systému (provisioning) vždy, bez ohledu, zda se změnila hodnota v CzechIdM oproti hodnotě na koncovém systému. V některých případech konektor vyžaduje specificky označit některé atributy jako povinné. Pokud to však není vyžadováno, doporučujeme tuto volbu nevyužívat z důvodu síťové zátěže.
• Je možné ho číst – Doporučujeme nechávat tuto volbu povolenou. Tato volba zajišťuje kompatibilitu s konektory, které například nepovolují číst vybrané atributy.
• Obsahuje více hodnot – CzechIdM dovoluje načítat a provisionovat atributy, které obsahují více hodnot současně. Například atribut Tituly může být nastaven tak, aby byl z CzechIdM plněn ze 2 atributů – TitleBefore, TitleAfter. Pak atribut Titulyve schématu napojeného systému musí být označen jako vícehodnotový.
• Je možné ho vytvořit – Tato volba se využívá především v situaci, kdy je napojený systém zároveň zdrojový i koncový. Pokud je váš systém pouze zdrojový nebo pouze koncový, doporučujeme nechávat tuto volbu povolenou. Čtení a zápis pak řídit na úrovni celého systému volbou ReadOnly.
• Je možné ho upravit – Tato volba se využívá především v situaci, kdy je napojený systém zároveň zdrojový i koncový. Pokud je váš systém pouze zdrojový nebo pouze koncový, doporučujeme nechávat tuto volbu povolenou. Čtení a zápis pak řídit na úrovni celého systému volbou ReadOnly.
• Standardně je vracen –

Dalším krokem na nastavení mapovaní atributů schématu z předchozí kapitoly.

V první řadě vybereme, pro jaký účel bude mapování sloužit, možnosti máme dvě:

• synchronizace(získání dat)
• provisioning(propagace dat)

Dále je potřeba zvolit, který z nastavených typů objektů chceme pro mapování zvolit. V příkladu tedy vybíráme vytvořené schéma objektu user.

Dále vybereme typ entity v CzechIdM, která bude mapovaná data obsahovat. Může se jednat následující:

• Identita
• Organizační strom

Obrázek 19: Základní nastavení mapování

Nyní přejdeme k samotným atributům objektu, které chceme v nastavovaném mapování využít.

U každého mapovaného atributu máme k dispozici několik možností nastavení.

Strategie plnění,kde vybíráme z následujících možností:

• Sloučit
• Autoritativní sloučení
• Nastavit, tak jak IdM vypočítá
• Nastavit pouze při vytvoření
• Nastavit pouze, pokud je hodnota na systému prázdná

Další možnosti namapovaného atributu jsou:

• Pošli vždy
• Pošli pouze pokud existuje IdM hodnota
• Je identifikátorem
• Atribut entity
• Rozšířený atribut
• Tajný atribut
• Autentizační atribut

Zejména je třeba vybrat, zda se atribut bude mapovat na některý ze standardních atributů zvolené entity, nebo zda se jedná o doplněný rozšiřující atribut. Více o rozšířených atributech je posáno v **této kapitole**.Následně vybereme daný atribut v CzechIdM, se kterých cheme atribut systému namapovat.

Obrázek 20: Tabulka namapovaných atributů

Synchronizace slouží k získání dat z napojeného systému do CzechIdM. Synchronizace standardně reaguje na změnu určeného časového atributu.

Během procesu synchronizace, je pro každý účet vyhodnocena situace, ve které se vzhledem ke stavu v IdM nachází. Základní konfigurací synchronizace je nastavení typu akce, která má být v dané situaci provedena.

Synchronizační situace jsou pevně dané a jsou následující:

• Vazba existuje

V této situaci je možné provést následující akce:

Aktualizovat entitu:Provede aktualizaci identity navázané na účet. Aktualizace se provádí na základě mapování navázaného na synchronizaci. Po uložení entity, dojde vždy k vyvolání standardního provisioningu.

Aktualizovat účet:Provede vyvolání standardního provisioningu. Synchronizace pouze vyvolá událost, samotný provisioning neprovádí.

Odstranit vazbu:Smaže vazbu v CzechIdM. Tzn. odstraní účet a vazby mezi identitou a účtem Neprovádí úpravu samotné identity, nevyvolává provisioning.

Odstranit vazbu a navázané role:Provede odstranění vazeb, jako v předchozím případě, ale navíc odstraní role identity, které jsou navázané na příslušné. Jinak řečeno, odstraní ty role, které daný účet identitě přiřadily.

Ignorovat:Tato akce neprovádí žádnou aktivní operaci.

• Vazba neexistuje

Situace, kdy k danému účtu na systému neexistuje vazba (účet v CzechIdM), ale identita ano.

Protože vazba neexistuje, byla identita v tomto případě nalezena pomocí korelačního atribut. Korelačním atributem může být kterýkoli atribut z navázaného mapování synchronizace (korelační atribut je povinný). V této situaci je možné provést následující akce:

Vytvořit vazbu:Vytvoří vazbu v CzechIdM. Tedy vytvoří účet a vazbu mezi identitou a účtem. Neprovádí úpravu samotné identity, nevyvolává provisioning.

Vytvořit vazbu a aktualizovat účet:Vazba je vytvořena stejným způsobem jako v předchozím případě. Navíc je provedena aktualizace účtu na koncovém systému. To znamená, že. je vyvolána událost pro spuštění provisioningu.

Ignorovat:Tato akce neprovádí žádnou aktivní operaci.

• Entita neexistuje

Situace, kdy k danému účtu na systému neexistuje identita v CzechIdM. V této situaci je možné provést následující akce:

Vytvořit entitu:Vytvoří identitu a vazbu v IdM. Vytvoření se provede podle mapování nastaveného v synchronizaci. Vytvoření entity vyvolá provisioning (aktualizaci účtu).

Ignorovat:Tato akce neprovádí žádnou aktivní operaci.

• Účet neexistuje

Situace, kdy k danému účtu v IdM neexistuje účet na koncovém systému.

K této situaci může dojít v případě, že konektor podporuje operaci DELETE. Tzn. konektor je schopný informovat, jaké účty byly od doby poslední synchronizace smazány na koncovém systému. Typické využití této situace je ovšem v rekonciliaci, kde iterujeme přes všechny účty v CzechIdM a ověřujeme, zdali účet na koncovém systému existuje, pokud ne, je vyvolána nastavená akce. V této situaci je možné provést následující akce:

Vytvořit účet:Synchronizace pouze vyvolá událost pro navázanou entitu, která spustí provisioning, čímž dojde k vytvoření účtu na koncovém systému.

Smazat entitu: Smaže účet v CzechIdM, vazbu mezi účtem a identitou a identitu.

Odstranit vazbu: Smaže vazbu v CzechIdM. Tzn. odstraní účet a vazby mezi identitou a účtem. Neprovádí úpravu samotné identity, nevyvolává provisioning.

Odstranit vazbu a navázané role: Provede odstranění vazeb, jako v předchozím případě, ale navíc odstraní role identity, které jsou navázané na příslušný systém. Jinak řečeno, odstraní ty role, které daný účet identitě přiřadily.

Ignorovat: Tato akce neprovádí žádnou aktivní operaci.

Jde o propis objektů a jejich atributů do koncového systému. Základním typem provisioningu je provisioning Identit, kterým odpovídá objekt účtu v koncovém systému.

Aby mohl proběhnout provisioning, je třeba, aby uživatel měl v CzechIdM roli, která přiděluje daný systém a používá některé jeho mapování atributů. Pro nastavení role je přejdeme na záložku Role, kde vybereme požadovanou roli, která bude grantovat účet v systému například role „LDAP“. Klikneme na detail role pomocí znaku lupa a přejdeme na záložku „Napojené systémy“.

Zde je seznam mapování provisioningu, který je nejčastěji prázdný, případně obsahuje jednu položku. Nebývá zvykem, aby role grantovala přístup do více systémů především kvůli přehlednosti. Pro přidání nového mapování provisioningu k roli klikneme na tlačítko „Přidat“.Máme možnost pracovat s následujícími položkami:

• Role – ReadOnly položka s názvem aktuálně editované role
• Systém – Název koncového systému, do kterého chceme pomocí role provisionovat. Například LDAP – uživatelé.
• Název mapování – Jde o sadu mapování atributů, kterou jsme si dříve definovali pro vybraný systém z předchozího bodu. Kapitola 2.3.3.

Dále je k dispozici sekce „Atributy mapované v rámci této role“. V této sekci lze přetížit vybrané mapování výše tak, aby do atributu objektu poslalo jinou hodnotu, než je ve vybraném mapování. Toho lze využít především tam, kde má některá role přidělovat specifické oprávnění a pochopitelně tedy toto oprávnění nelze nastavit v obecném mapování atributů na celém systému. Jde například o plnění atributu „MemberOf“ v MS Active directory, pokud daná role má uživatele zařazovat do AD skupiny.

Má-li uživatel alespoň jednu roli, která obsahuje tuto konfiguraci mapování atributů pro provisioning, pak je uživatel automaticky provisionován do daného systému kdykoli nad ním vznikne změna libovolného z mapovaných atributů.

Propis dat v CzechIdM je realizován frontou požadavků na koncové systémy. Změní-li se například u Identity některý z jejích atributů a zároveň má identita účet pro některý napojený systém (např LDAP), pak je vyvolán zápis operace CREATE/UPDATE/DELETE do fronty provisioningu. Stejný princip platí pro všechny objekty, které podporují provisioning:

• Identita
• Role
• Organizace (TreeNode)
• Katalog rolí

Na audit provisioningu se lze dostat následujícími cestami

• Audit → Provisioning
• Napojené systémy → detail systému (lupa) → Provisioning – ve skutečnosti je tato cesta pouze zkratkou na předchozí bod, přičemž je předvyplněn filtr „Koncový systém“ na hodnotu podle toho, který systém jsme v menu vybrali. Přecházíte-li z tohoto zobrazení na jinou položku menu a poté zpět přes Audit → Provisioning, mějte na paměti, že filtr zůstává vyplněn původní hodnotou. Tedy neuvidíte celý audit bez omezení. Pro zrušení filtru klikněte na tlačítko Filtr a poté na tlačítko Zrušit filtr.

V obou případech se dostaneme na stejný formulář, který obsahuje dvě záložky

• Aktivní operace – znázorňuje frontu nevykonaných neboli čekajících požadavků na provisioning
• Archiv – zobrazuje již zpracované položky provisioningu

Fronta provisioningu funguje tak, že pokud existuje neprovedená operace pro nějaký objekt, třeba pro uživatele knovak,pak každá další operace pro tento objekt se řadí do fronty. Můžeme tak mít například pro knovak ve frontě následující řadu operací: CREATE, UPDATE, UPDATE, DELETE.

Nejčastějším důvodem pro nevykonání provisioningu je nedostupnost systému, špatně nakonfigurované napojení na systém nebo přepnutí systému do režimu pouze pro čtení. V tom případě operace končí chybou a čeká ve frontě na vykonání. V CzechIdM můžeme tuto operaci provést manuálně tak, že označíme tuto operaci a z listu na výběr akce Operace s vybraným záznamem vybereme námi chtěný úkon. Na výběr máme ze dvou možností

• Opakovat akci
• 

Zrušit akciV obou případech jsme před samotným vykonáním dotázáni, zda chceme opakovat/zrušit celou dávku nebo pouze vybrané. V prvním případě budou ve stejném pořadí jako ve frontě opakovány všechny akce, které se vztahují k dané identitě. Například pro uživatele knovakto budou postupně všechny operace CREATE/UPDATE/UPDATE/DELETE.

Zvolíme-li možnost Opakovat pouze vybrané, pak se v pořadí, v jakém jsou umístěny ve frontě, vykonají/zruší pouze operace, které jsme dříve vybrali. Ostatní zůstanou nezpracovány ve frontě dále. V příkladu identity knovak bychom například vybrali CREATE/UPDATE, které by se v tomto pořadí vykonali/zrušili. UPDATE/DELETE by ve frontě zůstal. Opakování jednotlivých operací vyžaduje znalost napojení koncového systému. Pokud by administrátor například vybral operace, které nadávají smysl – například pouze DELETE, aniž by předtím použil CREATE, skončí toto volání chybou.

V CzechIdM existuje dlouhotrvající úloha (LRT) s názvem RetryProvisioningTaskExecutor, která automaticky spouští frontu provisioningu v předem definovaných intervalech. Je-li tato úloha zapnutá, pak bude CzechIdM periodicky zkoušet provisioning pro operace, které má ve své frontě.

Chcete-li mít dlouhodobou odstávku napojeného systému, doporučujeme tuto úlohu z výkonnostních důvodů dočasně vypnout.

Po kliknutí na znak lupy u každého záznamu ve frontě provisioningu získáme náhled na detail operace. Zejména zde vidíme následující položky:

• Datum vytvoření operace
• Typ entity (Strom/Identita…) a typ operace (Vytvoření/Smazání/Aktualizace)
• Název systému – Název systému, do kterého je provisioning prováděn
• Výsledek – V případě chyby zobrazuje dodatečné informace jako je
  • kód chyby – například PROVISIONINGATTRIBUTEVALUEWRONGTYPE
  • popis chyby – například Provisioning - hodnota atributu není správného typu
  • stacktrace – například eu.bcvsolutions.idm.acc.exception.ProvisioningException: Schema attribute __ENABLE__ defines typ java.lang.String, but value is type java.lang.Boolean!

Z těchto informací jsme často schopni přímo určit povahu chyby. V příkladu výše se zjevně jedná o špatně nastavené schéma pro provisioning, konkrétně je třeba upravit atribut __ENABLE__, aby přijímal Boolean nebo použít transformační pravidlo pro převod Boolean → String.

V detailu operace máme dále k dispozici dvě tabulky

• Idm atributy – tato tabulka zobrazuje všechny atributy, které má systém pro danou entitu nastaven v mapování provisioningu. Například systém LDAP může mít pro entitu Identita nastaveny atributy Name, FirstName, LastName, Titles.Tabulka zároveň obsahuje hodnoty těchto atirbutů, například knovak, Karel, Novák, Mgr.. Tuto tabulku někdy označujeme jako přání,neboli co si přejeme poslat. Hodnoty pro každý z atributů jsou konečné, tedy pokud jejich mapování obsahovalo nějakou transformaci/výpočet, pak je zde již aplikován.
  
  Například pokud by mapování obsahovalo také atribut Manager, tak jeho hodnota by mohla být „CN=John Doe, O = My Company“, která nemusí být nikde v IdM uložena a je počítána právě v tranformaci při provisioningu.
• Atributy pro provisioning – tabulka vpravo obsahuje vybrané atributy a jejich hodnoty, které se opravdu do koncového systému pošlou. Ne všechny atributy je třeba do systému posílat. Zejména se neposílají atributy, jejiž hodnota se v koncovém systému neliší od hodnoty přání(tabulka vlevo). Výjimku samozřejmě tvoří atributy, které označíme v mapování provisioningu jako povinné (required).

Může se stát, že pravá tabulka je prázdná, a to zejména ve dvou případech

• Ve frontě již existuje pro stejnou entitu jiná operace, která má být vykonána dříve. V tom případě IdM z výkonnostních důvodů nepočítá rozdíl mezi přáním a stavem na koncovém systému. Toto by vyžadovalo zbytečnou síťovou komunikaci. Dalším důvodem je, že skutečný stav, který je poslán do systému, se mohl změnit v období, kdy operace čekala ve frontě. Například administrátor změnil hodnotu v koncovém systému. Pak by informace ve frontě byla velmi zavádějící.
• Neexistuje rozdíl mezi hodnotami, které chce poslat IdM a hodnotami v napojeném systému. Zároveň však pochopitelně nesmí být žádný atribut v mapování provisioningu označen jako povinný (required).

Workflow reprezentují v CzechIdM nějaký proces – například Nová Identita, Nástup na mateřskou dovolenou. V podstatě se jedná o spustitelnou část aplikace, která tyto procesy realizuje. Z hlediska architektury se vlastně jedná o stavový automat, který v jednotlivých svých stavech vykoná nějakou předem definovanou akci. Například při vytvoření nové identity pošle email na nadřízeného. Nebo při odchodu zaměstnance vytvoří úkol na IT pro odebrání všech přístupů.

Všechna spuštění těchto workflow jsou evidována do auditního logu v menu Audit → Historie workflow. Název instance workflow je vždy tvořen názvem samotného forkflow a nějakou proměnnou, která nejčastěji definuje, pro který objekt je tato instance spuštěna. Například dle názvu Change permissions request for "Administrator" je zřejmé, že se jedná o workflow obsluhující žádost o změnu oprávnění a v této instanci bylo spuštěno pro uživatele „Administrátor“. Hodnoty proměnných v názvu workflow jsou zpravidla uvozeny uvozovkami.

Název workflow často obsahuje i názvy entit. Například pokud do filtru pro tento formulář vložíme do pole Názevhodnotu Administrator, pak získáme všechna workflow, která se týkala tohoto uživatele.

Naopak, pokud do pole pro Název vložíme „Change permissions request“, pak získáme všechny workflow pro žádost o změnu oprávnění pro všechny uživatele.

V této kapitole budeme připojovat vzorový systém jako zdroj identit. Využijeme základní Database Table Connector. Zdrojová tabulka, kterou budeme používat, má 4 sloupce: id, username, jmeno, prijmeni.

Nejprve na záložce Napojené systémy stiskneme tlačítko přidat. Zvolíme libovolný název systému, například Some base. Zaškrtneme volbu ReadOnly – naše databáze bude zdroj dat, nechceme do ní zapisovat. Ostatní atributy systému necháme ve výchozím stavu. Nakonec klikneme na Uložit a pokračovat.

Přejdeme na záložku Konfigurace a zde vybereme konektor Database Table Connector (connId).Dále zadáme cestu k DB a přihlašovací údaje uživatele, kterým bude CzechIdM do DB přistupovat. Uživatel v databázi musí mít právo alespoň pro čtení z napojené tabulky. Konkrétně jsme v našem příkladu vyplnili:

• Host = localhost – DB nám běží na stejném serveru jako IdM
• Port = 5432 – standardní port pro PostgreSQL
• User = idmadmin – dříve vytvořený uživatel v DB s dostatečným oprávněním na čtení dat
• User Password = %%%%%%%%* - zde je hodnota hesla pro DB uživatele zadaného v předchozím kroku
• Table = users – v DB jsme si předpřipravili tabulku s názvem users,ze které budeme synchronizovat uživatele do CzechIdM
• Key Column = id - Database Table Connector (connId)vyžaduje explicitní vyznačení sloupce, který je v DB použit jako unikátní identifikátor. Typicky se jedná o primární klíč tabulky.
• JDBC Connection URL = jdbc:postgresql://localhost:5432/Somebase – udává cestu k DB
• JDBC Driver = org.postgresql.Driver – konektor podporuje více různých typů relačních databází. V našem případě napojujeme DB PostgreSql. Pro napojení je třeba v CzechIdM nastavit ovladač, který zajistí operace s daným typem databáze.

V době psaní tohoto návodu lze driver pro PostgreSql stáhnout zde https://jdbc.postgresql.org/download.html

Kromě nastavení v konfiguraci systému v CzechIdM je potřeba soubor s ovladačem umístit do umístění pro knihovny aplikačního serveru. V našem případě běží CzechIdM v AS Tomcat, tedy driver umístíme do složky lib. Případně můžeme umístit driver do WEB-INF/lib přímo v umístění aplikace CzechIdM.

Ostatní atributy konektoru necháme nevyplněné nebo s výchozí předvyplněnou hodnotou.

Pokud jsme vše správně nastavili a CzechIdM má přístup do naší DB, můžeme konfiguraci ověřit kliknutím na zelené tlačítko Test konektoru na začátku stránky.

Přejdeme na záložku Schéma systému (popsáno v kapitole 2.3.2) a klikneme na tlačítko Generovat schema. Konektor nám automaticky vrátí seznam dostupných atributů na napojovaném systému. Objekt vrácený z konektoru je ve výchozím stavu typu __ACCOUNT__, což nám pro napojení identit vyhovuje. Dále konektor vrátil podle očekávání 4 atributy dle našich sloupečků v DB. Ty zobrazíme kliknutím na obrázek lupy vedle typu objektu.

Navíc nám konektor ale vrátil atribut __NAME__, který je definován standardem ConnId. Námi použitá implementace Database Table Connector (connId) se této specifikace drží, avšak pro synchronizaci jej nepoužívá, proto pro naše načítání dat ze zdrojového systému jej nebudeme potřebovat.

Kliknutím na lupu vedle názvu atributu je možné zobrazit detaily konfigurace pro konkrétní atribut.

V našem případě mají všechny atributy stejnou konfiguraci až na atribut id a __NAME__, které jsou označeny jako povinné.

Máme-li připravené schéma systému, pak přikročíme k mapování synchronizace. To nám umožní určit, jaké atributy z dostupného schématu nasynchronizujeme do IdM a také do kterých atributů Identity se budou atributy z účtu plnit.

Na záložce mapování atributů stiskneme tlačítko Přidat.Vyplníme

• Typ operace = Synchronizace
• Název mapování = users – naše označení této sychronizace. Systém může mít více různých synchronizací.
• Název objektu = %%ACCOUNT%% - typ objektu, který chceme synchronizovat.
• Typ IdM entity = Identita – typ entity, na kterou se bude mapovat typ objektu vybraný v předchozím bodu.

Po vytvoření mapování klikneme na detail tohoto mapování a nastavíme konkrétní vazby atributů účtu na atribut identity. Nastavíme mapování pro všechny naše atributy id, name, surname, username.

Například atribut id nastavíme dle následujícího obrázku. Ostatní atributy nastavím stejně až na položky

• Je identifikátorem, která je zaškrtnuta pouze pro id.
• Atribut entity – říká, že atribut ze systému pošleme k základnímu atributu entity v CzechDIM. Vyplníme jej u všech položek kromě id.
• IdM klíč – definuje který atribut entity v CzechIdM bude daný atribut ze systému plnit. Tato volba je dosupná pouze pokud jsme předtím zaškrtli volbu Atribut entity. Dle obrázku výše namapujeme atributy name, surname a username na atributy v CzechIdM firstName, lastName a username.

Jak je vidět, ne všechny atributy musíme mapovat na atribut v CzechIdM. Ty, které nenamapujeme, nebudou vyplněny k entitě v CzechIdM. V našem případě se k entitě nepřenese id, které nechceme dále využívat, ani jej neplánujeme posílat do spravovaných systémů.

V našem příkladu jsme namapovali atributy účtu na systému na základní atributy Identity. Každá entita v CzechIdM má základní sadu atributů, které však lze rozšířit. Chceme-li v synchronizaci namapovat atributy na rozšířené atributy entit v CzechIdM musíme mít nejprve přichystán formulář EAV atributů pro danou entitu, viz kapitola 2.10.

V předchozí kapitole jsme si připravili mapování atributů pro synchronizaci. Nyní nastavíme samotný proces synchronizace, který toto mapování bude používat.

Přejdeme na záložku Synchronizace a klikneme na tlačítko přidat. V synchronizaci vyplníme název a povolíme ji dle obrázku. Rekoncilace můžeme zaškrtnout také, budeme načítat všechny účty bez omezení. Do sady mapovacích atributů vybereme mapování users, které jsme si vytvořili v minulé kapitole.

Dále přejdeme ve formuláři až k nastavení operací pro jednotlivé stavy účtu a entity a nastavíme následujícím způsobem:

• Vazba existuje, akce = Aktualizovat entitu – Tím zajistíme, že při opakovaném běhu synchronizace, kdy jsou již v CzechIdM uloženy vazby účet (koncový systém) – identita (CzechIdM), budou přeneseny změny účtů do entity v CzechIdM
• Vazba neexistuje, korelační atribut = id, akce = Vytvořit vazbu – Tím zajistíme, že při opakovaných bězích se prolinkují všechny účty a entity, které mají stejné id.
• Entita neexistuje, akce = vytvořit entitu - Tím zajistíme, že při všech bězích se nám v CzechIdM vytvoří entity, které tam do té doby neexistovaly, dle účtů na systému.
• Účet neexistuje, akce = Ignorovat – Nechceme provádět žádnou akci, pokud existuje entita v IdM a účet neexistuje. Systém je pro nás pouze zdroj dat.

Položky Workflow necháme nevyplněny, ty slouží pro pokročilé skriptování u jednotlivých akcí.

Na podzáložce Filtr nenastavujeme nic, nechceme omezovat synchronizaci pouze na některé účty. A záložka Logy je pouze informativní a obsahuje auditní log synchronizace.

Pokud jsme úspěšně prošli nastavením v předchozích kapitolách, můžeme nyní přistoupit ke spuštění samotné Synchronizace. Přejdeme na záložku Napojené systémy, vybereme náš nakonfigurovaný systém a přejdeme na záložku Synchronizace. Synchronizaci spustíme zeleným tlačítkem se znakem trojúhelníku na konci řádku s konfigurací synchronizace.

Běžící synchronizace mají vyplněn sloupeček Běží. Pokud přejdeme na detail běžící synchronizace (kliknutím na znak lupa) a poté přejdeme na záložku Logy, vidíme přehled všech synchronizací, včetně aktuálně běžících.

A virtual system is not directly connected for online management. The virtual system is basically only a registration mode, where for each system change is generated the implementation request (notification) that is assigned to the particular administrator. This administrator must provide that the change is made to the target system. In other words, IdM "knows" what the user should have on the system for accounts and permissions, but on the real system this is executed by the implementer (administrator). The reason may be the need to manage a large number of systems without the need for demanding integration.

• In left menu select 'Virtual systems / List' and click on Add.

You can fill:

• Name for virtual server e.g. 'NewVirtualSystem'
• Implementers - users, whom will be receiving requests for updating real system
• Roles with implementers - users with assigned these roles will be receiving requests for updating real system

Beware: Users/roles have to have permission 'Requests on virtual systems (VsRequest)' to receive these requests.

We have created new virtual system. Now we will assign system to some users. For this we create new role and create mapping for our new virtual system.

• In the left menu select Roles. Click on 'Add' green button to create new role.
• You have to only fill name for your new role e.g. 'RoleForNewVirtualSystem'.
• Click on 'Save and continue'.

• In details of our new created role, select tab 'Systems'
• Click on 'Add' green button.
• In 'System' field select our virtual system, on picture it is 'NewVirtualSystem'.
• In 'Mapping' field select 'Default provisioning (Identity - Provisioning)'.
• and click on 'Save'

We will create new user and assign him our role, so he will be provisioned to our new virtual system.

• in left menu select 'Users'
• Click on 'Create user' green button
• Fill Login, First name and Surname (e.g. 'john.doe', 'John', 'Doe').
• Click on 'create and edit'.
• On user detail click on tab 'Roles'.
• Click on 'Manage authorization'.
• On new dialog add new role. Click on 'Add' green button.
• In field 'Role name' select our role 'RoleForNewVirtualSystem'.
• Click on 'Set'.
• Click on 'Submit a request'.
  

Implementers received new task to create new account 'john.doe' on virtual system 'NewVirtualSystem'. You can check request In left main menu select 'Virtual systems / Request'. There are two tabs 'Unresolved requests' and 'Archive'. In 'Unresolved requests' there is list of all tasks, which yet will be resolved.

If you did previous tutorial, you have here this request. You can go to detail of request with UID 'john.doe' and system 'NewVirtualSystem' (click on button with "magnifying glass"). And you can now see detail of request for creating new account.

There are three specific information:

• Basic information for the request (state, UID, system, type, created ).
• Implementers - All implementers whose can resolve the request. In implementers there are all by directly selecting and all with assigned roles (Implementers can be set in creation of virtual system or in detail of virtual system).
• Target state on system - Table show how should looks account on target system. In the table are only changes from the request (not from previous/next unresolved requests). For 'create' request type are all rows marked as changed (orange color). Generally this table shows state on CzechIdM against state on virtual system, in this situation show "True" without merge with others unresolved requests.

If we do not resolve create request and edit our user 'john.doe', e.g. change surname to Doe. In 'Unresolved requests' There is new update request. Click detail of update request.

• Request detail shows same information as in previous 'create' case, but for update single attribute. Because previous 'create' request was not realized yet, is shows only one row. If 'create' request is resolved, then shows all attributes of the account with one changed attribute.
• Request detail can show previous and next unresolved request (for same account). For this case is shows table with one previous request (or know 'create' request).

When we finally resolve our two requests, there are moved to tab 'Archive'.

Realize request

• Operation realize can by started in table 'Unresolved requests' or in request detail.
• After this operation all changes from this request are propagated to data structure of virtual system.
• Request is moved to 'Archive'

Cancel request

• Operation realize can by started in table 'Unresolved requests' or in request detail.
• For this operation is required to fill the reason. Reason is shown on archived request detail.
• After this operation all changes from this request are discarded.
• All unresolved requests made after this canceled request on the same account are canceled as well.
• Request is moved to 'Archive'

• For show request agenda is required 'VsRequest' permission.
• For show requests only for assigned implementers, you have to set evaluator 'VsRequestByImplementerEvaluator'. With this evaluator can user show and edit requests where is implementer (directly or from roles).

After request for updating virtual system is created, notification is sent to all implementers.

As default was implemented email notification 'vs:vsRequestCreated' for new virtual system request. This notification is by default automatically connected to this topic. Template for this notification can be modified in left main menu 'Notifications / Templates'.

Email template provides similar informations as request detail (described above). For example 'Target table' is constructed from same data as table on request detail. Below is examples of notification emails send during process create and modify account 'john.doe' and notification, which show change of multivalue attribute.

Email notification for create new account 'john.doe':

Email notification for modify account 'john.doe':

Email notification for modify multivalue attribute 'ldapGroups' for account 'john.doe'.

To the attribute was added new values 'E,F' and removed values 'C,B':