Archiv pro štítek: CzechIdM

Seznam podporovaných systémů CzechIDM

K CzechIdM je možné připojit libovolný systém, který je dostupný po síti a je známa struktura identit. CzechIdM umožňuje spravovat uživatelské účty na vzdálených systémech prostřednictvím vhodných konektorů. Jedná se o komunikační rozhraní využívající standardní protokoly ke komunikaci se spravovaným systémem.

Děláme Identity Management přes 10 let, dříve jako konzultanti, 6 let pod vlastní firmou. Začali jsme s pevnou sadou konektorů, kterou postupně rozšiřujeme, vyvíjíme si i vlastní. Většinu informačních systémů na trhu jsme již připojovali a aktivně je naše Identity Managery spravují.czechidm

Pokud konektor  pro správu koncového systému nemáme, využijeme některý obecný nebo jej na míru vyvineme. U složitějšího systému, jako je  například SAP, je náročnost vlastního vývoje odpovídacící pracnosti v nižších jednotkách dní vývojáře.

Zde je seznam nejčastěji připojovaných systémů

Veřejné správa a samospráva – agendové systémy a spisové služby :
  • Marbes Proxio
  • Gordic Ginis
  • ICZ eSpis
  • ICTBrains Matrix
  • BBM iFIS – finanční řízení
  • Vera
Akreditované certifikační autority v ČR:
  • eIdentity.cz
  • Postsignum.cz QCA
Doménové řadiče a adresářové služby:
  • Microsoft Active Directory
  • Kerberos
  • OpenLDAP
  • Novell eDirectory
  • Red Hat Directory
Mailové systémy:
  • MS Exchange
  • Office 365
  • Linux postfix
  • Communigate
Databáze:
  • Microsoft SQL Server
  • MySQL
  • Oracle
  • PostgreSQL
  • Progres
  • Sybase
Operační Systémy:
  • HP-UX
  • Linux distribuce bez omezení – Red Hat, Debian, SuSE,…
  • Microsoft Windows všech verzí
  • Solaris
  • S/400
Personalistiky:
  • HRIS
  • Mysys HRMS
  • Navision
  • SAP
  • Vema
  • Helios
Web Single Sign On (SSO) a Access Management:
  • OpenAM
  • IBM/Tivoli Access Manager
  • Oracle Acces Manager
  • Sun Java System Access Manager
  • Kerberos
Zdravotnické systémy:
  • StaproMEDEA NIS
  • StaproPANAKEA
  • OpenLIMS
  • LEKIS
  • TESCO SW FaMa

Ostatní:

  • různé LDAPy
  • Plone
  • SAMBA

 

Pokud jste níže nenašli svůj systém, nezoufejte, seznam není kompletní. Napište nám na info@bcvsolutions.eu, zašleme Vám ínformaci jak je pracné Váš systém napojit.

Zhodnocení roku 2014 a plány na rok 2015

Rok 2014 byl pro nás obrovskou lekcí. Hlavně díky tomu, že jsme dlouho čekali na nové zakázky. To se nám stalo poprvé od startu firmy a donutilo nás to udělat hodně změn, které nakonec měly velmi pozitivní dopad na fungování firmy.

Druhá polovina roku byla opakem, naprostým úspěchem. Získali jsme nové zákazníky, tým vývojářů a konzultantů se rozjel a nasazovali jsme do produkce jeden systém za druhým. Uspořádali jsme úspěšný workshop na CzechPAM, kterým nám zajistil nové zákazníky. Splnili jsme si sen – vydali naše CzechIdM jako Opensource. Aktuálně máme nejvíce projektů od začátku firmy.

Co se podařilo v roce 2014:
  • Zveřejnili jsme náš produkt CzechIdM jako Opensource, což nás zviditelnilo a přineslo zákazníky.
  • Máme nový produkt CzechPAM. Střihli jsme si vývoj od základu a to poměrně velmi rychle. Produkt je velmi uživatelsky sexy.
  • Uspořádali jsme úspěšný workshop CzechPAM, který jsem si opravdu užil. S účastníky dále spolupracujeme.
  • Spravujeme jako firma nejvíce účtů pomocí IdM v ČR, vyjma datových schránek.
  • Udělali jsme mnoho vylepšení v CzechIdM – vytvořena standardní synchronizace, což je pecka funkce. Admin si sám může naklikat synchronizaci mezi napojenými systémy.
Cíle na rok 2015 – dominovat v ČR v identity managementu :-)
  • Dodat nejvíce IdM projektů najednou.
  • Růst obratu o 20%.
  • Pravidelně publikovat do blogu – 4xměsíčně.
  • Release nové verze CzechIdM 2x do roka. Zrychlit CzechIDM a zpříjemnit pro uživatele. Zavést automatizované testování GUI.

Osobně se mi podařilo pořádně se rozběhnout, za rok jsem zaběhl 927km. Na tento rok plánuji překonat 1000km.

Přeji mnoho úspěchů v novém roce.

Automatické přidělování rolí

Role v CzechIdM představují balík oprávnění identity ke koncovému systému nebo přímo CzechIdM (admin role). Role lze přiřazovat ručně, například pomocí webového GUI, nebo pomocí workflow a pravidel. Mým úkolem bylo implementovat nový způsob přiřazování rolí – automatické přidělování rolí, které lze použít v průběhu standardní rekoncilace/synchronizace. Dále se v článku dozvíte, jak byla tato nová funkcionalita v CzechIdM implementována a jak automatické přidělování rolí konfigurovat a spouštět.

Automatické role

Nejprve je třeba definovat, co jsou to automatické role. Nově v CzechIdM mají všechny role, včetně admin rolí, atributy, které slouží primárně pro rozhodování, komu danou roli při automatickém přiřazení přidělit. Počet těchto atributů je napevno stanoven na 10 a jsou jednoduše pojmenovány attribute1 až attribute10. Role je automatická právě tehdy, když má vyplněný alespoň jeden tento atribut – hodnota atributu není null a nebo prázdný řetězec.

Pro přiřazování automatických rolí byly definovány 4 nové užitečné metody nad třídou Data.

  • GetAutoRoles() – metoda používá aktivní UserView a pro daného uživatele vrací seznam automatických rolí, které splňují podmínky přidělení v příslušných atributech rolí.
  • AssignAutoRolesExpUsers() – na základě explicitně předaného seznamu uživatelů těmto přiřadí odpovídající automatické role.
  • AssignAutoRolesExpRoles() – na základě explicitně předaného seznamu rolí vyhledá odpovídající uživatele a těmto přiřadí odpovídající automatické role.
  • AssignAutoRoles() – pro všechny uživatele v systému přiřadí odpovídající automatické role.

Pomocí těchto metod lze například ve workflow nebo pravidlech jednorázově přiřadit automatické role uživatelům.

Konfigurace automatického přiřazení rolí

Předtím, než je možné přikročit k samotnému procesu automatického přidělování, je potřeba provést konfiguraci podmínek, které musí uživatelé splňovat, aby jim byla automatická role přidělena.

Podmínky je možné si představit jako trojici:

Atribut:Relace:Hodnota atributu

  • Atribut je název uživatelského atributu, například „tel“
  • Relace je vztah mezi názvem a hodnotou atributu, v současnosti lze vybírat z equal (EQ), not equal (NEQ) a like (LIKE)
  • Hodnota atributu je vypovídající, například „+420 540 123 456“

Konfigurace podmínky probíhá ve dvou krocích. První část konfigurace je umístěna v pravidle getAutoRolesAttributes. Pravidlo tedy editujeme, nejjednodušeji pomocí webového rozhraní. Pravidlo getAutoRolesAttributes obsahuje definici DTO, které představuje první část podmínky pro automatické přidělování rolí. Pravidlo má následující strukturu:

DTO roleAttrs = new DTOGroup();
 DTO attr1 = new DTOGroup();
 attr1.put(Constants.AUTO_ROLE_ATTRIBUTE_NAME, "tel");
 attr1.put(Constants.AUTO_ROLE_ATTRIBUTE_RELATION, RoleAttrRelation.EQ);
 …
 DTO attr10 = new DTOGroup();
 attr10.put(Constants.AUTO_ROLE_ATTRIBUTE_NAME, "");
 attr10.put(Constants.AUTO_ROLE_ATTRIBUTE_RELATION, RoleAttrRelation.EQ);
 …
 roleAttrs.put(AutoRoleAttr.EQ.name(), RoleAttrEq.OR);

Na řádku attr1.put(Constants.AUTO_ROLE_ATTRIBUTE_NAME, "tel"); jako druhý argument funkce attr1.put() vyplníme název atributu uživatele, například „tel“. Na následujícím řádku se vyplňuje Relace, v příkladu je RoleAttrRelation.EQ, který reprezentuje rovnost řetězců. Jak je vidět, lze nastavit až 10 podmínek pro přidělování rolí, přičemž logický operátor mezi jednotlivými podmínkami je ve výchozím stavu OR, jak je vidět na posledním řádku z příkladu.

Nyní máme tedy nastavenou první část podmínky Atribut:Relace:Hodnota a chybí nám ještě poslední část samotná hodnota atributu. Tu nastavujeme do již představených atributů rolí Attribute1 až Attribute10, přičemž pořadí atributů odpovídá řádkům v pravidle getAutoRolesAttributes. Toto můžeme nastavit pomocí webového GUI:

auto_config

Nyní máme již nastavené podmínky pro automatické přidělování rolí. Spuštění automatického přidělování rolí může probíhat automaticky při standardní rekoncilaci/synchronizaci. Pomocí GUI lze nastavit, kdy bude tato funkcionalita aktivní.

synch_conf

Omezení

Je třeba zdůraznit, že automatické přidělení rolí proběhne pouze při změnách uživatelské identity (update, vytvoření). Tedy vždy pouze pro určité stavy a akce. Jsou to tyto:

  • Assigned – UPDATE_IDENTITY
  • Matched – LINK_ACCOUNT_AND_UPDATE
  • Missing identity – CREATE_IDENTITY
  • Missing identity – CREATE_IDENTITY_AND_UPDATE

Automatické role mají určitá omezení, která je třeba mít na paměti při konfigurování. Zejména lze přiřazovat role pouze na základě atributů datového typu String. Například nelze použít pouze název atributu „homeOrganisation“ nebo „disabled“.

Dále je třeba počítat s tím, že jednotlivé podmínky jsou vzájemně spojeny logickým operátorem OR. Návrh automatických rolí počítá s pozdějším přidáním dalších logických operátorů jako je AND, nicméně v současné podobně je jedinou volbou OR.

Závěr

V tomto článku jsem představil novou vlastnost CzechIdM – automatické přiřazování rolí. Byly definovány automatické role, ukázány možnosti konfigurace automatického přiřazení rolí a také omezení pro tuto novou funkcionalitu. Možnosti využití jsou jistě širší, než je schopen pojmout tento článek, proto se můžete těšit na pokračování, kde budou představeny širší možnosti konfigurace automatických rolí. Pro jakékoli dotazy mě můžete kontaktovat na marcel.poul@bcvsolutions.eu.

Kontrolované a zakázané organizace v CzechIdM

V tomto článku vás seznámím s novou funkcionalitou v CzechIdM, která umožňuje snazší implementaci centrální správy uživatelů ve společnostech se složitější organizační strukturou, což byl případ jednoho z našich zákazníků. Jedná se o funkcionalitu zakázaných organizací. Ta umožní vyjmout ze správy administrátora nějakou organizaci, ačkoliv ten samý administrátor spravuje její nadřazenou organizaci.

Centrální a lokální administrátoři

Do administrátorského rozhraní mají přístup všichni uživatelé, kteří mají v CzechIdM přidělenou nějakou roli typu „ADMIN“. Každá taková role přiřazuje svým držitelům rozličná oprávnění (čtení či editace uživatelů, rolí, systémů,…) na základě konkrétního nastavení. Ovšem aby mohl administrátor spravovat uživatele v CzechIdM, musí navíc kontrolovat tu organizaci, v níž je uživatel zařazen (tj. uživatelovu domovskou organizaci). Podobně je to i s organizacemi; administrátor může spravovat jen ty organizace, které kontroluje.

Administrátorovi je tedy možné nastavit buď plná práva na všechny uživatele, nebo vytvořit lokálního administrátora, který kontroluje pouze určitou část organizační struktury (jednu nebo více organizací). Organizační struktura je stromová; mluvíme tedy o nadřazených a podřazených organizacích, přičemž celý organizační strom má v CzechIdM jeden kořen – organizaci „top“.

Pokud administrátor kontroluje organizaci „top“, znamená to, že vidí všechny uživatele a organizace. Příkladem takového uživatele je třeba „admin“, který existuje v každé instanci CzechIdM jako centrální administrátor.

Stromová organizační struktura

Při nastavování kontrolovaných organizací se uplatňuje jednotný princip, že kořen organizačního podstromu reprezentuje celý podstrom. Má-li tedy administrátor nastavenou organizaci „Celá firma“ ve svých kontrolovaných organizacích, znamená to, že kontroluje nejen uživatele umístěné přímo v organizaci „Celá firma“, ale také uživatele z jejích podřazených organizací (např. „Ředitelství“, „Odbor účetnictví“,…).

Tento princip by v ideálním případě stačil k tomu, aby se dala nastavit libovolná potřebná kombinace kontrolovaných organizací pro administrátory. Nicméně reálné situace zřídka bývají ideální a někdy může být potřeba, aby administrátor měl možnost spravovat nadřazenou organizaci, ale ne všechny její podřazené organizace. Například aby mohl spravovat uživatele v organizaci „Celá firma“, ale ne uživatele v její podorganizaci „Ředitelství“. Ideální řešení by bylo upravit organizační strukturu či umístění uživatelů v ní tak, aby takovéto výjimky neexistovaly. To však samozřejmě není vždy možné. Proto vznikly tzv. zakázané organizace.

Zakázaná organizace je výjimka z kontrolovaných organizací. V příkladu uvedeném výše jednoduše nastavíme administrátorovi, aby kontroloval „Celou firmu“, ale aby měl zakázané „Ředitelství“. Po přihlášení do CzechIdM pak bude moci spravovat uživatele celé firmy kromě uživatelů z organizace „Ředitelství“ a jejích podřazených organizací; tyto uživatele ani neuvidí ve výpisu uživatelů.

Kontrolované a zakázané organizace

Kontrolované a zakázané organizace

Bezpečnost

Při implementaci zakázaných organizací bylo třeba důkladně promyslet všechny možnosti. Je zásadní, aby uživatel, kterému je tímto způsobem zakázán přístup ke správě části organizační struktury, skutečně nemohl žádným způsobem ovlivnit její nastavení. To znamená:

  • nesmí mít možnost vytvářet, editovat či mazat uživatele z nějaké své zakázané organizace
  • uživatelům, které má ve správě, nemůže nastavit, aby kontrolovali nějakou organizaci, které leží mimo jeho vlastní kontrolu (ať už přidělením kontrolované organizace, nebo odebráním zakázané organizace)
  • uživatelům, které má ve správě, nemůže odebrat kontrolu nad organizací, která leží mimo jeho vlastní kontrolu (ať už odebráním kontrolované organizace, nebo přidáním zakázané)

Při administraci tedy může dojít třeba k následující situaci:

  1. Administrátor kontroluje organizaci „top:Celá firma“ a má zakázanou organizaci „top:Celá firma:Ředitelství“.
  2. Uživatel je zařazen v organizaci „top:Celá firma“ (takže ho administrátor může spravovat) a na začátku nekontroluje žádnou organizaci.
  3. Administrátor nastaví do kontrolovaných organizací uživatele organizaci „top:Celá firma“.
  4. Uživatel má ve výsledku kontrolu nad organizací „top:Celá firma“, ale má zakázanou organizaci „top:Celá firma:Ředitelství“. Tuto zakázanou organizaci totiž přidalo automaticky CzechIdM při uložení změn nad uživatelem. To proto, že administrátor nesmí nikomu nastavit kontrolu nad „Ředitelstvím“, které sám nekontroluje.

Obdobně se CzechIdM chová i při odebírání kontrolovaných organizací či přidávání/odebírání zakázaných organizací.

Kontrola oprávnění administrátora se provádí na úrovni GUI i v backendu. Na úrovni GUI lze měnit přiřazení kontrolovaných a zakázaných organizací pouze v tom rozsahu, na který má administrátor oprávnění. Pokud by chtěl nastavit uživateli takovou kombinaci, která by vedla k nesmyslnému stavu (např. kontrolovaná organizace by ležela pod zakázanou organizací), CzechIdM by neumožnilo nastavení uložit.

V backendu se kontroluje oprávnění vždy v rámci metody Data.checkinView (což je jediná metoda, přes kterou lze uložit tzv. view – „pohled na uživatele“ – do databáze). Ani při vynechání kontroly oprávnění v GUI tedy nelze nastavit nic, co by bylo v rozporu s oprávněními přihlášeného uživatele.

Závěr

V tomto článku jsem vám představila jednu z nových vlastností CzechIdM. Pokud by vás zajímaly detaily jejího chování či podrobnosti implementace, neváhejte mi napsat na e-mail alena.peterova@bcvsolutions.eu.

Jak na Selenium testy pro CzechIdM

V tomto článku si ukážeme, jak zprovoznit Selenium testy pro CzechIdM a napsat svůj první test. Předpokládá se, že máte k dispozici vývojové prostředí pro CzechIdM s TestNG (pokud ne, začněte naříklad zde).

Požadavky

Zde uvádím seznam potřebného softwaru, včetně verze, se kterou jsem pracoval, pro referenci, kdyby v budoucnu došlo k nekompatibilitě.

  • naklonované CzechIdM z repozitáře, Java 1.7
  • TestNG (pokud používáte Eclipse, nejlépe jako plugin)
  • Selenium Client & WebDriver Language Bindings pro Javu (testováno s verzí 2.44)

nepovinné, ale ušetří čas:

  • Selenium IDE (testován plugin pro firefox verze 2.8.0)

Příprava Selenium v Eclipse

Rozbalíme Selenium Client & WebDriver Language Bindings, v něm se nacházi několik .jar souborů (v aktuální verzi 2) a složka libs ve které jsou další (v aktuální verzi 37). V Eclipse klikneme pravým na projekt czechidm-test a vybreme Properties. Na Záložce Java Build Path v podzáložce Libraries je tlačítko Add External Jars …, Přidáme tedy všechny knihovny (aktuálně 39). Nyní by měly Selenium testy v pořádku proběhnout.

První test se Selenium IDE

Po instalaci pluginu a restartu prohlížeče se vpravo od adresního řádku objeví logo Selenium IDE, tím ho spustíme. Base URL zadáváme bez idm/, pokud testujete na lokálním počítači s testovacím prostředím nastaveným podle návodu na tomto blogu, je to nejpravděpodobněji http://localhost:8080/. Vpravo pod řádkem pro Base URL je červené tlačítko pro nahrávání. Otevřeme si tedy IdM, nastavíme Base URL a začneme nahrávat.

Base URL a nahravani

Pokud budete testů dělat více a nebudete chtít, aby se pokaždé znovu přihlašovaly, je potřeba si ohlídat jejich pořadí, pro začátek však uděláme test co se přihlásí i odhlásí.

V tomto vzorovém testu se tedy přihlásíme do IdM, otevřeme záložku Reports, do kolonky Executor napíšeme admin a klikneme na Search. Nakonec se odhlásíme.

Nahravani testu

V tuto chvíli v okně Selenium IDE máme nahranou kostru prvního testu. Můžeme si ho pro jistotu spustit a dát se do úprav. Samotné Selenium IDE nám nabízí spoustu nástrojů pro kontrolu (ne)existence obsahu, ale jsou věci (například právě obsah tabulky vyčtené z databáze), které je praktičtější napsat rovnou v Javě, než v samotném Selemium IDE.

Podívejte se však jaké možnosti Selenium IDE nabízí. Stačí kliknout pravým tlačítkem na řádek, před který chceme přidat kontrolu a kliknout na Insert New Command. V kolonce Command vybereme nebo napíšeme příkaz, Target je cílový element a Value hodnota (např. pro Command assertText je text, který v elementu má být).

Když máme hotové kontroly které jsme schopni provést v samotném Selenium IDE, klikneme na File > Export Test Case As > Java / JUnit 4 / WebDriver. Bohužel Selenium IDE v aktuální verzi neumí kombinaci Java / TestNG / WebDriver, bude tedy potřeba test převést, s pluginem pro TestNG v Eclipse je to však otázka pár kliknutí.

export do Javy

Dostaneme soubor s kostrou testu, může vypadat například takto:

package com.example.tests;

import java.util.regex.Pattern;
import java.util.concurrent.TimeUnit;
import org.junit.*;
import static org.junit.Assert.*;
import static org.hamcrest.CoreMatchers.*;
import org.openqa.selenium.*;
import org.openqa.selenium.firefox.FirefoxDriver;
import org.openqa.selenium.support.ui.Select;

public class Test {
	private WebDriver driver;
	private String baseUrl;
	private boolean acceptNextAlert = true;
	private StringBuffer verificationErrors = new StringBuffer();

	@Before
	public void setUp() throws Exception {
		driver = new FirefoxDriver();
		baseUrl = "http://localhost:8080/";
		driver.manage().timeouts().implicitlyWait(30, TimeUnit.SECONDS);
	}

	@Test
	public void test() throws Exception {
		driver.get(baseUrl + "/idm/admin/authentication/login.seam");
		driver.findElement(By.id("j_id12:username")).clear();
		driver.findElement(By.id("j_id12:username")).sendKeys("admin");
		driver.findElement(By.id("j_id12:password")).clear();
		driver.findElement(By.id("j_id12:password")).sendKeys("admin");
		driver.findElement(By.id("j_id12:submit")).click();
		driver.findElement(By.id("reportsLink:j_id60")).click();
		driver.findElement(By.name("j_id100:submenu_table:j_id109")).clear();
		driver.findElement(By.name("j_id100:submenu_table:j_id109")).sendKeys("admin");
		driver.findElement(By.name("j_id100:submenu_table:j_id137")).click();
		driver.findElement(By.id("j_id32")).click();
	}

	@After
	public void tearDown() throws Exception {
		driver.quit();
		String verificationErrorString = verificationErrors.toString();
		if (!"".equals(verificationErrorString)) {
			fail(verificationErrorString);
		}
	}

	private boolean isElementPresent(By by) {
		try {
			driver.findElement(by);
			return true;
		} catch (NoSuchElementException e) {
			return false;
		}
	}

	private boolean isAlertPresent() {
		try {
			driver.switchTo().alert();
			return true;
		} catch (NoAlertPresentException e) {
			return false;
		}
	}

	private String closeAlertAndGetItsText() {
		try {
			Alert alert = driver.switchTo().alert();
			String alertText = alert.getText();
			if (acceptNextAlert) {
			alert.accept();
		} else {
			alert.dismiss();
		}
			return alertText;
		} finally {
			acceptNextAlert = true;
		}
	}
}

Umístíme jej tedy do vhodného package mezi testy, já jsem zvolil eu.bcvsolutions.idm.test.ui.admin.selenium. V Eclipse na něj klikneme pravým tlačítkem a zvolíme TestNG > Convert to TestNG. Pravděpodobně nebudete chtít vygenerovat testng.xml, ale budete test chtít přidat do hlavního testng.xml, aby se spouštěl s ostatními testy.

V BCV solutions testujeme automaticky pomocí Jenkins, proto je připravena třída eu.bcvsolutions.idm.test.SeleniumTest, ze které testy dědíme. Poskytuje předpřipravené metody setUp a tearDown pro testování více prohlížeči. Stačí jednoduše přidat na začátek import eu.bcvsolutions.idm.test.SeleniumTest a k deklaraci třídy extends SeleniumTest a smazat vygenerované metody setUp a tearDown. V testng.xml přidáme naši třídu ke všem prohlížečům (ChromeTest, FirefoxTest, případně do budoucna další) a nyní se bude test spouštět postupně na všech. Také nám tato třída poskytuje metody logIn a logOut aby se nám stále neopakoval stejný kód.

Nyní je vhodný čas zkusit, jestli test správně proběhne. Pokud ano, můžete se pustit do pokročilejších kontrol, nyní už v Javě, a tedy mnohem pohodlněji než v Selenium IDE. Můžete si například najít tabulku s výsledky a kontrolovat, zda obsahuje po přefiltrování správná data.

K tomu máme k dispozici třídu eu.bcvsolutions.idm.test.SeleniumTestUtils, ve které je prozatím metoda pro kontrolu, zda sloupec tabulky (ne)obsahuje hodnotu X, do budoucna se jistě rozšíří, abychom nemuseli časté typy kontrol psát stále znovu.

Na co si dát pozor do budoucna

V budoucnu se CzechIdM bude jistě rozrůstat o další funkce, s tím souvisí nejen drobné změny vzhledu (další položky v menu, …) ale i testovacích dat. Může se tedy stát, že nám mezi existující položky přibudou další, musíme tedy s touto variantou počítat a nedělat testy až přespříliš striktní, typu „v X-tém řádku, Y-tém sloupci bude hodnota Z“ ale například „někde v Y-tém sloupci bude hodnota Z“, což je problematické přímo v Selenium IDE a lépe se řeší už v Javě. Sice to stále neřeší všechny situace (např. že data padnou na další stránku), ale alespoň většinu z nich.

Pozor na ID elementů

V aktuálním release má spousta HTML elementů ID vygenerované automaticky díky JSF. Zde narážíme na problém, protože pokud v rozhraní přibude element, JSF posune číslování, tedy veškeré kontroly spoléhající na ID elementu selžou. O tomto problému víme a budeme ho v brzké době řešit dogenerováním vlastních ID. Prozatím je potřeba počítat s úpravou testů pro nové verze a nebo se snažit psát kontroly, které na ID nezáleží.

Závěr

Selenium testy jsou jistě zajímavým tématem k hlubšímu studiu a někdy se k nim určite vrátím. V případě že máte nějaké otázky, nebo postřehy k tomuto článku, mužete psát na jiri.novak@bcvsolutions.eu.

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 jaromir.mlejnek@bcvsolutions.eu.

Archiv v CzechIdM

Potřebovali jste si někdy něco zazálohovat? Případně potřebovali jste si udržovat změny ohledně nějakého objektu v průběhu času? Jestli ano, nyní je to v CzechIdM možné. V CzechIdM vznikl nový modul — archiv, který zvládá tyto úkony a ne jenom to. Vše o principu a správném použití archivu si můžete přečíst právě v tomto článku.

Funkčnost a GUI Archivu

Mezi primární funkci archivu patří samozřejmě archivování různých objektů. Také je možné jej prohledávat na základě zvolených kritérií či exportovat vybraná data do csv souboru. Tyto funkce jsou snadno přístupné administrátorovi přímo z administrátorského rozhranní CzechIdM pod záložkou uživatelé a podzáložkou archiv. Takto vypadá hlavní stránka archivu:

archiveMain

V hlavičce stránky je možné definovat kritéria, podle kterých si přejeme vyhledávat archivované objekty. Mezi možnosti patří hledání podle názvu, datum archivace, typu, či hodnoty atributu. Strukturu samotných objektů vysvětlím dále v článku. Po vyhledání se zobrazí seznam objektů odpovídajících výše uvedeným kritériím. V případě, že bychom si chtěli vyhledané objekty vyexportovat a dále s nimi pracovat, stačí pouze kliknout na tlačítko export a jen si uložit výsledný soubor.

archiveExport

Volání metod archivu z Java kódu

Nyní se zaměřím více na technickou stránku věci, aneb jak je možné obsluhovat archiv přes java kód. Pro obsluhu archivu vznikly nové statické metody na třídě data, které je možné volat kdekoliv z kódu. Protože automaticky se v CzechIdM nic nearchivuje, je nutné tuto akci vždy vyvolat explicitně. Například můžeme upravit workflow smazání uživatele, kde před samotným vykonáním smazání tohoto uživatele zaarchivujeme.

Archivování

Archivované objekty sice musí splňovat předepsanou strukturu vyžadovanou archivem, ale de facto je možné archivovat jakýkoliv serializovatelný objekt. Pro zaarchivování objektu musíme předat archivu meta informace jako jsou jméno a typ objektu a dále seznam jeho atributů, které si přejeme uložit. Každý ukládaný atribut se skládá ze jména a serializovatelné hodnoty. Při ukládání se tato hodnota uloží i v podobě řetězce z důvodů vyhledávání. Přesně s těmito atributy zavoláme metodu Data.archive a CzechIdM se postará o zbytek.

Vyhledávání v archivu

Pro prohledávání archivem používáme metodu Data.archiveSearch, které předáme kritéria vyhledávání. Ta nám vrátí iterátor, přes který můžeme procházet archivovanými objekty. Z důvodu rychlosti a optimalizace vrací iterátor pouze základní meta informace o archivovaném objektu, pro vytáhnutí celého objektu včetně jeho atributů musíme zavolat metodu Data.archiveGetElement, které předáme ID daného objektu. Zde je krátká ukázka jak definovat kritéria, které vyhledají objekt typu „IDENTITY“, zaarchivovaný před týdnem mající atribut manager nastavený na „Doe“:

Criteria criteria = new eu.bcvsolutions.idm.data.dto.Criteria();
criteria.add("type", "IDENTITY", Relation.EQ);
Calendar cal = Calendar.getInstance();
cal.setTime(new Date());
cal.add(Calendar.DAY_OF_YEAR, -7);
criteria.add("archiveDate", cal.getTime(), Relation.GT);
criteria.createAlias("attributes", "attrs");
criteria.add("attrs.attrName", "manager", Relation.EQ);
criteria.add("attrs.attrValueAsString", "Doe", Relation.EQ);

Export

Export z archivu funguje podobně jako prohledávání. Na vstupu se mu předají kritéria a on vyexportuje všechny objekty odpovídající těmto kritériím do csv souboru. Ovšem protože každý objekt může mít k sobě napárovaný neomezený počet atributů a nás může zajímat pouze nějaká jejich podmnožina, je možné specifikovat pouze ty atributy, které se mají k daným objektům vyexportovat. Tyto atributy definujeme v mapě, které funkci exportu předáme. Jako klíče jsou názvy atributů, které chceme vyexportovat. Můžeme definovat i jejich hodnoty, které slouží pro přejmenování sloupce pro účely exportu. V případě, že chceme vyexportovat všechny atributy, předáme místo mapy null. Zde je názorná ukázka, jak vyexportovat všechny objekty archivu a k nim pouze atributy „MANAGER“ a „ROLES“ u kterých budeme ale chtít, aby se v exportu objevily jako „manažer“ a „role“.

Criteria criteria = new eu.bcvsolutions.idm.data.dto.Criteria();
Map<String> attributes = new HashMap<String>();
attributes.put("MANAGER", "manažer");
attributes.put("ROLES", "role");
File file = Data.archiveExport(criteria, attributes, "archiv_export");

Závěr

Po přečtení tohoto článku by jste měli být schopni sami umět ovládat archiv přes Java kód. Kdyby jste měli nějaké dotazy ohledně archivu či potřebovali poradit, kontaktujte mě přes filip.mestanek@bcvsolutions.eu.

Vypisujeme témata pro bakalářské a diplomové práce

Již několik let vypisujeme témata a vedeme bakalářské a diplomové práce. Zadání vytváříme na základě reálné potřeby pro skutečné zákazníky. Výsledek Vaší práce bude někdo používat a to v podstatě ihned. Proto hledáme šikovné lidi, kteří se nebojí udělat pořádnou práci a mají zájem se trochu zviditelnit.

Na čem budete pracovat?

CzechIdM Identity Management – nástroj pro centralizaci a automatizaci správy uživatelských identit (účtů, skupin atd.) v celé síti, a to bez výrazných zásahů do fungování stávajících systémů. CzechIdM je SW kompletně naprogramovaný v jazyce Java, konkrétně na platformě J2EE. Více zde: http://www.czechidm.com

Co budeš používat?

  • Java EE
  • JBoss AS
  • JBoss jBPM
  • Hibernate, Java persistent API (JPA)
  • Java Server Faces, Richfaces framework
  • EJB3
  • Connector Framework

Koho hledáme?

Obecně hledáme toho, kdo chce něco smysluplného vytvořit. Chceme toho, kdo dokončí co začal a chce se svou prací dlouhodobě chlubit. Pokud máte zájem vytvořit kvalitní práci, která nebude do šuplíku, a která bude přínosem, kontaktujte nás.

Ukázka témat

  1. Vytvoření konektoru na připojení Office365.
  2. Vytvoření automatické testovací platformy a automatických testů na GUI.
  3. Vytvoření nového uživatelského rozhraní CzechIdM.
  4. Realizace databázového migrátoru.

Kontakt

Kontaktuj mne na mailu lukas.cirkva@bcvsolutions.eu. Následovat bude osobní schůzka, kde si popovídáme a nabídneme několik témat a pokud si plácneme, domluvíme další kroky.

První krůčky s CzechIdM Kapitola 3: Nastavení synchronizace a rekonciliace systému

czechidm

V minulém díle jsme si ukázali, jak vytvořit koncový systém pro CzechIdM, a jak s jeho pomocí spojit CzechIdM s databázovou tabulkou. Dnes si ukážeme, jak sesynchronizovat účty v koncovém systému s identitami v CzechIdM. Také nastavíme rekonciliaci. Rozdíl mezi těmito dvěma slovy není veliký, protože obě operace se starají o stejnou činnost, jen v jiném rozsahu. V obou situacích sjednocujeme (synchronizujeme) stav účtů na koncovém systému a informace, které o nich máme v CzechIdM. A právě takovou operaci si dnes ukážeme. Ale nejdříve si vysvětlíme, co se vlastně při synchronizaci nebo při rekonciliaci děje.

Co to je synchronizace a rekonciliace

Jak jsme si již řekli o odstavec výše, cílem obou operací je synchronizovat data na koncovém systému a v CzechIdM. To se hodí provést v různých situacích. Buď jde o koncový systém, který jsme nově napojili na CzechIdM, a chceme účty na tomto systému připárovat k identitám v CzechIdM. Nebo jde o autoritativní koncový systém, kde pravidelně vznikají, aktualizují se nebo zanikají účty, a při každé takové změně chceme náležitě vytvořit, upravit či smazat příslušnou identitu v CzechIdM. Případně jde prostě o systém, kde z nějakého důvodu nesouhlasí stav účtů s tím, co je evidováno v CzechIdM, a to chceme opravit.

Zatímco při synchronizaci se zpracovávají jen ty účty na koncovém systému, které se od poslední synchronizace změnily nebo nově vytvořily, při rekonciliaci se zkontrolují úplně všechny účty. Samozřejmě nemusíme každých deset minut spouštět vybranou operaci ručně. Stačí jednou nastavit, kdy se má synchronizace či rekonciliace spustit a jak často se má opakovat.

Tím ale možnosti nastavení nekončí. Při obou operacích si můžeme vybrat, co se stane, nastane-li nějaká z modelových situací. Například představme si situaci, kdy vznikne nový účet na koncovém systému. Pomocí synchronizace můžeme nastavit, jaká operace se má provést. Můžeme si vybrat, co se stane jako výkonná akce a co jako informativní akce. Tak například jako výkonnou akci můžeme nastavit vytvoření nové identity, a jako informativní odeslání e-mailu na námi zadanou adresu. Samozřejmě pokud si nechceme zahlcovat schránku, CzechIdM nám může zaslat zprávu pouze v případě, kdy dojde k nějaké chybě, a nebo nám nemusí zasílat zprávy vůbec. Představivosti se meze nekladou.

Zasílání zpráv není rozhodně jedinou věcí, kterou CzechIdM umí. Můžeme si například nastavit hromadnou akci, která se spustí po zpracování všech účtů synchronizací/rekonciliací. Buďto můžeme opět odesílat zprávy, nebo si můžeme vybrat nějaké workflow či pravidlo, které se vykoná.

Důležitá věc, kterou musíme každé synchronizaci/rekonciliaci nastavit, je korelace. Korelace je podmínka, podle které CzechIdM přiřazuje jednotlivým identitám odpovídající účty. Například pokud jsme si v minulém dílu nastavili login jako jedinečný identifikátor účtu na koncovém systému, zde ho můžeme použít v nastavení synchronizace/rekonciliace: na základě rovnosti loginu koncového účtu a názvu identity v CzechIdM se účet této identitě přiřadí.

Zde jsou vyjmenované jednotlivé možnosti, které při synchronizaci či rekonciliaci mohou nastat:

  • ASSIGNED – účet je již přiřazen konkrétní identitě
  • MATCHED – účet a identita si odpovídají na základě korelace, ale účet ještě není připárován k identitě
  • 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.

Tak nyní bychom měli mít alespoň základní informace o tom, co se vlastně při synchronizaci a rekonciliaci děje, a pojďme přejít na jejich nastavení.

 

Nastavení rekonciliace/synchronizace

Jako první krok si ukážeme, jak namapovat atributy.

Namapování atributů je potřebné v případě, kdy se během synchronizace/rekonciliace mají nastavovat hodnoty atributů identity v CzechIdM. Využijeme to tedy především u autoritativních koncových systémů. Například nastavíme, že do atributu „email“ u identity v CzechIdM se bude propagovat hodnota atributu „email“ koncového účtu. Pro rekonciliace běžných koncových systémů obvykle stačí nastavit mapování atributu „roles“, tj. jak se mají aktualizovat role identity v CzechIdM.

Přejdeme tedy na:

SystémyMapování atributů

1

vyplníme atributy identity a Uložíme výsledek.

2

Nyní přejdeme k nastavení samotné rekonciliace. Nastavení synchronizace je úplně stejné, proto si zde ukážeme pouze nastavení rekonciliace. Přejdeme na:

Systémy → Systémy → Nastavit rekonciliaci

1

u systému SystemTest1.

Zde nastavíme jednotlivé výkonné a informativní akce pro všechny stavy rekonciliace. 

42

a následně klikneme na Uložit.

Zobrazení výsledku rekonciliace/synchronizace

Zde si ukážeme, jak si zobrazit informace o probíhající rekonciliaci.

3

Přejdeme na:

Systémy → Systémy → Zobrazit informace o rekonciliaci (SystemTest1)

4

Zde jsou uvedeny informace o probíhající rekonciliaci, případně o posledním průběhu. Po prvním provedení se nelekejte výsledků MISSING_IDENTITY. Důvod je jednoduchý, jelikož proběhla první rekonciliace, nebyly v CzechIdM ještě žádné identity, které koncovým účtům odpovídají. Proto CzechIdM zahlásilo, že identita chybí, a vytvořilo ji. Pro odchod stačí kliknout na tlačítko Zavřít.

Závěr

V tomto krátkém díle jsme si ukázali, jak nastavit synchronizaci a rekonciliaci na CzechIdm. Po nastavení a spuštění by měly být všechny naše účty aktuální.

V případě jakýchkoliv dotazů pište prosím na michal.stejskal@bcvsolutions.eu.

 

První krůčky s CzechIdM Kapitola 2: Připojení databázové tabulky

czechidm

V tomto díle našeho krátkého seriálu o práci v CzechIdM se podíváme na to, jak definovat konektor pro koncový systém, jak připojit námi vytvořenou tabulku ke koncovému systému a nakonec se podíváme, jak vytvořit roli pro náš koncový systém.

Vytvoření databázové tabulky

V minulém dílu jsme si nainstalovali MySQL, zatím ale stále nemáme žádné přívětivé prostředí, kde můžeme s databázemi pracovat. Proto si nainstalujeme MySQL workbench. Instalace tohoto prostředí není nijak složitá, stačí v terminálu zadat

$sudo apt-get install mysql-workbench

Po skončení instalace zadáme opět v terminálu mysql-workbench

  • Ze záložky Database vybereme možnost Manage Connection. Zde pojmenujeme naše připojení a klikneme na Test connection. Pokud nastali problémy, zkontrolujte si prosím parametry připojení:

Záložka Connection

Connection Method: Standard (TCP/IP)

Hostname: 127.0.0.1

Port: 3306

Username: root

  • Ze záložky Database vybereme Connect to Database. U možnosti Stored Connection vyberem námi vytvořené připojení a klikneme na OK.
  • Zobrazí se nám prostředí pro práci s databázemi. Uprostřed je bílé okno pro vykonávání SQL příkazů. Do něj zadáme:
CREATE SCHEMA `test` ;
CREATE TABLE test.datas (
`ID` INT,
`firstName` TEXT,
`lastName` TEXT,
`login` TEXT,
`address` TEXT,
`city` TEXT,
`dateOfBirth` TEXT,
`company` TEXT,
`possition` TEXT,
`salary` INT,
`timeStamp` TEXT);

a klikneme na žlutý blesk v horní části obrazovky. Tím se vykoná SQL příkaz, který vytvoří nové schéma test a v něm tabulku datas se sloupci jméno, příjmení, email… .

  • Dalším krokem je nastavení primárního klíče. V levé části obrazovky máme světle modré pole. Pokud máme mysql-workbench spuštěný poprvé, je toto pole prázdné. Klikneme na něj tedy pravým tlačítkem a vybereme Refresh All. Zobrazí se námi vytvořené schéma a v něm naše zatím prázdná tabulka.
  • Klikneme na ní opět pravým tlačítkem a zvolíme Alter table. Otevře se nám dialog pro nastavení tabulky test. Zaškrtneme parametry PK a NN u sloupce ID. Parametr PK znamená, že daný sloupec bude primárním klíčem. Pomocí primárního klíče se jednoznačně identifikuje každý záznam v tabulce. To znamená, že žádné ID v naší tabulce nemůže být shodné s dalším, nebo že žádné ID nesmí být prázdné. Toho docílíme právě zaškrtnutím NN parametru (nut null). Dále zaškrtneme možnost AI (Auto Increment), kterým nastavíme, že každé další ID bude o jedna větší než ID předchozí.
  • Nyní nasypeme nějaká testovací data do naší nové tabulky. Do záložky Query 1 v horní části obrazovky  zkopírujeme následující kód:
INSERT INTO test.data (`firstName`, `lastName`, `login`, `address`, `city`, `dateOfBirth`, `company`, `possition`, `salary`, `timeStamp`) VALUES ('Drahoslav', 'Miler', 'Drahoslav@Miler.cz', 'Stráň 122', 'Lobeč', '10.10.1957', 'b', 'Lorem ', '20077', '12.4.2014');

Opět klikneme na žlutý blesk vlevo nahoře do naší databáze se přidá první záznam. Takto můžeme vkládat kolik záznamů chceme. Vždy do hodnoty VALUES vložíme data přesně tak, jak je to ukázáno v kódu nahoře. Pokud si chceme zkontrolovat výsledek, klikneme pravým tlačítkem myši na tabulku datas a zvolíme Select rows – 1000 limit.

Pokud si o databázích chcete přečíst něco podrobnějšího, podívejte se například na tento seriál: http://www.linuxsoft.cz/article.php?id_article=731

Definování typu systému pro konektor

Prvním krokem je vydefinování typu systému pro Database Table konektor v CzechIdM. Tento krok stačí provést pouze jednou, a to když připojujete nějaký systém pomocí tohoto konektoru poprvé. Přejdeme tedy na záložku

Systémy → Typy systémů → Nový typ.

Zaškrtneme možnost, že se má použít lokální connector server a klikneme na Pokračovat. Posledním krokem je pojmenování nového typu systému a vybrání správného balíku. My náš typ pojmenujeme Database Table Konektor a jako balík vybereme org.identityconnectors.databasetable-1.1.xx.jar.

Nyní stačí už jenom náš nový typ systému uložit a máme hotovo.

Připojení systému s databázovou tabulkou

Snímek obrazovky pořízený 2014-07-27 23:06:42

Nyní již propojíme námi vytvořenou tabulku s CzechIdM. Pro tento krok musíme vytvořit nový systém, který bude sloužit k připojení k tabulce. Přejděme tedy na záložku

Systémy → Systémy → Nový systém
  • Vybereme konektor, který jsme vytvořili v předchozím kroku, tedy Database Table Konektor a klikneme na Next.
  • V nové tabulce vyplníme Název systému na SystemTest1, kolonku Název pro uživatele necháme v tuto chvíli volnou.
  • Authority level nastavíme na 0. Tímto číslem určujeme jak moc bude náš systém autoritativní pro data v CzechIdM. Čím je toto číslo větší, tím více je systém autoritativní. Prakticky to bývá tak, že level 1 je zdrojový systém (systém je zdroj dat pro identity v CzechIdM), level 0 je koncový systém (CzechIdM je zdroj dat pro koncový systém).
  • Pouze ke čtení nebudeme zaškrtávat, protože budeme v budoucnu upravovat tabulku pomocí CzechIdM.
  • Další položkou, kterou vyplníme, je port. Nastavíme ho na 3306, tam nám totiž běží MySQL databáze.
  • Dále jako Key Column zvolíme login. Key Column nám určuje, který atribut bude použit jako identifikátor jak při zobrazování, tak i například při synchronizaci systému.
  • Initial JNDI Properties v tuto chvíli necháme volné.
  • Do položky Host zadáme místo, kde nám běží server, tedy localhost.
  • All native nebudeme zaškrtávat.
  • Name quoting necháme volné.
  • Do políčka Table zadáme jméno námi vytvořené tabulky, tedy datas.
  • Pokud jste nechali při instalaci MySQL serveru políčko pro heslo roota prázdné, nevyplňujte ani políčko User Password. V opačném případě zadejte heslo, jež jste si nastavili pro MySQL roota.
  • Do kolonky Database se zadává jméno databáze, ke které se připojujeme. V našem případě se databáze jmenuje test.
  • Change Log Column (Sync) nastavíme na timeStamp. Tím jsme nastavili, který atribut bude použit při synchronizaci systémů jako časová značka změněných řádků.
  • Password Column necháme také volné, protože v naší databázové tabulce nemáme žádný sloupec obsahující hesla.
  • JDBC Connection URL nastavte na jdbc:mysql://%h:%p/%d. Tím jsme určili URL pro spojení CzechIdM a databáze.
  • Native Timestamps a Enable writing empty string nebudeme zaškrtávat, ale položku Rethrow all SQLExceptions označíme.
  • Validate Connection Query necháme volné.
  • Do pole User napíšeme root, což je uživatelské jméno, přes které se připojujeme k MySQL databázi.
  • Datasource Path necháme volné.
  • JDBC Driver nastavíme na com.mysql.jdbc.Driver. Tím jsme určili třídu konektoru pro připojení do databáze.

Nyní klikneme na tlačítko Test. Tím se otestuje zda-li je náš systém pro připojení správně nastaven. Zobrazí-li se hláška o úspěšném navázání spojení, klikněte na Pokračovat.

Snímek obrazovky pořízený 2014-07-27 23:08:06

Nyní se dostaneme do okna, kde můžeme editovat atributy. Klikneme tedy na Editovat atributy a zobrazí se nám jména sloupců z námi vytvořené databázové tabulky.  Do sloupce IdmName vyplníme jednotlivé atributy tak, aby CzechIdM poznalo, o který atribut se jedná, Tedy pokud pojmenujeme atribut firstName, pro CzechIdM opět firstName, CzechIdM bude vědět, že se jedná o křestní jméno. Poté klikneme na tlačítko Uložit.

Pokud si chceme zobrazit výsledky naší práce, klikneme na na odkaz Zobrazit všechny účty na seznamu našich systémů. Měli bychom vidět pouze prázdný seznam a až po kliknutí na tlačítko Hledat se nám zobrazí všechny účty z našeho koncového systému. Můžeme rozklikávat jednotlivé účty a prohlížet si jejich detaily. Ve chvíli, kdy skončíme, klikneme na tlačítko Zavřít.

Vytvoření role pro připojený systém

Poslední krok, který si v tomto článku ukážeme, je vytvoření role v CzechIdM, která vytváří účty na připojeném systému, jakmile je přiřazena uživateli. Přejdeme na záložku

Role → Role → Nová role

a zde na záložce Základní informace vyplníme název nové role (např. Test system account). Poté přejdeme na záložku Schémata zdrojů a klikneme na odkaz Přidat u systému Test end system v pravé tabulce (se seznamem všech připojených systémů). Poté klikneme na odkaz Editovat v levé tabulce (se seznamem systémů, ke kterým opravňuje tato role).

Na následující stránce můžeme nastavit, jak budou atributy účtu plněny touto rolí v závislosti na svých potřebách. Zatím to ponecháme beze změny a klikneme na Nastavit.

Naši novou roli už jen Uložíme. Tuto roli můžeme přidělit libovolné identitě a tím pro ni vytvořit nový účet na napojeném koncovém systému.

Závěr

V tomto článku jsme si ukázali, jak připojit databázovou tabulku pomocí Database Table konektoru, a jak si zobrazit data z tabulky. Dále jsme si ukázali, jak vytvořit roli, jež nám vytvoří účet pro identitu v databázové tabulce. V příštím díle se podíváme na to, jak sesynchronizovat účty a jak nastavit rekonciliaci.

Pokud jste v článku nalezli nějakou chybu, nebo máte nějaký dotaz, prosím napište mi na michal.stejskal@bcvsolutions.eu .