Identity manager – jak funguje propojení konektor / cache / vyhledávání

Tento příspěvek vzniknul úpravou dotazu a mé odpovědi na webu http://www.abclinuxu.cz

Jak to v Identity Manageru (IdM) vlastně pořádně funguje? Jak jsou načítány a ukládány údaje z koncových systémů? Dejme tomu že mám uživatele v Active Directory či nějaké SQL databázi. Každý uživatel může mít několikrát definován nějaký atribut (třeba skupina). Když k tomu budu chtít připojit Identity Manager, jak se s těmito atributy vypořádá?

Popíšu způsob, jak tuto problematiku řeší naše CzechIdM a také Sun IdM (Oracle Waveset).

Při konfiguraci každého systému se definuje mapování skutečných názvů atributů účtu na „abstraktní“ názvy, se kterými pracuje IdM. Pokud k IdM připojíme například LDAP, který bude mít účty s atributem „group“ a také nějakou relační databázi, kde se bude odpovídající atribut jmenovat „skupina“, můžeme každý z těchto atributů namapovat na stejný název „userGroup“.

Identity manager se pak bude snažit tyto atributy synchronizovat tak, aby měly stejnou hodnotu. Samozřejmě záleží na tom, který z obou systému je pro tento atribut autoritativním zdrojem a tedy svojí hodnotou přepíše tomu druhému.

Pokud tyto atributy nemají mít stejnou hodnotu, tak musí být každý z nich namapován na rozdílný název. Například „group“ -> „ldap_userGroup“ a „skupina“ na „db_userGroup“. Pak lze tyto atributy nastavovat nezávisle na sobě.

Pokud budu chtít vyhledávat podle nějakého atributu, tak musí mít IdM vlastní keš? Vytváří si IdM takovou keš nebo kešuje jen „neduplicitní“ atributy příp. jak umí vyhledávat v záznamech bez keše?

Pokud jde o keš, tak CzechIdM ani Sun IdM ve standardním nastavení nestahují atributy do svého úložiště. Všechny data nechávají na systémech a pouze propagují změny z jednoho systému na jiný (tomu se říká provisioning). Jediné co si tyhle Identity Managery uchovávají je informace, které identitě (uživateli) patří který účet a dále pak jméno a email. Tyto informace je ale možné rozšířit o tzv. extended atributes. Pokud tedy víte, že budete často vyhledávat podle atributy „homeDirectory“ v systému AD, tak nastavíte IdM tak, aby si tento atribut ukládal ve své repository. Pak je možné pomocí něho snadno vyhledávat.

Vyhledávat je možné i podle atributů, které nejsou kešované v IdM. Ale tam hodně záleží na tom, zda to konkrétní konektor nebo adaptér použitý pro připojení k systému umožňuje.

Například v Sun IdM lze za tímto účelem použí metodu ze třídy com.waveset.ui.FormUtils

 

public static java.util.List getResourceObjects(
         com.waveset.object.LighthouseContext session,
         java.lang.String objectType,
         java.lang.String resourceId,
         java.util.Map options)

 

Do parametru „options“ se pak nadefinuje patřičný „searchFilter“.

Dále pokud bych si potřeboval napsat vlastní konektor – jaké datové typy to obecně podporuje? Co kdyby byl nějaký binární atribut – třeba certifikát či uživatelská fotka uložená v blob v SQL db?

O tom jak si napsat vlastní konektor, který používá jak CzechIdM tak Sun IdM, se lze dočíst v tomto článku, který napsal kolega: Vývoj identity konektoru pro systém CzechIdM. Pro rychlou informaci jen napíšu, že binární data nejsou nejmenší problém.