Co si pohlídat?
1) Mějte IDM admina, vlastníka systému
Pokud chcete mít úspěšný projekt Identity Managementu, určete zástupce, který bude IdM řešení v organizaci vlastnit. Pro zjednodušení nazvěme takového zástupce adminem IdM. Není to člověk, který musí umět programovat. Nemusí rozvíjet nebo spravovat systém. Je to zástupce investora, který rozumí funkcím řešení (ne nutně produktu) a ví, jak fungují interní procesy organizace. Admin zná, jaké systémy jsou integrované, do jaké úrovně a proč. Je schopen zhodnotit, zadat a obhájit další rozvoje. Nebo požadavky naopak dokáže odmítnout pro nízkou ekonomickou návratnost.
Admin pomůže s přechodem na nového servisního partnera Identity Manageru, protože ví, jak má systém fungovat z pohledu firmy. Pokud takového zástupce nemáte, doporučuji ho co nejdříve delegovat.
2) Vyberte správného dodavatele a produkt
Nesoustřeďte se na produkt. Dívejte se na implementační tým. Pobavte se s jeho členy. Nechte si ukázat reference, demo. Zavolejte referenčním zákazníkům. Nechte si navrhnout řešení na vaše potřeby. Dle toho nejlépe poznáte, zda máte správného dodavatele. Ano, stojí to čas, který se vám ovšem násobně vrátí.
Nenechte ovlivnit velkou značkou nebo Gartner diagramem. Setkáváme se s tím, že velké IT korporace mají zastaralý produkt. Již několikrát jsme migrovali zákazníka z “nej dle produktu Gartnera”, protože klient byl naprosto nešťastný z implementace i funkcí.
Potřebujete mezinárodní produkt nebo ten který je přizpůsobený na českou legislativu a aplikace?
Dostáváme dotaz: A jakou máme garanci, že neskončíte? Na to odpovídáme: A jakou máte jistotu u velkého dodavatele? Naopak velká IT firma produkt zařízne, bez lítosti. U IdM jsme se s tím v minulosti potkali několikrát, například u Microsoftu nebo Oracle. Garancí může být existence více implementačních partnerů, kteří řešení mohou převzít.
3) Smluvní náležitosti – řešení musí být vaše
Již při nákupu rozvažte, zda chcete pronájem řešení, nebo nákup. U IdM se v ČR potkáváme pouze s nákupem. U nákupu si pohlídejte, že veškeré dodané produkty – kód, dokumentace, postupy, návody, konektory, apod. – budou ve vašem vlastnictví.
4) Dokumentace, dokumentace, dokumentace
Kvalitní dokumentace je drahá věc. Nestačí jen produktové listy a návody how-to, postupy v GUI. Je třeba mít popsáno, jak fungují procesy správy uživatelů vašeho řešení. Jak jsou systémy integrovány, jaká data se předávají, jak jsou transformována, kam jsou předávána. IdM řešení bývá obvykle dost integrováno a přizpůsobeno. Dokumentace musí být pro administrátora, měla by být i pro vývojáře. Hlavním rysem vývojářské dokumentace není pouze “jak” je to implementováno, ale “jak a proč” je implementováno.
Jak poznáte, že je dokumentace kvalitní? Zapojte se (vašeho admina) do testovacího procesu nasazování nových verzí. Přebírejte nové funkce i s dokumentací. Co se týče kvality dokumentace, platí jednoduché pravidlo. Pokud dokumentaci nerozumíte, je něco špatně.
5) Kompletní zdrojové kódy
Tento bod je doporučením, není nutností. Mít dostupné zdrojové kódy je pro nezávislost výhodou. Dnes je několik dodavatelů poskytujících zdrojové kódy IdM. Je třeba mít funkční, kompletní a kvalitně zdokumentované zdrojové kódy celého řešení vaší verze. Nestačí mít zdrojové kódy po dodávce někde v sejfu. Systém se upravuje, ladí, rozvíjí. S tím se mění i zdrojové kódy. Osvědčuje se nám používat verzovací systém GIT. Požádejte svého dodavatele o přístup do GITu.
Aby zdrojové kódy byly výhodou, musíte s nimi pracovat dlouhodobě, ideálně již při stavění řešení. Vybudujte tým, který zapojte do budování řešení. Postupně technologie i procesy IdM nasávejte a tým školte na reálné práci. Jednorázové převzetí novým týmem je velmi náročným úkolem.
6) Perfektně zdokumentované API, využívejte otevřené technologie
Moderní SW bývá vícevrstvý – databáze, aplikační server, webový klientský portál. Backend s frontendem komunikuje jasně definovaným rozhraním, obvykle nějakou webovou službou. Identity Manager používá různá rozhraní ke komunikaci se spravovanými systémy.
Špatně definovaná rozhraní jsou obvykle to, co prodlužuje a prodražuje případnou výměnu identity manageru. Někdo musí jít, API znovu analyzovat, a pak podle něj lze teprve vytvořit implementaci pro nové IdM. Samotný identity manager lze považovat z hlediska instalace za krabicový produkt. Jeho napojení k ostatním systémům firmy z něj teprve dělá užitečnou věc. Nepodceňujte proto dokumentaci systémových rozhraní.
Dokumentace se dnes dá i dynamicky generovat. Například takto CzechIdM SWAGGER v našem IdStory.
Pro komunikaci IDM s aplikacemi lze využít i standard SCIM. System for Cross-domain Identity Management (SCIM) specifikace byla navržena pro jednoduchou správu uživatelských identit v cloudovém prostředí. Staví na principu RESTful API.
Závěr?
Může se stát, že se přechodu na jiný SW Identity Manager přesto nevyhnete.
