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 .

 

První krůčky s CzechIdM Kapitola 1: Instalace potřebných programů

czechidm

Dobrý den, vítejte u první části našeho detailního seriálu, ve kterém si ukážeme, jak nainstalovat a nakonfigurovat náš systém pro CzechIdM, a také si ukážeme základní práci s CzechIdM. V této části si nainstalujeme programy, bez kterých bychom CzechIdM nemohli zprovoznit. Každý z těchto programů je důležitý stejně tak jako jeho následné nastavení, proto vyskytnou-li se problémy, pokuste se je spravit nebo mne kontaktujte.

Nyní přistoupíme k samotné instalaci. Pro korektní běh aplikace CzechIdM jsou potřeba pouze tři věci (MySQL, Java (jdk, jre), JBoss). Všechny tři programy spolu nyní nainstalujeme, nastavíme a vysvětlíme jejich důležitost pro běh CzechIdM. Veškeré nastavení a instalace budou prováděny v rámci operačního systému Ubuntu ve verzi 14.04 64bit. Všechny příkazy začínající $ jsou příkazy pro terminál.

Instalace MySQL

MySQL je důležité pro práci s databází. V databázi budou drženi jednotliví uživatelé a CzechIdM se do MySQL bude přes konektor připojovat. Bez MySQL bychom měli sice velmi silný nástroj na správu identit, ale žádná data, se kterými bychom pracovali. Přejděme tedy k instalaci MySQL.

Nejdříve nainstalujeme MySQL a MySQL server. Tato instalace probíhá přes balíčkovací systém yum. Pokud Vám při zadání prvního příkazu instalace vyskočí chybová hláška o chybějící programu yum, jednoduše ho doinstalujte zadáním sudo apt-get install yum do Vašeho terminálu.

$yum install mysql
$yum install mysql-server

 

Nyní nastartujeme MySQL server pomocí příkazu

$sudo /etc/init.d/mysql start

Pokud nenastala žádná chyba, máme nyní úspěšně nainstalované aplikace spravující databáze.

Instalace Javy a konektoru pro připojení k MySQL

Druhým krokem, který musíme udělat, než spustíme náš server s CzechIdm, je instalace Javy a to konkrétně JDK. JDK v sobě mimo jiné obsahuje Java Runtime Enviroment, jež je potřeba ke spouštění aplikací napsaných právě v Javě. Začněme tedy s instalací.

Přejdeme na stránku http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-1880260.html a stáhneme si zde JDK ve verzi 1.7 pro 64bitový systém Linux. Stažený archiv si rozbalíme a překopírujeme do adresáře /opt pomocí příkazů

$tar -xzf jdk-7u51-linux-x64.tar.gz
$mv jdk1.7.0_51 /opt/

Instalační skript pro JBoss má zadanou cestu k Javě. Jelikož by bylo zbytečně složité pokaždé přepisovat instalační skript pro instalaci, vytvoříme symbolický odkaz na složku, kde máme umístěnou Javu.

$ln -s /opt/jdk1.7.0_51 /opt/jdk

Dále nainstalujeme prostředí pro spuštění Javy

sudo add-apt-repository ppa:webupd8team/java
sudo apt-get update
sudo apt-get install oracle-java7-installer

Poslední věc, kterou musíme udělat, je nastavit JAVA_HOME v .bashrc. Nejdříve zjistíme, kde máme Javu, spustíme tedy příkaz

$which java

Dostaneme umístění Javy. V našem případě máme Javu v /usr/bin/java. Ny přejdeme do našeho domovského adresáře a otevřeme si .bashrc a vložíme následující řádky (pokud Vám příkaz which java ukázal jiné umístění, uložte do proměnné JAVA_HOME cestu, která platí pro Váš systém)

$vim .bashrc
JAVA_HOME=/usr/bin/java 
export JAVA_HOME 
PATH=$PATH:$JAVA_HOME 
export PATH

Nyní máme úspěšně staženou Javu a můžeme si stáhnout JDBC konektor. Konektor budeme používat pro připojení JBoss serveru k naší MySQL databázi, aby mohl pracovat s jejími záznamy. Přejděte na stránku http://search.maven.org/remotecontent?filepath=mysql/mysql-connector-java/5.1.8/mysql-connector-java-5.1.8.jar a uložíme si ho do adresáře /tmp.

Instalace JBoss serveru

Úspěšně jsme nainstalovali MySQL a rozběhli Javu, která je důležitá pro běh JBoss serveru. Přejděme tedy k tomu nejdůležitějšímu, a to je instalace JBoss serveru společně s CzechIdm. Ze stránky http://download.czechidm.com/doku.php si stáhneme nejnovější release a stažený balíček rozbalíme

$tar -xzf czechidm-jboss-2014q1.tar.gz

Nyní přejdeme do složky scripts, kde je uložen instalační skript. Tento skript zkontroluje, zda máme nainstalované všechny potřebné programy, a pokud ano, nainstaluje JBoss.

$cd czechidm-jboss-2014q1/scripts

Pomocí příkazu

$./install_jboss.sh

skript spustíme.

Při instalaci budeme vyzváni k zadání hesla pro uživatele root v MySQL. Pokud jste heslo nenastavovali, nechte pole prázdné a potvrďte, jinak zadejte heslo. Nemusíte se ničeho obávat, toto heslo se nikde neukládá, vyplňujeme me ho pouze proto, aby instalační skript mohl vytvořit databázi pro CzechIdM. Další věc, kterou musíme při instalaci udělat, je zadat absolutní cestu k našemu staženému konektoru. JDBC jsme si stáhli do složky /tmp zadáme tedy tuto cestu

$/tmp/mysql-connector-java-5.1.8.jarm

Pokud při instalaci nenastaly žádné problémy, budeme uvítáni následujícím textem:

================================================
WELCOME to JBoss & CzechIdM installation script!
================================================

Creating home directory for CzechIdM: /opt/czechidm... done.

Creating repository and its admin for CzechIdM...
  (MySQL root) Enter password: 
Done.

Installing JBoss AS to /opt/czechidm... done.

Adding MySQL connector to JBoss...
  Enter the location of the MySQL connector JAR file (or type SKIP to configure it manually):
/tmp/mysql-connector-java-5.1.8.jar 
Done.

Configuring JBoss as a service to /etc/init.d/jboss... done.

JBoss for CzechIdM installation completed.

You can start JBoss with the command 'service jboss start'.

JBoss máme nainstalovaný, takže spustíme server příkazem:

$service jboss start

Samotné spuštění chvilku trvá, většinou se připravte na 2 až 3 minuty čekání. Mezitím se tedy přesuneme do složky, kde je uložený log ze serveru, a budeme kontrolovat, zda-li se při startu neobjeví nějaká chyba. Přesuneme se  tedy do složky s logem a pomocí příkazu tail -f se podíváme na log.

$cd /opt/czechidm/jboss/server/default/log/
$tail -f server.log

Po úspěšném spuštění JBoss serveru budeme mít na posledním řádku zobrazeno

[org.hibernate.util.NamingHelper] (JbpmJobExecutor@127.0.0.1:Executor-1) JNDI InitialContext properties:{} 
Instalace CzechIdM

Nyní máme úspěšně nainstalované a spuštěné prostředí pro CzechIdM. Přejdeme tedy k jeho instalaci. Jako první krok se přesuneme do složky, kde máme uložený instalační skript

$cd /tmp/czechidm-jboss-2014q1/scripts

a spustíme instalaci CzechIdM

$./install_czechidm.sh

Pokud proběhne vše v pořádku, máme vyhráno. Úspěšně jsme nainstalovali CzechIdM a můžeme se s ním začít učit. Spustíme prohlížeč, zadáme adresu http://localhost:8080/idm a můžeme se začít seznamovat s CzechIdM.

Snímek obrazovky pořízený 2014-07-27 20:43:38

Odinstalace CzechIdM

Pokud se z nějakého důvodu rozhodneme odinstalovat CzechIdM z počítače, musíme nejprve vypnout JBoss server pomocí příkazu

$service jboss stop

Pak přejdeme do složky, kde máme CzechIdM

$cd /tmp/czechidm-jboss-2014q1/scripts

A spustíme odinstalaci

$./uninstall.sh

Tento skript nám odinstaluje CzechIdM z počítače.

Závěr

V tomto článku jsme si ukázali, jak nainstalovat prostředí pro spuštění CzechIdM a jak nainstalovat samotné CzechIdm do našeho počítače. Příště si ukážeme, jak vytvořit tabulku v MySQL, jak nastavíme konektor pro systém a propojíme CzechIdM s databází.

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

Oracle – co dělat když se rozsype ASM

Na Oracle clusteru používáme ASM pro ukládání souborů databáze. Když všechno běží, je to paráda. Když se něco pokazí, je to paráda trochu menší, ale náprava naštěstí nebývá složitá. Jednoho dne se v našem ASM pokazila metadata a následkem toho ztratilo přehled o discích s daty. Co se vlastně stalo a co s tím dělat se dočtete dále.

Co to vlastně je ASM?

Diskgroups

U Oraclích databází máme dvě možnosti, kam ukládat data – buď klasicky na filesystém nebo na ASM. ASM stojí na principu tzv. groups. Grupa je zhruba analogická oddílu filesystému – může na ní ležet jedna nebo více databází, podle potřeby.

ASM potom podle nastavené redundance dat v grupě (external=žádná, normal=mirror, high=mirror s dvěma kopiemi dat) využívá datová úložiště a samo se stará o uložení a správu datových bloků, tzv. extents.

Aby to nebylo tak jednoduché, grupa je rozdělena na logické celky, kterým se říká failgroups. Pro ty platí vše, co jsme zatím zmínili o grupě. Pokud má grupa jen jeden disk, je tento disk vlastně samostatnou failgrupou.

Podle nastavené redundance je pak vyžadován určitý počet failgroup v grupě. Například pokud budeme mít normal redundancy grupu DBG a v ní failgrupu DBFG1 s jedním diskem. Po přidání dalšího disku do DBG se automaticky vytvoří DBFG2, pokud mu to ovšem explicitně nezakážeme. Tyto failgroup jsou vzájemně mirrorem. Pokud bychom přišli o celou DBFG1, databáze stále poběží, protože všechna data máme v kopii v DBFG2.

ASM instance

Ačkoli jde o datové úložiště, dokáže se ASM do určité míry chovat jako instance databáze. K této instanci pak jako klienti lokálně přistupují jednotlivé databáze.

K administraci ASM slouží utilita asmcmd, což je ekvivalent přizpůsobené a hodně osekané příkazové řádky. Protože se ale ASM dokáže chovat jako databázová instance, nic nám nebrání se k ní připojit přes sqlplus. Potom si můžeme v klasickém SQL stylu spouštět i dotazy na vlastnosti, stav a aktuální akce.

Co se vlastně stalo

„Příčina nehody: neznámá. Místo: neznámé. Čas: neznámý. Doufám, že tyto informace pomohou objasnit nehodu, ke které tu došlo.“ –Kryton, seriál Červený trpaslík

Citát to vystihuje naprosto přesně. ASM se jednoho dne prostě rozhodlo, že se mu DBFG1 nelíbí, vyhodilo z ní všechny disky a pak se ji pokusilo z DBG odebrat. Odebírání disků z grupy je běžná věc – jde o automatický mechanismus, kdy ASM při zjištění mrtvého disku (nelze z něj číst nebo na něj zapisovat) tento disk po určité době odstraní. Následně přesype data v grupě, aby vyžila s tím, co jí zůstalo, a zároveň co možná nejlépe splnila podmínky na redundanci dat. Odstraněným diskům se nastaví hromada příznaků, aby šlo poznat, co se s nimi dělo. ASM také každé odstranění zaloguje.

Stav po zjištění problému byl následující: u disků právě probíhalo odstraňování, ASM ale nepřesýpalo data, příznaky u disků byly podivně nastavené a v logách instance bylo prázdno. Podle operačního systému byly disky dostupné po celou dobu běhu serveru.

Vše tedy ukazovalo na neplechu v ASM. Takže aktuálně vyřešit nápravu a potom hledat příčinu, pokud ji vůbec máme šanci najít.

Chybový stav

Připojil jsem se do ASM jako „sqlplus / as sysasm“ a vypsal si grupy:

SQL> select mount_status, header_status, state, failgroup, os_mb, total_mb, path from v$asm_disk;

MOUNT_STATUS	HEADER_STATUS	STATE	FAILGROUP	OS_MB	TOTAL_MB	PATH
--------------------------------------------------------------------------------------------------------
MISSING		UNKNOWN		FORCING	DBFG1		0	26624
CLOSED		MEMBER		NORMAL			26624	0		/dev/mapper/dbfg1_disk
CACHED		MEMBER		NORMAL	DBFG2		26624	26624		/dev/mapper/dbfg2_disk

Můžete si všimnout, že disk z DBFG1 podle ASM nemá korektní hlavičku. Tady s ním moc neuděláme, podíváme se přímo do operačního systému.

kfed

Kfed je šikovná utilita, která člověku umožňuje hrabat se přímo v metadatech ASM disku. Navíc nepotřebuje, aby běželo cokoliv z Oracle stacku. Stačí mít disk namountovaný v operačním systému nebo mít fungující ASMlib (pokud je používán). Pomocí „kfed read“ si vypíšeme hlavičku disku (offsety úplně nesedí, protože DBG a DBFG jsou upravené názvy):

[root@node1 ~]# kfed read /dev/mapper/dbfg1_disk
...
kfbh.type:                            1 ; 0x002: KFBTYP_DISKHEAD
...
kfdhdb.grptyp:                        2 ; 0x026: KFDGTP_NORMAL
kfdhdb.hdrsts:                        3 ; 0x027: KFDHDR_MEMBER
kfdhdb.dskname:               	  DBG_0 ; 0x028: length=5
kfdhdb.grpname:                     DBG ; 0x048: length=3
kfdhdb.fgname:                	  DBFG1 ; 0x068: length=5
...

Stručný význam jednotlivých polí, konkrétní hodnoty si můžete vyčíst třeba zde:

type - typ hlavičky, zde nám říká, že jde o ASM diskovou hlavičku
grptyp - typ redundance grupy, kam disk patří
hdrsts - stav disku vůči grupě
dskname - jméno disku
grpname - jméno grupy
fgname - jméno failgrupy

Takže tímhle to nebude. Ještě pomocí „kfed find“ zkontrolujeme metadata disku:

[root@node1 ~]# kfed find /dev/mapper/dbfg1_disk
Block 0 has type 1
Block 1 has type 2
Block 2 has type 3
... (všechno další musí být "type 3")

Příkaz find projde bloky disku a vyzkouší, zda sedí metadata bloků. Odhalí tedy špatné checksumy, ale nikoli chyby v datech. Pokud budou v bloku poškozená data, ze kterých bude správně spočten checksum, nedozvíme se to.

Náprava

Poškozená fyzická data nás momentálně netrápí, protože databáze normálně běží a klienti v ní spouštějí dotazy. Disk z grupy vypadl před nějakou dobou, a tedy ho stejně musíme sesynchronizovat, aby obsahoval aktuální data. Protože disk nevypadá poškozený, prostě ho do grupy našťoucháme zpátky:

SQL> alter diskgroup DBG add failgroup DBFG1 disk '/dev/mapper/dbfg1_disk';

Na což Oracle zareaguje hlášením, že disk už součástí nějaké grupy je. Trochu příkaz upravíme (protože v tomto případě nic rozbít nemůžeme):

SQL> alter diskgroup DBG add failgroup DBFG1 disk '/dev/mapper/dbfg1_disk' force;

Což už projde. Inu, co nejde silou…
Teď jsme tedy přidali disk do grupy a proběhne přesýpání (tzv. rebalance). ASM má najednou více failgroup, takže si na ně rozhodí data kvůli redundanci. Proces chvilku trvá a lze ho uspíšit explicitním zvýšením priority. Konkrétní dotaz, který jsem použil při nápravě:

SQL> alter diskgroup DBG add failgroup DBFG1 disk '/dev/mapper/dbfg1_disk' force rebalance power 4;

Parametr „power“ může nabývat hodnot 0-11 (0-STOP,11-TURBO:) ), default je 1. Grupa se rebalancovala a od té doby běží vše tak, jak má.
U velkých databází může rebalance trvat dlouho, proto je dobré použít „power“ a trochu přesýpání pomoci. Aktuální činnost ASM lze získat výpisem:

SQL> select * from v$asm_operation;
GROUP_NUMBER	OPERA	STATE	POWER	ACTUAL	SOFAR	EST_WORK	EST_RATE	EST_MINUTES	ERROR_CODE
------------------------------------------------------------------------------------------------------------------
1		REBAL	RUN	4	2	475	2310		1360		0

Závěr

V článku jsem představil postup nápravy chybného stavu ASM za použití standardních utilit dodávaných s Oracle databází. Dále jsme si ukázali utilitku kfed, jakožto rychlého pomocníka pro orientaci v datech ASM disků. Podobný postup se uplatňuje, pokud disky skutečně oprávněně vypadnou z ASM grupy – v takovém případě není třeba nic „forcovat“. Pokud vás článek zaujal, nebo byste se chtěli zeptat na cokoliv ohledně ASM a Oracle DB, neváhejte mne kontaktovat na petr.fiser@bcvsolutions.eu.

CzechIdM na Windows? Není problém!

Windows-supportPři příležitosti vydání nového releasu CzechIdM a jeho zveřejnění jsme řešili, jak udělat instalaci CzechIdM co nejjednodušší a tím nejvíce dostupnou.

Vznikl instalační návod a několik instalačních skriptů, které automaticky konfigurovaly potřebné aplikační prostředí. Protože ale vývoj CzechIdM probíhá na Linuxu a zároveň všechny dosavadní instalace jsou na Linuxu, vznikly tyto skripty právě jen pro Linux. Jak CzechIdM, tak i aplikační server na kterém CzechIdM běží jsou napsané v Javě, proto není problém ho spustit na všech systémech.

Jako cíl jsme si tedy dali zprovoznění CzechIdM i pro Windows o kterém budu právě pojednávat v tomto článku. Celkově se instalace na Windows liší pouze v odlišné konfiguraci specifické pro Windows. Pokud by vás zajímalo více obecně o instalaci a jejích detailech, přečtěte si článek Zjednodušení instalace CzechIdM.

Stažení balíčku CzechIdM

Nejprve si stáhneme distribuční balíček CzechIdM z http://www.czechidm.com/getstarted/. Ten obsahuje aplikační server, potřebné sql skripty na úvodní naplnění dat a uploader. Nejprve si zkopírujeme složku jboss-5.1.0.GA tam, kde chceme mít CzechIdM nainstalované. Zde je třeba dát pozor na příslušná oprávnění – je dobré zkopírovat tuto složku do nějaké uživatelem vlastněné složky. Kdybychom ji zkopírovali například do Program files, je možné, že by CzechIdM nenaběhlo z důvodu výších nároků na práva.

Zprovoznění aplikačního prostředí

Nejprve je třeba stáhnout a nainstalovat MySQL server a databázi. Najdeme ho na adrese http://dev.mysql.com/downloads/. Podporované jsou verze 5 a vyšší. Spustíme MySQL server (nachází se ve složce bin/mysqld.exe). Nyní je třeba založit databázi a nakonfigurovat uživatele, přes kterého se CzechIdM do MySQL připojuje. Na to naštěstí máme skripty, které vše udělají za nás. Překopírujeme všechny sql skripty do lokace, kam jsme nainstalovali MySQL do složky bin. Přesměrujeme skript initial_import.sql na standartní vstup mysql přes CMD.

mysql -u root < create_repository.sql

Dále stáhneme MySQL JDBC connector z http://search.maven.org/remotecontent?filepath=mysql/mysql-connector-java/5.1.8/mysql-connector-java-5.1.8.jar. To je konektor, který umožnuje CzechIdM se připojit právě do MySQL databáze kam si ukládá svoje vlastní data. Tento konektor musíme nakopírovat do složky, kde máme překopírovaný jboss do server/default/lib/ a server/default/deploy/CzechIdM-ear.ear/lib/. Zároveň ho musíme zkopírovat do složky, kam jsme stáhli distribuci CzechIdM do IdmUploader/IdmUploader_lib/.

Jako poslední bude třeba stáhnout a nainstalovat aplikační prostředí Javy. Najdeme ho na http://www.oracle.com/technetwork/java/javase/downloads a stáhneme JDK 1.7. Úspěšnou instalaci můžeme zkontrolovat v CMD zadáním

java -version

Instalace CzechIdM

V této fázi máme již vše potřebné připravené. Zbývá již jen spustit aplikační server JBoss a nahrát počáteční import dat do databáze. Server spustíme tak, že půjdeme na umístění, kam jsme ho zkopírovali do složky bin, kde spustíme run.bat. Tím by se měl začít server spouštět. Počkáme, než kompletně naběhne. To poznáme, že poslední věta v konzoli bude vypadat jako JNDI InitialContext properties:{}

Teď potřebujeme importovat počáteční data do databáze. Ty nám vytvoří výchozí uživatele v CzechIdM. Jdeme do složky MySQL/bin a zde zadáme do CMD

mysql -u root < initial_import.sql

Jako poslední úkol je nahrání aplikační logiky do CzechIdM. K tomu slouží program IdmUploader, který je ve složce distribuce, kterou jsme stáhli na začátku článku. Zde je třeba spustit runIdmUploader.bat. Import dat trvá obecně okolo 30 sekund.

Dokončení instalace

Jakmile máme AS JBoss spuštěný, MySQL máme připojený do CzechIdM a zároveň jsme provedli počáteční import, můžeme se přihlásit do administrátorského rozhraní. To se typicky nachází na adrese http://localhost:8080/idm. Pro přihlášení použijeme účet superadministrátora, která má login „admin“ a počáteční heslo je stejné. Nezapomeňte si toto heslo v konfiguraci změnit jako první!

Závěr

Tímto by měla být instalace CzechIdM hotová a můžete se k němu připojit přes http://localhost:8080/idm, kde se příhlásíte jako admin s heslem admin. Kdyby jste měli nějaké otázky či problémy s instalací CzechIdM na Windows, neváhejte se obrátit na filip.mestanek@bcvsolutions.eu.

CzechIdM je nyní dostupný pod svobodnou licencí a zdarma!

V současné době jsou hlavním tématem v mnoha společnostech úspory. Není vůbec snadné prosadit jakýkoliv nový projekt. Na druhou stranu ICT prostředí je vystavováno stále větším nárokům a rozrůstají a zvyšují se i požadavky na jeho bezpečnost. Pomocníkem v této situaci je Identity management, který spravuje uživatelské účty, role, skupiny, organizační zařazení a jejich vztah k jednotlivým aplikacím a datům. Jak tedy nasadit centrální správu identit, bez velkých výdajů za licence a s využitím vlastních pracovníků?

bcv

Společnost BCV solutions s.r.o., leader v oblasti Identity a Access Managementu, nabízí pomocnou ruku. Po dlouhých letech vývoje a vylepšování svého identity manageru CzechIdM, který spravuje již více než 2 000 000 účtů, přibližuje na českém trhu řešení IDM každému. CzechIdM je nyní dostupné pod svobodnou licencí a zdarma! Proč se k tomuto kroku naše společnost přiklonila?

„Již od založení společnosti v roce 2008 bylo naším cílem především pomáhat firmám se správou identit. Poptávka po CzechIdM dlouhodobě překračuje naše možnosti. Protože chceme držet kvalitu implementací projektů, kontrolujeme náš růst.  Rozhodli jsme se dát CzechIdM k dispozici zdarma pod svobodnou licencí všem, kdo potřebují kvalitní a prověřené řešení IDM,” říká Lukáš Cirkva, ředitel společnosti BCV solutions s.r.o.

 

czechidm

 

Může CzechIdM pomoci právě Vám?

CzechIdM zajišťuje kompletní řešení správy uživatelských účtů pro malé a střední společnosti, instituce státní správy a zdravotnická zařízení. Toto řešení se tak stává dostupnější alternativou k již existujícím produktům společností Oracle, IBM či Novell.

Kdokoliv si produkt CzechIdM stáhne, je schopen jej nainstalovat, snadno připojit systémy a především jej používat,“ doplňuje Lukáš Cirkva.

Pokud vás řešení CzechIdM zaujalo a máte zájem o více informací či instalační soubory, navštivte nás na www.czechidm.com.

O BCV solutions

BCV solutions s.r.o., česká společnost se sídlem v Praze se zaměřením na poskytování IT řešení a služeb. Pomáháme zlepšit Identity a Access Management. Aktuálně zákazníkům pomáháme spravovat přes 2.000.000 účtů!

Kontakt

Lukáš CIRKVA, CEO
tel.: +420 724 111 809
email: lukas.cirkva@bcvsolutions.eu
http://www.bcvsolutions.eu

Nové možnosti delegování úkolů v CzechIdM

Možnost delegovat své schvalovací úkoly na jinou osobu máme v CzechIdM již delší dobu. V nedávné době se nám od našich zákazníků sešlo několik požadavků, jak tyto delegace dále zlepšit a rozšířit. Jedním z požadavků například bylo, aby administrátor s danými právy mohl nastavovat delegace za jiné uživatele. Dále jsem se rozhodli přepracovat GUI delegací tak, aby bylo pro uživatele přívětivější. Pojďme se tedy na tyto změny podívat.

czechidm

 

Práva pro administrátory k delegování

Dříve právo na delegování svých úkolů měli pouze uživatelé samotní, což se v některých případech ukázalo jako nepraktické. V lepším případě uživatel jen odjel na dovolenou a úkoly zapomněl delegovat na svého kolegu. Pokud by chtěl administrátor delegování nastavit místo onoho uživatele měl jedinou možnost. Resetovat heslo do CzechIdM, změnit nastavení a pak uživateli vysvětlit, že si má nastavit nové heslo.
Nyní se administrátor přihlásí do admin rozhraní a u všech uživatelů, které má ve své kontrolované organizaci má možnost kliknout na Delegovat úkoly ve sloupci Akce. Odkaz administrátora přenese na delegaci úkolů daného uživatele. Aby mohl administrátor takto přejít na delegaci úkolů, musí mít přidělená oprávnění, což je možné dvěma způsoby:

  • Jedná se o administrátora, který má přidělenou superAdmin roli, tudíž může vše
  • Jedná se o normálního administrátora, tudíž musí mít přidělenou admin roli s oprávněním:
    • USER_TASK: DELEGATE
    • USER: READ – pro čtení seznamu uživatelů (není nutné, pokud má oprávnění přidělené pomocí jiné role
    • ORGANISATION: READ – pro čtení organizační struktury (není nutné, pokud má oprávnění přidělené pomocí jiné role)

users_delegace_ukolu_u

Přívětivější GUI delegací

Díky častému nasazení a použití delegací v některých projektech jsme zjistili, že původně navržené GUI není tak intuitivní, jak jsme byli přesvědčeni. Proto jsme přistoupili k jeho změně a nyní formulář uživatele opticky provede celým nastavením delegací. Navíc uživatel okamžitě v přehledu na stejné stránce vidí, jaké nastavení delegací má nastavené.

delegace_u

Nejprve uživatel vybere čas, kdy má být delegování aktivní, následně na koho se mají úkoly delegovat a následně novou delegaci uloží.
Po uložení delegace musí uživatel, na kterého mají být úkoly delegovány, požadavek schválit. Stav uživatel vidí v přehledu delegací ve spodní části stránky.

Závěr

V článku jsme si ukázali novou funkci pro delegování úkolů, která dává administrátorovi další práva a nové GUI, které je nyní daleko přívětivější. Pokud byste měli zájem o další informace o delegování nebo měli jakékoliv otázky, můžete mě kontaktovat na Jan.Effenberger@bcvsolutions.eu

 

9 důvodů, proč dát přednost CzechIdM před Oracle Waveset

V poslední době se mě na prezentacích a školeních čím dál častěji ptají, v čem je náš Identity Management CzechIdM lepší než dosluhující Oracle Waveset, dříve nazývaný též Sun Identity Manager. Jako projektový manažer i vývojář jsem se na vlastní kůži setkal s oběma; nedávno jsem tu psal o úspěšné migraci z Oracle Waveset na CzechIdM ve Všeobecné fakultní nemocnici. Můžu tedy srovnávat, důvodů k migraci je celá řada.

  1. Podpora – CzechIdM je svým tvůrcem stále rozvíjeno.
    Zatímco Oracle Waveset je jako produkt mrtvý, CzechIdM se vyvíjí podle požadavků zákazníků, reaguje na technologické trendy a přizpůsobuje se novým verzím napojovaných systémů.
  2. Otevřené zdrojové kódy – Pokud máte Waveset, máte černou skříňku.
    S Wavesetem jste si nainstalovali předkompilované binární soubory, které si nepřečtete ani nepřizpůsobíte. Zákazníci CzechIdM naproti tomu dostanou kompletní zdrojové kódy a je na nich, zda budou chtít něco upravit.
  3. Příjemnější rozhraní – uživatelé mají raději CzechIdM.
    Rozdíl je v detailech: jednodušší menu, větší tlačítka, smysluplnější popisky, méně klikání v obvyklých situacích, přehlednější nápověda…
  4. Méně práce pro vývojáře – přizpůsobit CzechIdM je rychlejší a stojí to méně peněz.
    Kdo někdy programoval pro Oracle Waveset, dá mi za pravdu: napsat jednoduchý proces pro Waveset znamená naučit se podivný jazyk XPress a napsat v něm tisíc řádků kódu. CzechIdM používá standardní Javu, pokud jste se s ní potkali aspoň na gymnáziu, nejspíš byste zvládli napsat svůj první proces pro CzechIdM ještě dnes. Zákazník tak ušetří přes 30% nákladů.
  5. Výkon – CzechIdM zvládne za stejný čas více práce.
    Waveset drží všechny své objekty v XML struktuře. CzechIdM má datový model chytřejší: využívá všech výhod moderních relačních databází. Díky tomu pracuje s uživateli, účty a rolemi rychleji a efektivněji.
  6. Bezpečnost – tvůrci CzechIdM reagují na rizika.
    Ve světě informačních systémů se každý rok objevují nová bezpečnostní rizika – v databázích, aplikačních serverech, programovacích jazycích… Zatímco programátoři CzechIdM novým slabinám v technologiích čelí (viz nedávno odhalená bezpečnostní chyba v MySQL, na kterou museli reagovat, http://blog.sucuri.net/2012/06/security-vulnerability-in-mysql.html), Waveset už jen stojí na místě: bezpečnostní díra u něj zůstane dírou navždy..
  7. Jednodušší pro administrátory – s CzechIdM se administrátor rychleji naučí pracovat
    CzechIdM má jen ty funkce, které jsou skutečně potřeba. Administrátor tak může hned dělat svou práci a netráví dlouhý čas studiem nového produktu. Kompletní dokumentace v češtině taky není k zahození.
  8. Lokální tvůrce – tým vývojářů v Česku
    Na rozdíl od Wavesetu je CzechIdM stoprocentně český produkt vyvinutý lokální společností. Když zákazník potřebuje pomoc, dorazí k němu expert, který CzechIdM sám vytvářel a zná produkt do posledního řádku kódu.
  9. Prezentační vrstva na míru – JSF vs. XPress
    Složitější formulář pro Waveset jsou 3 dny práce v jazyce XPress a výsledek pravděpodobně nebude úplně podle vašich představ. CzechIdM stejně jako většina dnešních aplikací používá JSF, formulář bude za odpoledne a po stránce vzhledu je realizovatelné prakticky cokoli.

Ano, mít důvodů deset, vypadalo by to lépe. Máte podobnou zkušenost jako já? Pomůžete nám vymyslet desátý důvod? Kontaktovat nás můžete na adrese info@bcvsolutions.eu.

CzechIdM umí synchronizovat i bez programování

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

Workflow pro každý účet

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

Standardní implementace

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

Používané termíny

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

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

Modelový příklad

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

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

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

Nastavení systémů

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

Nastavení atributů systému Personalistika

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

Atributy_schematu_personalistika

Nastavení synchronizace systému Personalistika

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

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

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

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

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

Nastaveni_synchronizace_systému_personalistika

Nastavení rekonciliace systému Personalistika

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

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

Nastaveni_rekonciliace_systému_personalistika

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

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

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

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

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

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

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

Mapovani_atributu_synchronizace_personalistika

Nastavení atributů systému Doména

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

Atributy_schematu_domena

Nastavení rekonciliace systému Doména

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

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

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

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

Nastaveni_rekonciliace_systému_domena

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

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

Mapovani_atributu_reconciliace_domena

Drobná poznámka před koncem

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

Závěr

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

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

Jak zabezpečit Liferay portál pomocí HTTPS

Pro našeho zákazníka jsme implementovali portlet pro zabezpečené přihlášení do jeho interních aplikací. Tento portlet je umístěn na Liferay portálu a po ověření loginu a hesla proti Access Manageru SunSSO (technologii popsal kolega zde) vydá uživateli SSO cookie. Součástí tohoto úkolu bylo zabezpečit Liferay portál, aby k přihlašovací stránce šlo přistupovat pouze pomocí HTTPS. Na druhou stranu bylo nutné, aby k jiným stránkách portálu bylo možné nadále přistupovat přes HTTP.

V tomto článku vás seznámíme se způsobem, jak jsme tento požadavek vyřešili.

Analýza prostředí

V prostředí našeho zákazníka běží portál Liferay 6.1.2 CE na aplikačním serveru Tomcat 7.0.40.

Jedno z řešení, které bychom mohli použít, by spočívalo v nastavení HTTPS přímo do konfigurace Tomcatu. Druhou možností bylo nainstalovat před Liferay web server, který se postará o zabezpečení přes SSL a požadavky bude lokálně předávat aplikačnímu serveru již nešifrovaně.

Zvolili jsme druhý přístup, protože umožňuje větší flexibilitu a i do budoucna snazší řešení specifických požadavků zákazníka. Vybrali jsme Apache web server, který bude poskytovat následující služby:

  • Na portu 80 bude poskytovat přístup k Liferay portálu přes HTTP.
  • Na portu 443 bude poskytovat zabezpečený přístup k Liferay přes HTTPS. Pro ověření pravosti serveru bude nabízet certifikát uložený na serveru.
  • Přistoupí-li uživatel přes HTTP, zůstane po celou dobu na nezabezpečeném kanálu. Podobně pro HTTPS – po prvním přístupu na HTTPS už na něm uživatel zůstane. Není žádoucí vyžadovat jen zabezpečený přístup.
  • Předchozí bod má jednu výjimku, a to u stránky pro přihlášení. Zde je vždy vynucen přístup přes HTTPS.

Pro zajištění všech uvedených služeb stačí do standardní instalace Apache přidat ještě modul mod_ssl.

Nastavení Apache

Web server Apache a modul mod_ssl jsme nainstalovali ze standardních balíčků operačního systému CentOS:

$ yum install httpd
$ yum install mod_ssl

Dále ověříme, že jsou přítomné moduly mod_proxy a mod_proxy_ajp (na CentOSu jsou součástí standardní instalace Apache). Pokud nejsou, nainstalujeme je podobně jako mod_ssl.

Instance Apache je umístěna v adresáři /etc/httpd. Zde vytvoříme adresář ssl, kam umístíme náš certifikát a jeho soukromý klíč (mujweb.cz.cert a mujweb.cz.key).

Konfiguraci portů chceme mít umístěnou v jednom souboru, proto v hlavním konfiguračním souboru v conf/httpd.conf zakomentujeme řádek Listen 80. Ve složce conf.d přidáme ke všem konfiguračním souborům např. příponu „.orig“, aby je Apache nenačítal (případně je můžeme rovnou smazat).

Následně vytvoříme hlavní konfigurační soubor v adresáři conf.d:

LoadModule ssl_module modules/mod_ssl.so
Listen 80
Listen 443
SSLPassPhraseDialog builtin
SSLSessionCache "shmcb:/var/run/ssl_scache(512000)"
SSLSessionCacheTimeout 300
SSLMutex "file:/var/run/ssl_mutex"

<VirtualHost mujweb.cz:80>
    ServerName mujweb.cz

    <IfModule mod_proxy.c>
        ProxyRequests Off
        ProxyVia On
        <Proxy *>
            Order Allow,Deny
            Allow from All
        </Proxy>
        <LocationMatch "/web/login">
            Redirect permanent / https://mujweb.cz/
        </LocationMatch>
        ProxyPass / ajp://localhost:8009/
    </IfModule>
</VirtualHost>
<VirtualHost mujweb.cz:443>
    ServerName mujweb.cz

    <IfModule mod_proxy.c>
        ProxyRequests Off
        ProxyVia On
        <Proxy *>
            Order Allow,Deny
            Allow from All
        </Proxy>
        ProxyPass / ajp://localhost:8009/
        </IfModule>

        SSLEngine on
        SSLProtocol -ALL +SSLv3 +TLSv1
        SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM
        SSLCertificateFile "/etc/httpd/ssl/mujweb.cz.cert"
        SSLCertificateKeyFile "/etc/httpd/ssl/mujweb.cz.key"
        SSLVerifyClient none

        <FilesMatch "\.(cgi|shtml|phtml|php)$">
            SSLOptions +StdEnvVars
        </FilesMatch>

        BrowserMatch ".*MSIE.*" \
        nokeepalive ssl-unclean-shutdown \
        downgrade-1.0 force-response-1.0

        ErrorLog "logs/httpd-error.log"
        TransferLog "logs/httpd-access.log"

        CustomLog "logs/httpd-ssl_request.log" \
            "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
</VirtualHost>

Všimněme si zvýrazněných řádků. První z nich zajistí, že při přístupu na přihlašovací stránku (http://mujweb.cz/web/login) je uživatel ihned natrvalo přesměrován na HTTPS. Řádek s direktivou ProxyPass / ajp://localhost:8009/ zajišťuje předávání požadavků do Liferay, čímž se podrobněji zabývá následující kapitola.

Nyní zbývá už jen nastartovat Apache a také nastavit, aby se automaticky spouštěl při každém restartu serveru:

$ service httpd start
$ chkconfig --level 2345 httpd on

Samozřejmostí, na kterou ale snadno zapomeneme, je, aby porty 80 a 443 byly povolené ve firewallu :-)

Nastavení Liferay

Tomcat běží standardně na portu 8080, kde poskytuje stránky portálu. Zároveň ale na portu 8009 poslouchá jeho AJP konektor, který je určen ke komunikaci aplikačního serveru s web serverem. Požadavky na web server proto směřujeme na tento port, což zajistí, že Liferay dostane informaci o tom, jakým způsobem uživatel přistupuje. Liferay tuto informaci potřebuje zejména kvůli generování odkazů v rámci portálu (např. odkazy, kam se odesílají formuláře). Musí vědět, zda má vygenerovat odkaz pro HTTP, nebo HTTPS, či jaké má použít hostname.

V konfiguraci Liferay portálu je třeba provést nastavení dvou portálových proměnných. Obvykle se úpravy portálových proměnných provádí v souboru portal-ext.properties, ale pokud tento soubor z nějakého důvodu nechceme vytvářet, můžeme je napsat i přímo do portal-setup-wizard.properties, který je umístěn v adresáři, kam jsme instalovali Liferay.

Nastavíme následující proměnné:

web.server.http.port=80
web.server.https.port=443

Pokud bychom chtěli, aby Liferay generoval všechny URL adresy pro HTTPS, nastavili bychom ještě web.server.protocol=https. To ale pro nás v tomto případě nebylo žádoucí. V některých situacích bychom mohli dále nastavit web.server.host=preferovanyHost.cz, aby Liferay při generování URL odkazů používal hostname „preferovanyHost.cz“.

Po nastavení portálových proměnných zbývá už jen restartovat Liferay portál.

Závěr

Těch pár kroků uvedených výše stačí k tomu, že máme zabezpečný přístup k Liferay portálu přes HTTPS. Jednoduché, že?

Způsobů, jak zabezpečit Liferay portál i s uvedenými požadavky na přesměrování, je určitě mnoho, a pokud se o některé z nich chcete se mnou podělit, neváhejte se ozvat na můj e-mail alena.peterova@bcvsolutions.eu!