Tato webová stránka používá soubory cookie, abychom vám mohli poskytovat co nejlepší uživatelský zážitek. Informace o cookies jsou uloženy ve vašem prohlížeči a plní funkce, jako je rozpoznání, když se vrátíte na náš web, a pomoc našemu týmu pochopit, které části webu jsou pro vás nejzajímavější a nejužitečnější.
Novinky
Více než 30 IDM realizací v České republice i zahraničí

Tři tipy pro IdM midPoint
Předpokládáme, že čtenář tohoto článku má obecné znalosti o identity managementu a že zná produkt midPoint.
Příklad 1: Rozšířené požadavky na politiku hesla
Každý, kdo již někdy u zákazníka implementoval IdM, se jistě setkal s požadavky na tvorbu bezpečných uživatelských hesel. Typickými podmínkami jsou: Minimální délka hesla, periodicita změny hesla, vyžadované znaky, zakázané znaky apod. Všechny tyto podmínky lze v midPointu bez problémů konfiguračně nastavit.
Zákazník ovšem může vyžadovat nastavení dalších, méně obvyklých pravidel pro tvorbu hesla. Jedním z takových může být požadavek, aby heslo neobsahovalo aktuální login uživatele (bez ohledu na malá/velká písmena). Takové pravidlo lze konfiguračně jen těžko nastavit a midPoint ho v aktuální verzi 3.5 ani neobsahuje. Ovšem není třeba házet flintu do žita, neboť si ukážeme, jak si takové pravidlo vyrobíme, a to doslova na několika řádcích kódu. Všimněte si, že nebudeme upravovat žádný „hotový“ zdrojový kód javy midPointu, ale použijeme podporovaný a zdokumentovaný postup v mappingu tzv. „uživatelské šablony“ (user template), do kterého náš kód vložíme. Výhody tohoto postupu jsou zřejmé – takový kód nám bude fungovat i ve všech budoucích verzích midPointu. Při pozdějším upgrade se tedy nemusíme o námi vložený kód starat a postupujeme podle dokumentace. Jestliže bychom naopak změnili kód přímo ve zdrojovém kódu midPointu, museli bychom při každém budoucím upgrade řešit spojení našeho kódu s kódem nové verze, což může přinést spoustu komplikací.
Pojďme se nyní podívat, jak elegantně lze tento požadavek v midPointu vyřešit.
Část objektu, která zajišťuje kontrolu hesla proti loginu – mapping v user template
<mapping>
<name>Check Pwd against Login</name>
<source>
<c:path>$user/name</c:path>
</source>
<expression>
<variable>
<name xmlns_my=“http://whatever.com/my“>my:cryptPwd</name>
<c:path>$user/credentials/password/value</c:path>
</variable>
<script> <language>http://midpoint.evolveum.com/xml/ns/public/expression/language#Groovy</language>
<code>
import com.evolveum.midpoint.model.api.PolicyViolationException;
// kontrola hesla proti loginu – pokud heslo obsahuje login, generujeme výjimku
if(basic.lc(basic.decrypt(cryptPwd)).contains(basic.lc(basic.stringify(name)))) {
throw new PolicyViolationException(„Heslo nesmí obsahovat Váš login!“);
}
</code>
</script>
</expression>
</mapping>
Příklad 2: Mapování hodnot
Dalším požadavkem, se kterým se může vývojář implementující IdM setkat, je požadavek na mapování jednoho seznamu hodnot na jiný. Typickým příkladem jsou například kódy jazyků a jejich názvy (cs_CZ – Čeština, en_US – Angličtina, sk_SK – Slovenština, …), kódy pracovišť a jejich názvy (PHA – Praha, BNO – Brno, OVA – Ostrava, …) a podobně.
Představme si, že zákazník má ve zdrojové aplikaci HR uvedené třípísmenné kódy pracovišť zmíněné výše, ale do jiné aplikace je musíme převést do odpovídajícího plného názvu.
Jednou z možností, jak toto provést, je „natvrdo“ napsat kód s podmínkami, které budou převádět jednotlivé třípísmenné kódy na plné názvy pracovišť. To má samozřejmě spoustu nevýhod – nepřehlednost, nutnost změny kódu vývojářem při vytvoření/zrušení pracoviště a nemožnost upravovat seznam kódů zákazníkem.
Daleko elegantnější cestou v midPointu je použití tzv. „Lookup Table“ – překladové tabulky. Taková tabulka obsahuje dvojice klíč – hodnota se kterými je možné dále pracovat a volat je z programového kódu. Výhody jsou nasnadě – při vzniku či zániku pracoviště se pouze upraví odpovídající záznam v překladové tabulce. Tabulku může udržovat i sám zákazník (není k tomu třeba vývojář) a není nutné stále upravovat zdrojový kód pro převod.
Níže si ukážeme, jak by mohl takový kód pro převod pracovišť a jejich třípísmenných zkratek vypadat. Jednotlivé příkazy jsou vysvětlené přímo v komentářích u zdrojového kódu.
Část tabulky “lookup-pracoviste” s mapováním pracovišť
<row>
<key>PHA </key>
<label>Praha</label>
</row>
<row>
<key>BNO</key>
<label>Brno</label>
</row>
Část objektu, která zajišťuje mapování kódů pracovišť na jejich plné názvy – mapping v user template.
<mapping>
<expression>
<script>
<code>
import com.evolveum.midpoint.xml.ns._public.common.common_3.LookupTableRowType;
import com.evolveum.midpoint.xml.ns._public.common.common_3.LookupTableType;
import com.evolveum.midpoint.schema.GetOperationOptions;
import com.evolveum.midpoint.schema.RelationalValueSearchQuery;
import com.evolveum.midpoint.schema.RelationalValueSearchType;
import com.evolveum.midpoint.schema.SelectorOptions;
// default hodnota navratové proměnné
ret = ‚neznámé pracoviště‘;
// definice dotazu a options dotazu, defaultní pracoviště je Praha
query = new RelationalValueSearchQuery(LookupTableRowType.F_KEY, ‚PHA‘, RelationalValueSearchType.EXACT);
options = SelectorOptions.createCollection(LookupTableType.F_ROW, GetOperationOptions.createRetrieve(query));
// získání objektu lookup tabulky
LookupTableType lookup = midpoint.getObject(LookupTableType.class, ‚lookup-pracoviste‘, options);
// získání řádku tabulky
lookupRow = lookup.getRow();
// otestujeme, zda řádek tabulky vůbec existuje
if (lookupRow.size() > 0) {
// řádek existuje, získáme popis a nastavíme proměnnou
ret = basic.stringify(lookupRow[0].getLabel());
}
// vrátíme hodnotu proměnné – buď neznámé nebo nastavené z tabulky
return ret;
</code>
</script>
</expression>
<target>
<path>fullNameLocality</path>
</target>
</mapping>
Příklad 3: Našeptávač v uživatelském formuláři
Třetím typickým požadavkem, se kterým se může vývojář implementující IdM setkat, je požadavek zákazníka na vytvoření našeptávače u položek v uživatelském formuláři v GUI IdM. Příkladem může být například možnost vybrat si kliknutím myši ze seznamu jazyků, ze seznamu pracovišť či z lokalit. Výhodou našeptávače je (kromě zvýšení pohodlí uživatele) i minimalizace překlepů při zadávání.
Implementace této funkcionality je v midPointu velmi jednoduchá. Opět použijeme zdokumentovaný a podporovaný postup a vyhneme se jakékoliv úpravě zdrojového kódu midPointu. Pro vyřešení požadavku využijeme tzv. „Lookup Table“ – překladovou tabulku, o které jsme se zmiňovali v druhém příkladu, a vytvoříme našeptávač pro výběr jazyka.
Část tabulky „lookup-languages“ s mapováním jazyků
<row>
<key>cs</key>
<label>Čeština</label>
</row>
<row>
<key>en</key>
<label>Angličtina</label>
</row>
Část objektu, která zajišťuje načtení jazyků z tabulky a jejich zobrazení v našeptávači – item v user template
<item>
<ref>preferredLanguage</ref>
<displayName>Jazyk</displayName>
<valueEnumerationRef oid=“lookup-languages“/>
</item>
Závěr
V tomto článku jsme si na příkladech ukázali řešení tří typických uživatelských požadavků v identity manageru midPoint od společnosti Evolveum. Ačkoliv se na první pohled jednalo o vcelku složité požadavky, bylo jejich řešení v midPointu otázkou několika málo řádků kódu. Ani v jednom případě jsme nemuseli upravovat přímo původní zdrojový kód IdM (ačkoliv tu možnost v případě midPointu také máme a licence nám to dovoluje), ale použili jsme zdokumentovaný a doporučený postup úpravou XML objektů. To dokazuje obrovskou sílu tohoto nástroje a také lehkost, se kterou ho lze u zákazníků implementovat.
Autor: Roman Pudil pracuje jako solution architect v oblasti IdM ve společnosti AMI Praha.