Univerzita Palackého v Olomouci I
AUTOCONT
SMLOUVA O DÍLO Číslo smlouvy Zhotovitele:
I.
RCS-2015-Z167
SMLUVNÍ STRANY:
OBJEDNATEL:
UNIVERZITA PALACKÉHO V OLOMOUCI
veřejná
vysoká škola zřízená zákonem č. 111/1998 Sb., o vysokých školách a o změně a doplnění některých zákonů (zákon o vysokých školách), ve znění pozdějších předpisů
se sídlem: rektor: osoba oprávněná jednat ve věcech technických:
Křížkovského 8, 771 47 Olomouc prof. Mgr. Jaroslav Miller, M.A., Ph.D.
RNDr. David Skoupil řed itel Centra výpočetní techniky tel. 585 631 703 email: dG d .. ~o
[email protected] IČ : 61989592 DIČ: CZ61989592 bankovní spojení: Komerční banka, a.s., pobočka Olomouc č. ú.: 19-1096330227/0100 (dále jen "objednatel") na straně jedné
a ZHOTOVITEL: se sídlem: zápis v obchodním rejstříku: statutární orgán: osob oprávněná jednat ve věcech smluvních: osoba oprávněná jednat ve věcech technických: IČ: DIČ:
bankovní spojení: c.u.: (dále jen "zhotovitel") na uzavřeli
AutoCont CZ a.s. Hornopolní 3322/34, 702 00 Ostrava- Moravská Ostrava u rejstříkového soudu v Ostravě , oddíl B, vložka 814 představenstvo akciové společnosti
Ing . Jaromír Vejpustek, Josef Szturc, 47676795 CZ47676795
ředitel
místopředseda představenstva
krajského obchodního zastoupení
česká spořitelna
5209452/0800 straně druhé
níže uvedeného dne, měsíce a roku podle ust. § 2586 a násl. zákona č. 89/2012 Sb. , zákoník, ve znění pozdějších předpisů (dále jen " občanský zákoník")
občanský
tuto
smlouvu o dílo (dále též jako "SoD" či "Smlouva"):
Objednatel se zhotovitelem uzavírají tuto smlouvu o dílo v důsledku skutečnosti , že nabídka zhotovitele na dodávku předmětu plnění dle této smlouvy byla objednatelem vybrána ve výběrovém řízení s názvem "jako nabídka nejvhodnější.
Strana 1
Univerzita Palackého v Olomouci
ll.
Předmět
AUTOCONT
díla
1. Za podmínek uvedených v této sm louvě o dílo se zhotovitel zavazuje na svůj náklad a v souladu s právními předpisy a platnými technickými normami, v rozsahu, způsobem, v jakosti a ve lhůtách podle této smlouvy, řádně a včas provést dílo - Implementace systému identity management/2015 , tj. analýza, dodávka, úprava a nasazení systému pro správu identit uživatelů informačních systémů Univerzity Palackého - identity management systému (dále jen "lOM"), včetně veškerých potřebných licencí, dokumentace, proškolení uživatelů a poskytnutí technické podpory v průběhu trvání záruční doby, to vše v souladu s technickými specifikacemi uvedenými v příloze č. 1 této smlouvy a v cenové nabídce zhotovitele ze dne doplní uchazeč, podané zhotovitelem v rámci poptávkového řízení , které předchází podpisu této smlouvy, jenž tvoří nedílnou součást této smlouvy jako její příloha č . 2. nebezpečí,
2. Objednatel se zavazuje převzít dílo, resp. jeho jednotlivé fáze za podmínek dále stanovených touto smlouvou a zaplatit za něj cenu dle čl IV. této smlouvy. 3. O předání a převzetí jednotlivých fází díla jsou smluvní strany povinny sepsat předávací protokol, v němž bude uvedeno datum předání díla. Objednatel v protokolu uvede, zda bylo dílo předáno řádně a včas , popř. zda uplatňuje u zhotovitele vady díla. Tento předávací protokol je za objednatele oprávněna podepsat RNDr. David Skoupil nebo jím pověřená osoba. 4. Vlastnické právo ke zhotovovanému dílu přechází v plném rozsahu na objednatele okamžikem předání a převzetí 2. fáze díla. Zhotovitel bere na vědomí , že dílo vytvořené podle této smlouvy je dílem vytvořeným na objednávku ve smyslu§ 61 autorského zákona a objednatel je oprávněn užít dílo k účelu vyplývajícímu z této smlouvy, tj. zejména ze specifikace obsažené ve smlouvě o dílo. Zhotovitel bere na vědomí , že nebude v podmínkách pro provozování díla uplatňovat žádné dodatečné licenční podmínky, a to ani SW produktů třetích stran. 5. Dílo musí být plně funkční , bez dalších dodatečných nákladů ze strany objednatele. 6. Objednatel je oprávněn změnit rozsah Díla v průběhu jeho provádění Zhotovitelem dle této Smlouvy o dílo v případě, že dojde ke zmenšení rozsahu Díla ve srovnání s rozsahem dle této Smlouvy o dílo a jejích příloh . V případě, že objednatel zmenší rozsah Díla v průběhu jeho provádění, nemá zhotovitel vůči objednateli žádné (ani finanční) nároky, plynoucí ze zmenšení rozsahu Díla. 7. Smluvní strany si ujednaly, že ustanovení § 2609 občanského zákoníku o svépomocném prodeji se v případě prodlení objednatele s převzetím kterékoliv části předmětu díla nepoužije. 8. Zhotovitel je povinen objednateli umožnit po skončení záruční doby přístup ke zdrojovým kódům programových komponent obsahujícím logiku konektorů na zdrojové a spravované systémy. Po skončení záruční doby musí být objednateli umožněny úpravy těchto kódů vlastními silami, bez nutností spolupráce se zhotovitelem a bez dalších licenčních nákladů, a aniž by došlo k porušení licenčních práv. K výše uvedenému proto zhotovitel uděluje objednateli nevýhradní licenci.
111. Doba a místo dodání
1. Zhotovitel je povinen zahájit plnění dle této smlouvy o dílo dnem podpisu této smlouvy poslední smluvní stranou.
Strana 2
Un iverzita Palackého v Olomouci
AUTOCONT
2. Dílčí termíny plnění·: a) Výstup první fáze díla (předimplementační analýzu), v rozsahu přílohy č . 1 této smlouvy , je zhotovitel povinen objednateli protokolárně předat nejpozději do 2 měsíců od uzavření této smlouvy poslední smluvní stranou. Zhotovitel je povinen na základě požadavků objednatele písemný výstup 1. fáze provedení díla před jeho protokolárním předání m podrobit připomínkovému řízení ze strany objednatele, připomínky vzešlé z tohoto řízení do výstupu zapracovat a zohlednit v rámci druhé fáze provádění díla; b) Druhá fáze díla (implementační projekt) , v rozsahu přílohy č. 1 této smlouvy , bude zahájena po protokolárním předání a převzetí výstupu první fáze a jeho odsouhlasení objedna telem a provedena nejpozději do 2 měsíců ode dne jejího zahájení ; c) Třetí fáze díla (instalace a implementace), v rozsahu přílohy č. 1 této smlouvy , bude zahájena nejdříve po předání a převzetí výstupu druhé fáze a jeho protokol árního převzetí objednatelem a provedena nejpozději do 3 měsíců ode dne jejího zahájení nebo do 18.12.2015, podle toho co nastane dříve ; d) Čtvrtá fáze díla (zkušební provoz, dokumentace, zaškolení obsluhy a úspěšné provedení akceptačních testů) bude zahájena po protokolárním předání a převzetí díla v rozsahu první až třetí fáze vč. ukončené implementace. Dodání dokumentace a zaškolení uživatelů bude provedeno nejpozději do 3 měs íců od zahájení čtvrté fáze díla. Zkušební provoz potrvá po dobu 3 měsíců. Pokud dojde v průběhu zkušebního provozu k závadám , doba zkušebn ího provozu se prodlužuje o stejnou dobu, po kterou nebyly informační systémy prokazatelně plně funkční. Čtvrtá fáze díla bude ukončena akceptačními testy, protokolárním ukončen ím zkušebn ího provozu a předáním jednotlivých informačních systémů do běžného provozu . 2. Místo
plnění:
Centrum
výpočetní
techniky UP, Biskupské nám. 1, 771 11 Olomouc.
IV. Cena za dílo 1. Objednatel se zavazuje zaplatit zhotoviteli za dílo dle této smlouvy cenu ve výši 992.500 bez DPH, DPH 21% činí 208.425 Kč. Celková cena za dílo včetně DPH čin í 1.200.92 5 Kč.
Kč
2. Celková cena za kompletní dílo je stanovena jako cena pevná, nejvýše přípustn á a maximální, zahrnuje veškeré náklady zhotovitele spojené s provedením a dodáním díla (zejmén a doprava na místo plnění , clo, pojištění , licenční poplatky , zaškolení obsluhy , technická podpora v rámci záruční doby atd.), a s poskytováním záručního servisu objedna teli. Změna ceny za dílo je možná pouze a jen za předpokladu , že dojde po uzavření této smlouvy ke změnám sazeb daně z přidané hodnoty. 3. Zhotovitel odpovídá za to, že sazba daně z přidané hodnoty v okamžiku fakturac e je stanovena v souladu s platnými a účinnými právními předpisy . 4. Smluvní strany si ujednaly, že cena za dílo sjednaná touto smlouvou nebude jakýmkoli kolísáním cen , včetně inflace a kurzových změn.
ovlivněna
V. Platební podmínky
1. Sjednaná cena díla je splatná na základě daňových dokladů (dále jen "faktur") řádně vystavených zhotovitelem, ve lhůtě splatnosti 30 dnů . Smluvní strany se dohodly , že úhrada ceny díla dle článku IV. této smlouvy bude provedena na základě řádn ě vystaven ých daňových doklad ů (dále jen "faktury") takto:
St rana 3
Univerzita Palackého v Olomouci
a) b)
AUTOCONT
75 % z celkové ceny za dílo bude uhrazeno po protokolárním předání a převzetí částí díla odpovídajícím čl. 111. odst. 2 písm. a), b) a c) této smlouvy, 25% z celkové ceny za dílo bude uhrazeno po protokolárním předání a převzetí části díla odpovídající čl. 111. odst. 2 písm. d).
doklad- faktura Zhotovitele musí mít náležitosti daňového a účetního dokladu podle účinných právhích předpisů, obsahovat požadavek na způsob provedení platby, bankovní spojení, datum splatnosti 30 dnů ode dne jejich doručení Objednateli, formou a obsahem musí odpovídat zákonu o účetnictví v účinném znění a zákonu o dani z přidané hodnoty v účinném znění a musí mít náležitosti obchodní listiny podle § 435 občanského zákoníku. 2.
Daňový
3. Nebude-li faktura obsahovat některou povinnou nebo dohodnutou náležitost nebo bude chybně vyúčtována cena nebo DPH, je Objednatel oprávněn před uplynutím lhůty splatnosti odeslat fakturu poštou zpět druhé smluvní straně k provedení opravy s vyznačením důvodu vrácení. Zhotovitel provede opravu vystavením nové faktury. Dnem odeslání vadné faktury Zhotoviteli přestává běžet původní lhůta splatnosti, přičemž objednatel tak není v prodlení se zaplacením fakturované částky, a nová lhůta splatnosti běží znovu nejdříve ode dne doručení nové řádně opravené faktury Objednateli. 4. Daň z přidané hodnoty bude zhotovitelem účtována v sazbě určené podle právních předpisů účinných ke dni uskutečnění příslušného zdanitelného plnění. 5. Zhotovitel současně jednoznačně prohlašuje, že nemá před provedením díla podle této smlouvy právo na přiměřené části odměny či zálohy ve smyslu § 2611, nepoužije se ani § 261 O odst. 2 občanského zákoníku. 6. Cena za dílo se považuje za zaplacenou dnem odepsání ceny za dílo z bankovního účtu objednatele ve prospěch bankovního účtu zhotovitele.
Vl. Záruka za jakost, vady díla, zaškolení obsluhy 1. Zhotovitel poskytuje objednateli na dílo záruku za jakost ve smyslu § 429 a násl. obchodního zákoníku v délce trvání 24 měsíců ode dne protokolárního předání a převzetí všech částí díla. Zárukou se rozumí zajištění technické kompatibility a funkčnosti v rozsahu odpovídajícím stavu v den protokolárního předání a převzetí celého díla. 2 . Zhotovitel se zavazuje poskytovat po dobu záruky technickou podporu v rozsahu této smlouvy. 3. Zhotovitel se zavazuje provést zaškolení obsluhy v rozsahu
Vll.
Sankční
přílohy č.
přílohy č.
1
1 této smlouvy.
ujednání
1. Za porušení smluvních povinností sjednávají smluvní strany následující smluvní pokuty: a) za prodlení zhotovitele s předáním jednotlivých částí díla ve lhůtách podle čl. 111. Odst. 2 písm. a), b), c) ad) této smlouvy je zhotovitel povinen zaplatit objednateli smluvní pokutu ve výši 2.000,- Kč za každý, byť započatý, den prodlení a za každou fázi díla samostatně; b) za prodlení zhotovitele se splněním povinnosti odstranit vadu díla v písemně dohodnuté lhůtě nebo v příslušné lhůtě podle přílohy č. 1 této smlouvy je zhotovitel povinen zaplatit objednateli smluvní pokutu ve výši 1.000,- Kč za každý, byť započatý, den prodlení a za každý případ samostatně;
Stra na 4
Univerzita Palackého v Olomouci
AUTOCONT
c) za prodlení zhotovitele se splněním povinnosti poskytnout techn ickou podporu v rozsahu přílohy č. 1 této smlouvy v písemně dohodnuté lhůtě nebo v příslušn é lhůtě podle přílohy č. 1 této smlouvy je zhotovitel povinen zaplatit objednateli smluvní pokutu ve výši 1.000,Kč za každý, byť započatý , den prodlení a za každý případ samosta tně. d) V případě porušení povinností uvedených v čl. Vlil. této smlouvy zhotovit elem, je objednatel oprávněn účtovat smluvní pokutu ve výši 100.000,-Kč za každé takovéto prokázané porušen í. 2. Sjednáním smluvních pokut podle tohoto článku smlouvy není dotčeno právo o právněné smluvní strany na náhradu škody vzniklé v příčinné souvislosti s poručením smluvní povinnosti utvrzované smluvní pokutou. Ustanov ení§ 2050 občanského zákoníku se nepouži je 3. Splatnost vyúčtovaných smluvních pokut a úroků z prodlení je 30 dnů od data doručení písemného vyúčtování příslušné smluvní straně a za den zaplacení bude považov án den odepsání částky smluvní pokuty z účtu příslušné smluvní strany ve prospěch účtu , který bude uveden ve vyúčtování smluvní pokuty. 4. Smluvní pokuty je objednatel za dílo.
oprávněn započíst
proti pohledávce zhotovitele na úhradu ceny
Vlil. Závazek mlčenlivosti a důvěrné informace Zhotovitel se zavazuje během plnění této smlouvy i po ukončen í plněn í této smlouvy zachovat mlčenlivost o všech skutečnostech , které se dozví od objedna tele v souvislosti s pl nění této smlouvy, s výjimkou informací, které jsou obecně známy. Pro informace, které objednatel prohlásil či prohlásí za předmět důvěrné informace, platí závazek ml čenlivosti bez omezení. Důvěrné informace nesmějí být použity k jiným účelům , než k plnění předmětu této smlouvy (při porušen í závazku diskrétnosti má objednatel právo na náhradu škody). Výjimku představuje situace, kdy zhotovitel je zproštěn tohoto závazku písemnou instrukcí objedna tele nebo v případech uvedených v příslušných právních předpisech ČR. Za důvěrné informa ce jsou považovány také informace o smluvních stranách či třetích osobách , mající charakte r osobních údajů dle ustanovení z. č. 101/2000 Sb. o ochraně osobních údajů.
IX.
Závěrečná
ujednání
1. Objednatel si vyhrazuje právo zveřejnit obsah
uzavřené
smlouvy o dílo.
2. Veškeré právní vztahy v této smlouvě neupravené a z ní vyplývající se zákoníkem a právním řádem České republiky.
říd í občans kým
3. Ujednání této smlouvy jsou vzájemně oddělitelná. Pokud jakákoli část závazku podle této smlouvy je nebo se stane neplatnou či nevymahatelnou , nebude to mít vliv na platnost a vymahatelnost ostatních závazků podle této smlouvy a smluvní strany se zavazuj í nahradit takovouto neplatnou nebo nevymahatelnou část závazku novou, platnou a vymaha telnou částí závazku , jejíž předmět bude nejlépe odpovídat předmětu původního závazku . Pokud by smlouva neobsahovala nějaké ujednání, jehož stanovení by bylo jinak pro vymezení práv a povinností odůvodněné , smluvní strany učiní vše pro to, aby takové ujednán í bylo do smlouvy doplněno. 4. Změnit nebo doplnit tuto smlouvu mohou smluvní strany pouze form ou písemný ch dodatků , které budou vzestupně čísl ovány, výslovn ě prohláše ny za dodatek této smlouvy a podepsá ny oprávněnými zástupci smluvní ch stran.
Strana 5
Univerzita Palacké ho
AUTOCONT
v Olomouci
5. Objednatel je oprávněn odstoupit od této smlouvy pro její podstatné · porušení zhotovitelem, přičemž podstatným porušením smlouvy se rozumí: • prodlení zhotovitele s dodáním jednotlivých fází díla delším než 10 dní, • nedodržení technické specifikace díla uvedené v nabídce zhotovitele. Odstoupení od smlouvy musí být učiněno písemně a nabývá účinnosti dnem doručení písemného oznámení druhé smluvní straně. V případě odstoupení od této smlouvy objednatelem z d ůvodu výše uvedených podstatných porušení smlouvy zhotovitelem , nemá zhotovitel nárok na náhradu jakýchkoliv do té doby vzniklých nákladů. 6. Zhotovitel není oprávněn bez souhlasu objednatele postoupit svá práva a povinnosti plynoucí z této smlouvy třetí osobě . 7. Tato smlouva o dílo nabývá účinnosti dnem jejího podpisu oběma smluvními stranami. 8. Tato smlouva o dílo je vyhotovena v pěti vyhotoveních s povahou originálu podepsaných oprávněnými zástupci smluvních stran, přičemž objednatel obdrží tři a zhotovitel dvě vyhotovení. 9. Nedílnou
součást
této smlouvy o dílo tvoří přílohy : specifikace předmětu veřejné zakázky
Příloha č. 1- Technická
-
Příloha č.
2 - Nabídka zhotovitele ze dne 25. června 2015
.
1 7 -07· 2015
V Olomouci, dne ...... ... .
'T
-
V Olomouci, dne 14. 7. 2015
P~Lí Cl
\ t. ·Jr é.Í t
lr ·n\""0'-<>.C!Q.l.!S----
. ·i) o ó. ' -r ,
. . . .. . . . . . . .. . . .. v'· ......... . ... ....... . .. ... .
prof. M r. Jaroslav Miller, M.A. , Ph.D. rektor
Ing . .d~~9 ír Vejp tek m · tqifedseday edstavenstva
Strana 6
Univerzita Palackého v Olomouci
Příloha č.
1 -Techn ická specifik ace
AUTOCONT předmětu veřejné
zakázky
Technic ké požada vky na implem entaci lOM: IDM umožní automatizovat správu uživatelských identit, uživatelských účtů a oprávně ní uživatelů v jednotlivých systémech v návaznosti na organizační strukturu UP. Na UP existují minimálně tři typy identit osob, a to zaměstnanců univerzity, studentů a externistů. Je přitom běžné, že identity nabývají více typů , a to jak postupně, tak i současně (např. současně student a zaměstnanec). Poptávané řešení IDM musí pokrývat všechny typy identit. Základními zdroji dat pro IDM je personální informační systém ERP SAP, systém studijní agendy IS/STAG a databáz e externistů . Zadavatel požaduje licencování nabízeného softwarového řešení formou perpetuální licence bez omezení na počet spravovaných identit a počet přistupujících uživatelů. Zadavatel požaduje
Nabídn uté
řešení
vytvoření produkčního
lOM musí
splňovat
a testovacího
prostředí.
všechn y níže uveden é požadavky.
Obecné požada vky IDM musí udržovat identity, skupiny identit a organizační struktury ve své vnitřní databáz i. Identity ve vnitřní databázi budou sloužit jako referenčn í identity pro ostatní informač ní systémy. IDM musí udržovat a spravovat kompletní životní cyklus identity. IDM musí umožňovat správu více organizačních struktur (větví) s možnosti přiřazen í jedné identity do více struktur najednou. Identita v JDM musí obsahovat kromě přihlašovacího jména uživatele ještě jiný jednoznačný a unikátní identifikátor nezávislý na údajích uživatel e (v prostředí UP nazývaný generuid). Identifikátor musí být zvolen tak, aby vždy byl jednoznačně spojen s konkrétní fyzickou osobou a aby se neměnil v případě změn souvisejících s touto osobou (např. při změně příjmení, pracovního zařazení apod.). Tento identifikátor je zpět zapisován do zdrojových systémů. Přihlašovací jméno uživatele musí být generováno podle algoritmu, který určí zadavatel. IDM musí umožňovat evidenci a správu certifikátů elektronických podpisů pracovn íků v souladu s jejich pracovními oprávněními , a to včet ně metadat (tj. vydavatel certifiká tu, pro koho je vydáno, sériové číslo , platnost od, platnost do, typ certifikátu atd.). IDM musí umožňovat evidenci a správu identifikačních čipových karet pracovníků spolu s jejich základními typy přístupových oprávnění. IDM musí implementovat princip založený na systemizovaných místech. IDM musí umožnit systemizaci pracovních míst v souladu se strukturou organizace, definova t jednotlivá systematizovaná místa a jejich činnosti a sadu oprávnění a rolí pro jednotliv é informační systémy organizace vztažené ke konkrétnímu systemi zovanému místu. IDM umožní přiřazení identit na takto vytvořená systematizovaná místa a to i ve vazbě M:N. Identita tedy může být v systému IDM evidována na více systematizovaných místech a současně na systematizovaném místě může být evidováno více identit. lOM musí umožňovat přidělení oprávnění nebo role konkrétní identitě , systemizovaném u místu, skupině nebo organizační jednotce. IDM musí umožňovat vytváření virtuálních organizací, tedy ad hoc sestave ných organizačních struktur, nezávislých na struktuře organizace, zejména pro účely realizace projektů.
IDM musí umožnit správu uživatelských rolí , včetně zařazení uživatele do odpovíd ající role. IDM musí k roli umožnit přiřazení sady upřesňujících atributů (např. zdroj financování); typy a struktura těchto atributů musí být uživatelsky definova ná
Strana 7
Univerzita Palackého v Olomouci
AUTOCONT
lOM musí umožnit nastavení schvalovacího workflow (při přidělení práva, role atd.), emailových notifikací a potvrzování. V lOM musí být možné dynamicky konfigurovat rozhodovací pravidla pro začleňování uživatelů do skupin nebo k rolím na základě atributů identity a přidružených referenčn ích objektů (organizační jednotka, role, systematizované místo atd.). Pravidla musí být možné spravovat v grafickém editovacím prostředí, které musí být součástí IDM. lOM musí umožnit definovat vztahy zastupitelnosti mezi uživateli. Musí umožnit uživatelům, aby mohli sami delegovat v případě potřeby (dovolená, služební cesta, atd.) svoje role na jiné pověřené osoby a to i tak, že jeden uživatel může mít pro každou svou činnost nastaveného jako zástupce jiného různého uživatele. Delegace rolí přitom musí být buď časově omezeny, nebo nastaveny na dobu neurčitou. lOM musí umožnit delegování administrátorských práv lOM. Veškeré požadavky, které provedou uživatelé na IDM, musí být provedeny transakčně, musí být historizovány a logovány tak, aby bylo možné zpětně prokázat kdo, kdy a co změnil v lOM identitách, referenčních objektech, ale i v administraci. Záznam v historii musí obsahovat původní i novou hodnotu. lOM musí umožnit definování jednotlivých úrovní administrátorských oprávnění k identitám a stromové struktuře. V lOM musí být zejména možnost vytvářet administrátorské role na úrovni jednotlivých organizačních jednotek, za účelem správy identit a přiřazování vybraných rolí pro uživatele v organizační jednotce (fakultě, katedře, univerzitním zařízení). lOM musí umožnit dodatečné přidávání vlastních atributů k identitám a referenčním objektům, naplňování jejich obsahu ze zdrojových systémů a jejich publikaci externím aplikacím přes rozhraní webových služeb. lOM musí umožňovat přesun identity v rámci organizační struktury i mezi jednotlivými organizačními strukturami. lOM musí umožňovat sloučit dvě identity do jedné. lOM musí mít možnost detekovat situaci, kdy se ve zdrojovém systému vyskytne jako nový uživatel, který již dříve byl v lOM založen (navracející se pracovník nebo student) a přiřadit jej k existující identitě. IDM musí umožňovat kopírovat role mezi jednotlivými systematizovanými místy. IDM musí obsahovat nastavení, které zabrání hromadným změnám z důvodu případných chybných dat na vstupu (například z personálního systému), tak, aby nedošlo k hromadným nežádoucím změnám (například smazání objektů v LOAP nebo v Active Oirectory, zablokování poštovních schránek atd.). lOM musí mít kompletní podporu českého jazyka i z hlediska dat, se kterými pracuje. IDM musí mít možnost případného ořezání diakritiky (např. v algoritmech tvorby uživatelského jména), a to i u jiných znaků než jsou v české abecedě. včetně
Požadavky na integraci Zdrojové systémy Zdrojem dat o zaměstnancích UP je ERP SAP. lOM musí umožňovat načtení dat uživatelů z ERP SAP včetně relevantních atributů a organizační struktury pomocí vzdáleného volání BAPI funkce (RFC). Formát předávaných dat ze SAPu je možno upravit na základě dohody s dodavatelem. Zdrojem dat o studentech UP je IS/STAG. IDM musí umožňovat načtení dat uživatelů z databáze tohoto systému nebo z databázového pohledu (view). Strukturu databázového pohledu je možno upravit na základě dohody s dodavatelem. Zdrojem dat o externistech je samostatná databáze nebo databázový pohled (view). Strukturu databázového pohledu je možno upravit na základě dohody s dodavatelem.
Strana 8
Univerzita Palackého v Olomouci
AUTOCONT
Spravov ané systémy Pod pojmem správa rozumíme automatizované nebo ruční založení , smazan1, zneplatnění nebo změnu dat ve spravovaném systému na zá kladě změny v některém ze zdrojových systémů. Kromě níže uvedených systémů musí IDM umožnovat napojení i dalších systémů pomocí obecného konektoru nebo integrační platformy. Napojení dalších systémů musí být umožněno provést vlastními silami zadavatele bez nutnosti spolupráce s dodavatelem a bez dalších licenčních nákladů. IDM musí umožnit připojení libovolného množství dalších spravovaných systémů a to bez dalších licenčních nákladů Součástí nabídkové ceny poptávaného řešení nejsou úpravy ve spravova ných systémech zadavatele. Předmětem
o
o
o
o
o
o o
o o o
zakázky je napojení těchto systémů: LDAP - lOM musí umožnovat komplexní správu účtů , skupin a členství ve skupinách v systému LDAP, zejména musí umožnit založení uživatele , změnu atributů u uživatele, zrušení uživatele, změny zařazení uživatele do skupin a správu skupin. MS Active Director y- lOM musí umožnovat komplexní správu účtů , certifikátů, skupin a členství ve skupinách v systému MS Active Directory, zejména musí umožnit založení uživatele, změnu atributů u uživatele, zrušení uživatele , změny zařazení uživatele do skupin a správu skupin. IDM musí dále umožnit založení domovského adresáře uživatele včetně nastavení oprávnění. lOM dále nesmí v AD přepisovat další nastavené atributy, které nejsou řízeny IDM. Sendma ii-IDM musí umožňovat vytvoření a pokročilou správu emailových adres (aliasů) v prostředí systému řízení směrování emailů na platformě Sendmail . Algoritmus tvorby poštovních aliasů určí zadavatel. Součástí tohoto řešení musí být evidence již použitých emailových adres, generování alternativních emailových adres a uvolňování dlouhodobě nepoužívaných emailových adres a notifikační služby v případech, kdy algoritmus nedokáže emailovou adresu stanovit. MS Exchang e -IDM musí umožňovat správu emailové schránky na serveru MS Exchange , zejména musí umožnit vytvoření schránky , zrušení schránky a zneplatnění schránky. Office 365- Emailové schránky studentů UP jsou umístěny v cloudovém prostředí Office 365. lOM musí umožňovat nastavování atributů v AD, které následně umožní automaticky spouštěným skriptům identifikaci těch emailových schránek, které mají být přeneseny do prostředí MS Exchange do Office 365 (v případě studentů) nebo z do Office 365 do MS Exchange (v případě studentů, kteří se stanou zaměstnanci) . ERP SAP -lOM musí umožňovat zápis vybraných údajů zpět do ERP SAP ( např. generuid , email uživatele). IS/STAG - IDM musí umožňovat zápis vybraných údajů zpět do IS/STAG ( např. generuid , email uživatele). Shibbole th - lOM musí spravovat identity a oprávnění pro SSO systém Shibboleth. FreeRad ius - lOM musí spravovat identity a oprávnění pro systém FreeRadius. ShareP oint- IDM musí spravovat identity a oprávnění v platformě SharePoint. IDM musí dále do workflow na SharePoint předávat informace o nadřízenosti a podřízenosti daných zaměstnanců a informace o organ izační struktuře UP a kontaktní údaje o zaměstnancích .
Strana 9
Univerzita Palackého v Olomouci
o o
AUTOCONT
DYNAS - IDM musí zajišťovat zápis delegování uživatelských oprávnem pro schvalovací workflow do databáze Dynamického nákupního systému UP. Cestovní příkazy - IDM musí zajišťovat zápis delegování uživatelských oprávnění pro schvalovací workflow do databáze aplikace Cestovní příkazy .
IDM musí umožňovat zadavateli přístup ke zdrojovým kódům programových komponent obsahujícím logiku konektorů na zdrojové a spravované systémy. Po skončení záruční doby musí být zadavateli umožněny úpravy těchto kódů vlastními silami, bez nutnosti spolupráce s dodavatelem a bez dalších licenčních nákladů , a aniž by došlo k porušení licenčních práv. Na základě úprav musí být zadavatel schopen modifikovat funkčnost IDM vzhledem ke zdrojovým a spravovaným systémům tak, aby mohl pružně reagovat na změny ve zdrojových a spravovaných systémech a na změny požadavků vyplývajících z vnitřních pravidel zadavatele. Zejména musí být zadavateli umožněno vlastními silami modifikovat algoritmy tvorby generuid, tvorby emailových aliasů a dalších komponent, u kterých se předpokládá , že budou předmětem častějších změn. Tyto komponenty budou nadefinovány ve fázi předimplementační analýzy.
Požadavky na webové rozhran í
IDM musí obsahovat webové rozhraní pro přístup jak běžných uživatelů, tak systému pro správu a výkon jednotlivých integračních a provozních úloh. Webové rozhraní musí podporovat minimálně internetové prohlížeče Chrome, Firefox a Internet Explorer. Webové rozhraní pro běžné uživatele musí být odděleno od webového rozhraní pro administrátory systému. Webové rozhraní musí běžnému uživateli dovolit měnit některé údaje o své identitě. Zejména musí mít běžný uživatel prostřednictvím webového rozhraní možnost: o změnit si heslo, o vložit do systému průkazovou fotografii, o nastavit informaci o své nepřítomnosti , o nastavit delegaci svých vybraných uživatelských oprávnění na další osoby, a to pro každou roli zvlášť. Webové rozhraní musí umožnit uživatelům na vysokoškolských kolejích zadat až tři MAC adresy počítačů , ze kterých chtějí přistupovat na kolejích k internetu z pevné sítě. Tato informace musí být přenesena do adresáře LDAP. Všechny části řešení , které budou samoobslužně využívat běžní uživatelé, musí být plně lokalizovány do českého a anglického jazyka s možností přepínání mezi jazyky. U ostatních částí řešení zadavatel připouští i možnost jen českého jazyka nebo jen anglického jazyka. Všechny části řešení, které budou samoobslužně využívat běžní uživatelé, musí respektovat jednotný vizuální styl zadavatele (http://vizua .upol.cz/), zejména pak musí obsahovat horní a spodní pruh ve stanovených barvách a logo UP. To neplatí pro části webového rozhraní sloužících k administraci IDM, správě identit, správě číselníků atp. Přístup uživatelů k datům IDM musí být zajištěn prostřednictvím tohoto webového rozhraní. Řešení musí umožňovat zobrazení přidělených rolí k jednotlivým identitám s rozdělením na role navázané na systemizované místo, na role navázané na identitu, role navázané na organizační jednotku, role navázané na skupinu a na role přidělované pro jednotlivé případy. U identity musí být evidován souhrn všech rolí včetně informace o tom, odkud roli zdědil (z organizační jednotky, systematizovaného místa, skupiny) nebo kdo ho rolí pověřil. Musí být možno definovat pravidla pro zamezení konfliktu rolí. Webové rozhraní musí umožnit exportovat a publikovat informace k identitě uložené v IDM a to i historické. administrátorů
Strana 10
Univerzita Palackého v Olomouci
AUTOCONT
Webové rozhraní musí umožňovat správu identit uživatelů a jejich případnou úpravu, založeni, zneplatnění nebo smazáni. Webové rozhraní musí umožnit grafické zobrazení identit (uživatelských účtů) v organizační struktuře. V rámci jednoho pohledu musí být možné zobrazit organizační strukturu včetně pracovních pozic organizace až do úrovně jednotlivých uživatel ských účtů (identit).
Požada vky na synchro nizaci
IMD musí umožnit prostřednictvím webového rozhraní spravovat synchronizace včetně nastavení připojení na synchronizované systémy , nastavení plné nebo změnov é synchronizace, počtu změn , které je možné zpracovat, nastavení časového intervalu spouštění a nastavení intervalu odstávky. Synchronizaci musí být možné spouštět ručně i automaticky. Zadavatel požaduje možnost spouštět synchronizace i v simulačním režimu , tak, aby bylo možné si ověřit stav dopadu reálného spuštění předem. Simulační logy musí být k dispozici prostřednictvím webového rozhraní lOM. IDM musí upozorňovat na chybové stavy synchronizace pomocí mailu na adminis trátory lOM a zapisovat je do logu lOM přístupného z webového rozhraní. Webové rozhraní musí umožnit sledovat administrátorovi jednotl ivé stavy v průběhu synchronizace v grafické podobě. Požada vky na notifika ce
lOM musí umožnit notifikovat emailovou zprávou vytvoření a změny identity. IDM musí umožnit notifikovat emailovou zprávou vytvoření a změny referenčních objektů jako systematizované místo, organizační jednotka , skupina atd. Mechanismus správy notifikací včetně náhledu na odeslané notifikace musí být součástí webového rozhraní IDM. V šabloně notifikace musí být možné definovat příjemce , předmět a obsah dané notifikace. U notifikací vázané k identitám musí být dále možné nastavovat pro odesílán í notifikací samostatné příjemce pro různé části organizační struktury zadavatele (fakulty, katedry, univerzitní zařízení). lOM musí podporovat notifikační šablony a notifikace uživatelům pro upozorn ění na vypršení hesla a vypršení platnosti certifikátů. Notifikaci musí být možné nastavit na několik dní dopředu před vlastním vypršením hesla nebo certifiká tu. Notifikace musí být možné aktivovat nebo deaktivovat pro jednotlivé zdrojové systémy , které v lOM změnu identity nebo referenčního objektu provedly (ERP SAP, 18/STAG , webové rozhraní lOM). IDM musí umožnit zaslání notifikace pro překročení limitu počtu provedených změn. lOM musí umožnit zaslání notifikace při detekci problému při generování emailové adresy. Požada vky na auditní reporty
IDM musí umožňovat generování alespoň následujících auditních reportů: report přehledu uživatele/uživatelů a jejich rolí v systémech spravovaných IDM ve vybraném časovém okamžiku, report historie delegování práv uživatele/uživatelů v definovaném časovém období, možnost vytváření reportů z šablon nebo vlastních reportů,
Strana ll
Univerzita Palackého v Olomouci
AUTOCONT
IDM musí dále umožnit generování auditních reportů ve strojově čite lném formátu (např. v XML) , které musí obsahovat veškeré informace o daném uživateli a jeho rolích v informačních systémech zadavatele spravovaných na IDM ve vybraném časovém okamžiku.
Požadavky na webové služby IDM musí poskytovat rozhraní webových služeb pro programové napojení dalších systémů zadavatele v roli klientů IDM. Základní konfigurace přístupu k webovým službám musí být dostupná z webového rozhraní IDM. Rozhraní musí poskytovat minimálně následující služby: o získání organizační struktury, o získání hierarchie systematizovaných míst, o získání seznamu identit, o získání nadřízené osoby pro daného zaměstnance včetně delegované osoby, o získání seznamu rolí pro daného zaměstnance , včetně případné informaci o delegaci role, o zápis seznamu rolí uživatele do IDM, o zápis certifi kátů do IDM.
Technické požadavky na provoz
IDM musí být možné nativně provozovat na níže uvedeném technickém vybavení zadavatele: o prostřed í virtuálních serverů Hyper-V, o operační systém Linux nebo Windows, o databáze Oracle, v případě že bude systém vyžadovat jinou databázi než Oracle, musí být perpetuální licence této databáze součástí nabídkové ceny. Sou čá stí zakázky není dodávka HW vybaven í.
Požadavky na jednotlivé fáze díla: 1.
Předimplementační
analýza
Předimplementační
analýza musí obsahovat minimálně: model struktury organizace, technologický pop is stávajících technologií, ana lýzu procesů a systémů organizace se zaměřením na oblast správy uživatelských účtl\ přidělován í oprávnění a rolí, popis životního cyklu identity u ži vatelů, popis algoritmu přidělování emailových aliasů, popis pravidel uživatelských hesel, popis zdrojových a spravovaných systém ů s ohledem na j ejich připravenost pro nasazení lOM, popis atri butů dodávaných zdrojovým i systémy v souladu s potřebami spravovaných systémů.
V předimplementační analýze musí být dále zahrnuto budoucí připojení minimálně těchto systémů; analýza popíše a stanoví potřebné podmínky pro jejich budoucí napojení: Identifikační karty včetně navazuj ících systémů SmartQ, vstupního systému CEV.IS, ubytovacího systému ISKAM, stravovacího systému KREDIT, Centrální evidence smluv Marbes,
Strana 12
Univerzita Palackého v Olomoucí
AUTOCONT
E lektronická spisová služba Magion. Předimplementační
analýzu je dodavatel povinen dodat v písemné podobě. Před jejím předáním je dodavatel povinen podrobit ji připomínkovém u řízení ze strany zadavate le, připomín ky vzešlé z tohoto řízení do výstupu zapracov at a zohledni t v rámci druhé fáze prováděn í díla. O odsouhla sení, předání a převzetí předimplementač ní analýzy bude vyhotoven písemný protokol .
2. Implementační projekt Implementační
projekt musí obsahovat minimálně: manažerský souhrn, detai lní popis řešení, harmono gram implementace řešení a realizace celého projektu, požadavky na souči nnost zadavatele, návrh akceptačních testů a akceptačního protokolu, přiřazen í činností k pracovním pozicím v organizační struktuře , návrh metod iky pro správu identit a j ej ich oprávnění, návrh harmonogramu nasazování systému a zkušebního provozu.
Implementační
projekt je dodavatel povinen dodat v písemné podobě. Před jeho předáním je dodavate l povinen podrobit jej připomínkovému řízení ze strany zadavatele, připom ínky vzešlé z tohoto řízení do výstupu zapracovat a zohledn it v rámci třetí fáze provádění díla. O odsouhla sení, předání a převzetí implementačního projektu bude vyhotoven písemný protokol.
3. rnstalace a implementace insta laci a implementaci je dodavate l povinen provádět v souladu se schválen ým i mp lementačním projektem. V této etapě dodavate l provede instalaci systému a jeho kompletní impleme ntaci včetně potřebných doplnění, specifick ých úprav a nastaven í, naplní systém uživatelskými daty a uvede do zkušebního provozu. O ukončení instalace a implementace a předání díla do zkušební ho provozu bude vyhotoven písemný protokol. Nebude-li
předávané
dílo prosto vad či nedodělkll, objednatel uvede zjištěné vady či nedodělky do protokolu a zároveň stanov í dodavateli lhůtu k jejich odstraně ní. Předání části díla s vadami či nedoděl ky není sp lněním dodavate lova závazku, pokud objednat el v protokolu neuvede, že plnění s vytknutými vadami a nedodělky přebírá. předávacího
4. Zkušební provoz, dokume ntace a zaškole ní čtvrtá fáze díla (zkušební provoz, dokumentace, zaškolení obsluhy a úspěšné provedení
akceptačních testů)
bude zahájena po protokolárním předání a převzetí díla v rozsahu první až fáze vč. ukončené implementace. Dodání dokumentace a zaškolení uživatel ů bude provedeno nejpozději do 3 měsíců od zahájení čtvrté fáze díla. Zkušební provoz potrvá po dobu 3 měsíců. Pokud dojde v průběhu zkušebního provozu k závadám, doba zkušebn ího provozu se prodlužuje o stejnou dobu, po kterou nebyly informační systémy prokazate l ně plně funkčn í. čtvrtá fáze díla bude ukončena akceptačními testy, protokolárním ukončením zkušebn ího provozu a předáním jednotlivých informačních systémů do běžného provozu . třetí
Zkušebním provozem se rozum í doba určená k ověření požadovaných funkcí jednotlivých informačn ích systémů. Doba zkušebn ího provozu začíná běžet dnem protokolárního ukončení instalace a implementace díla. Délka trvání zkušebního provozu bude 3 měsíce. Pokud dojde v
Strana 13
Univerzita Palackého
AUTOCONT
v Olomouci
průběhu zkušebního provozu k závadám , doba zkušebního provozu se prodlužuje o stejnou dobu, po kterou nebyly informační systémy prokazatelně plně funkční. Zkušební provoz bude ukončen akceptačními testy, protokolárním ukončením zkušebního provozu a předáním jednotlivých informačních systémů do běžného provozu.
Dokumentace Zadavatel požaduje vytvoření a předání kompletní technické a uživatelské dokumentace v elektronické podobě v českém jazyce. Dokumentace musí jednoznačně a detailně popisovat celé implementované řešení včetně popisu všech rozhraní a umožnit uživatelům na všech úrovních bezproblémovou orientaci v implementovaném prostředí. Technická dokumentace bude mimo jiné obsahovat i popis procesu zálohování a obnovy, monitoringu a procedur bezpečného vypnutí a spouštění systému. Dokumentace musí dále obsahovat technický návod na připojení dalšího spravovaného systému vlastními silami.
Zaškolení obsluhy předmětu plnění a v rámci celkové nabídkové ceny bude administrátorů systému a vybraných uživatelů zadavatele (max. 5 osob) v
V rámci
provedeno školení rozsahu minimálně
dvou školících dní (8 vyučovacích hodin/den). Dále bude provedeno školení programátorů zadavatele, zaměřené na možnosti rozvoje systému vlastními silami (max. 3 osoby) v rozsahu minimálně dvou školících dní (8 vyučovacích hodin/den). Veškerá školení proběhnou v místě plnění , pokud nebude dohodnuto písemně jinak osobami oprávněnými jednat ve věcech technických za smluvní strany. Přesný termín školení musí být v dostatečném časovém předstihu odsouhlasen osobou oprávněnou jednat za objednatele ve věcech technických . Veškeré náklady spojené s výše uvedenými školeními (vč. pobytu servisních techniků , aplikačních specialistů , popř. specialistů dodavatelů příslušenství) hradí zhotovitel. Akceptační
testy
Předání a převzetí díla bude provedeno na základě protokolu o provedených akceptačních testech. Ukončení akceptačních testů budu stvrzeno podepsáním akceptačního protokolu po ukončení zkušebního provozu. Návrh akceptačních kritérií a obsah a forma akceptačního protokolu bude součástí implementačního projektu a podléhá schválení zadavatelem. Součástí akceptačních testů musí být minimálně: ověření funkčnosti řešení v plném rozsahu technické specifikace, ověření funkčního řešení v rámci zkušebního provozu, úplná technická a už ivatelská dokumentace implementovaného řešení včetně popisu rozhraní pro jednotlivé připojené systémy.
Technická podpora po dobu
záruční
doby
Zadavatel požaduje v rámci celkové nabídkové ceny poskytnutí technické podpory v průběhu trvání záruční doby a to v rozsahu min. 1O hodin měsíčně s tím, že nevyužité hodiny podpory v jednom měsíci se převádí do měsíců následujících. Technická podpora bude zahrnovat: Konzu ltace a další práce dodavatele na nastavení, provozu a
případném rozš iřování
lOM.
Strana 14
AUTOCONT
Un iverzita Palackého v Olomouci
tele za účel em Poskytování hot-line formou telefonické podpory pro oprávně né osoby objedna Služba hot-line bude poraden ství a konzultací pro řešeni technick ých a provozních problémů. poskyto vána v pracovn í dny v době 8:00- J6:00. jeho už ívání v rámci Profylaktické služby pro zajištění řádného fungování systému po celou dobu zpráva o výsledku á souhrnn technické podpory . Výstupe m profylaktických aktivit bude aktivity : měsíční jednotli vých kontrol. Profylaktické č innosti zahrnují následuj ící pravide lné o kontrola logů systému IDM, o Kontrola logů jednotli vých synchronizací, o Kontrola stavu databáze IDM, o kontrola stavu velikosti místa na disku serveru IDM. í požadavků na Poskyto vání služby HelpDe sk pro oprávně né osoby objedna tele pro zadáván konzultační s lužby a na hlášení vad systému . Odstraňování vad Součástí cenové nabídky
Pro
bude služba pro odstraňování vad v rámci Vady budou hlášeny prostřednictvím s lužby HelpDe sk Vady budou odstrar1 ovány v pracovn í dny v d obě 8:00 - 16:00.
záruční
doby 24
vad zadavatel vyžaduje dodržení následující
reakční
doby:
účely odstraňování
Kategorie vady Vysoká Střední
Nízká
Reakční
doba 1 pracovní den 3 pracovní dny 5 pracovních dnů
měsíců .
Doba realizace nápravy 3 pracovní dny 15 pracovních dn ů 60 pracovních dnů
tel prověří doba je definována jako časový interval, po který se očekává , že dodava nahlášenou vadu a navrhne vhodný způsob nápravy a protiopatřen í. vady do jejího úplného Doba realizace nápravy je definována jako časový interval od nahlášení Reakční
odstranění.
Specifikace kategorií vad : použitelný ve svých Kategorie vady "vysoká", ti- vady zabra r1uj ící provozu - systém není systému . Tento stav innost základn ích funkc ích nebo se vyskytuje funkční závada znemož ňující č opatřen ím. ml'1že ohrozit běžný provoz zadavat ele a nelze j ej dočasně řešit organizačním j e ve svých funkcích Katego rie vady "střední", tj. vady omezuj ící provoz - fu n kčnost systému o vady způsobuj ící degrado vána tak, že tento stav omezuj e běžný provoz zadavat ele. Jedná se také provoz, j im iž ující 1 ' umož1 ale , části eho j problém y při užívání a provozován í systému nebo zpl'1sobené problémy lze dočasně řeš it organi začními opatřen ími. které nespadaj í do Kategor ie vady "nízká", tj . vady neomezuj ící provoz - znamen á drobné vady, kategorií "vysoká " nebo "střední". Zařazení
vady do jednotlivých kategorií určuje zadavatel.
Strana 15
;
lJn"tverzita Palackého v Olomouci
Příloha č. Uchazeč
AUTOCONT
2 - Nabídka Zhotovitele
v rámci této
přílohy předkládá
nabídku Zhotovitele.
Strana 16
AUTOCONT
ls. PODROBNÁ KALKULACE A SPECIFIKACE PŘEDMĚTU PLNĚNÍ 5.1. KALKULACE PŘEDMĚTU PLNĚNÍ ~ r~:~-o~~ --.rr~ "t,.;:;-~~;;:-~ Cena v Kč bez DPH_--: 'r;l_l?~"!_v K -~~.,--:~-:---:::- ~-'t5~-~ j~~t'---""''"·· _,,_.__::;:._
.
. P~!ožka_ p!~.~ní ~ .:; . ;·~ ·č::- .::~ ·:.!1 Předimplementační analýza I mplementační proj ekt
Instalace a impl eme ntace zaškolen í Zkuš ební prov oz, doku men tace a í lhůty (24 měsíců) Tech nick á podp ora po dobu zá ručn ční lhůty (24 měs íců) Odstraňo ván í vad po dobu záru Licence IDM Celk ová cena předmětu plnění
i
86 515 Kč
715 00 Kč
15 015 K č
715 00 Kč
15 015 Kč
86 515 Kč
591 500 Kč
124 215 Kč
715 715 Kč
91 000 Kč
191 10 Kč
110 110 Kč
58 500 Kč
12 285 Kč
70 785 Kč
58 500 Kč
12 285 K č
70 785 Kč
50 000 Kč
10 500 Kč
60 500 Kč
992 500 Kč
208 425 Kč
120 0 925 Kč
ĚNÍ 5.2. SPECIFIKACE NABÍZENÉHO PLN uje Seznam významných zaká zek) a splň át imp lem ento van é (např. viz. likr něko ené, ověř je Naše veškeré požadavky Zadavatele. prod uktu AC Iden tita. t CZ a.s. je realizováno implementací IDM řešení od spol ečnosti AutoCon t), jehož cílem je evidovat a IDM (Ide ntity and Access Managemen typu ém syst ační rm info je tita Iden AC aných pro třetí strany. atele informa čních systémů provozov řídit uživat ele organizace i uživ řeše ní
5.2.1. ARCHITEKTURA ŘEŠENÍ Sou čá stí řešení
race pro servery AC ího pros třed í. Vhodná kon figu bude příprava testovacího a produkčn
Iden tita je:
SERVERY TESTOVACÍ PROSTŘED Í
R2 Std CZ 1 Gbi t 2 jádra 4GB 50G B WinSrv 2012 idla Prav lAM er Serv T-lAM-BR Srv 2012 R2 Std CZ 1 Gbit uživ atele 1 j ádro · 4GB 50G B Win · T-IAM-EXT lAM serv er pro externí
SERVERY PRODUKČNÍ PROSTŘ E DÍ R2 Std CZ 1 Gbit 2 jádra 4GB 1 50G B WinSrv 2012 IAM -APP Řídi cí server lAM R2 Std CZ 1 Gbit 2 jádra 4GB 50G B WinSrv 2012 lAM-BR Server lAM - Pravidla 2 R2 Std CZ 1 Gbit e 1 jádr o 4GB 50GB ,I WinS rv 201 atel uživ rní exte pro er serv lAM IAM -EXT vány na plat form ě Hyper-V . Uve dené se rvery moh ou být virtu alizo prov oz test ovacího a server Microso ft SQL Serv er. Pro vý bázo data n žívá vyu e j dat Pro persist enci xpress. e edice Microso ft SQL Se rver E p rodukč ního pros tředí dost ačuj HW vybave ní. So u část í zakázky není dod ávka
AUTOCONT 5.2.2. AC IDENTITA Systém IDM AC Identi ta od společnosti AutoCont CZ a.s. naplňuje veškeré pořadavky ze zadávací dokumentace. Systém IDM integruje identi ty v rámci vyjme novaných služeb organizace. Pro integraci uživatelů v rámci organizace je umožněno vytvoř ení jedno tné centrální evidence uživatelských účtů a oprávnění uživatelů k integrovaným aplikacím. Sjedno cujícím prvkem je systém IDM. Ze zdrojových systémů vstupují do IDM údaje o osobách, uživatelských účtech , zařazení v organizační struktuře, přiřazení pracovního místa, přiřazení do skupin atd. V rámci IDM jsou uživatelům přidělena oprávnění pro různé systémy formo u přiřazení rolí pro jedno tlivé integrované systémy. IDM umožňuje jednoduše a přehle dně spravovat číselník aplikací a aplikačních rolí těchto aplikací. Tyto aplikační role je možné přiřadit na organizační jednot ky, pracov ní místa, skupiny a vybrané uživatelské účty evidované v systému IDM. Do cílových systémů může IDM předávat kompl etní data o uživatelích včetně informace o oprávněn í ke konkré tní aplikaci, která jsou reprezentována přidělenými rolemi příslušné aplikace. IDM bude umožňovat napojení na následující systémy:
•
• • •
•
•
• •
•
•
•
• •
ERP SAP IS/STAG Data báze externistů LDAP server MS Active Directory Sendmail MS Exchange Office 365 Shibboleth FreeRadius SharePoint Dynas Cestovní příkazy
Přesný rozsah napojení IDM na jedno tlivé systém y organizace bude stanoven v rámci analytické fáze projek
tu.
SYNCHRONIZACE IDEN TIT Zdrojem identi t pro IDM jsou definované systémy, které obsahují základní informace o identitách (například Personální systém, LDAP server). Aktuální stav identi t je udržován v IDM a je výchoz ím zdrojem pro ostatní integrované systémy. IDM perzistuje svá vnitřní data do databázového systému MSSQL. Pro autom aticko u aktualizaci osobních údajů i údajů o identit ách (uživatelských účtech) jsou využita data v některém z integrovaných systémů. Typicky primárním zdrojem pro identi ty organizace je personální systém, kde jsou evidována data o zaměstnancích organi zace. Dále mohou být definovány případné další zdrojové systém y jako například LDAP server (Active Directory). UŽIVA TEL SKÉ ROLE SYSTÉMU IDM
Nabídka na ,.Implementace systému identity management/20 15"
/
·AUTOCONT Pro zajištění funkcionality systému IDM definujeme aktéry, kteří vykonávají nebo využívají jednotlivé funkce systému IDM. Jedná se o uživatelské role informačního systému IDM: Uživateli DM Uživatel, který je evidován v systému lOM a může zadávat změny svých údajů (změna hesla) Administrátor číselníků organizace Uživatel s oprávněním spravovat číse lníky systému IDM pro přidělenou organizaci nebo organizačn í jednotky. Jedná se o číselníky:
• •
Organizační
struktura organizace (pouze část číselníku pro přidělenou organizaci) Pracovní místa (pouze část číselníku pro přidělenou organizaci)
Administrátor číselníků IDM Uživatel s oprávněním spravovat čísel níky systému IDM, který spravuje číse ln íky pro všechny organizace :
• • • • • • • • • • • • •
Domény Aplikace Role aplikací Agendy (včetně agendových rolí) Typy kontaktů Uživatelské skupiny Organizační struktura (organizací a organizačních jednotek externích subjektů) .
Pracovní místa Typy adres Typy dokladů Typy kontaktních údajů Typy organizačních jednotek Země
Administrátor organizace Administr átor organizace má oprávnění spravovat uživatele přidělené orga nizace nebo organizačn í jednotky. Může provádět změny uživatele, změnu hesla, přidávat nového uživatele. Administrátor IDM Administr átor IDM má oprávnění spravovat veškeré identity evidované v IDM. Může provádět změny identity, změnu hesla, přidávat nového uživatele, přidělovat role uživatelům, skupinám, pracovním místům nebo o rgan izačním jednotkám . Dále může spravovat konfiguraci IDM nastaven í konektorů na jednotlivé systémy a režimy synchronizace změnová, plná, pravide lná, ručn í, simulace atd . Administrátor pro přiřazení aplikačních rolí
Spravuje přiřazení aplikačních rolí a jejich specifikací na pracovní místa, uživatele v rámci své organizace nebo organizační jednotky.
ZÁKLADN Í FUNKCIO NALITA SYSTÉMU IDM Správa číselníků Uživatel (uživatelé) IDM v roli Správce číse lníků případně Správce číselníků organizace udržují aktuální stav číse lníků nezbytných pro správné fungování systému IDM prostřednictvím uživate lského ro zhraní. Změny některých číse lníků vychá zejí ze synchroni zací se zdrojovým systémem (organ izační struktura, pracovní místa).
Nabídka na . Implementace systému identity management/201S"
AUTOCONT Správa iden tit celý životní cyklus iden tity webového rozhraní IDM spravuje Adm inis tráto r IDM prostřednictvím lušné informační systémy. Dále uživatelů, přiděluje role pro přís in skup do zuje Zařa . IDM v né má evidova chod IDM. Adm inis tráto r organizace ačních parametrů pro správný zabezpečuje nastavení konfigur přidělené organizace. oprávnění spravovat iden tity Správa nastavení lOM . telná přes administrátorské rozhraní Konfigurace systému IDM je spravova . Dále je možné t emailové notifikace a jejich definice vova spra né mož je IDM race figu kon Vedle systémové systémy, režimy syn chro niza ceavení připojení na synchronizované spravovat synchronizace včetně nast atd. , ruční, simulace, omezení spuštění, plná, změnový, pravidelná automatická externího rozhraní webových služeb IDM je možné spravovat přístupy do Přes administrátorské rozhraní IDM. reporty k aktuálnímu stavu iden tit ím rozhraní rovněž generovat račn nist admi v e můž IDM r Adm inis tráto orty je možné vytvářet i do minulosti. zejména s ohledem na oprávnění. Rep webové v této kapitole jsou realizovatelné ve Jednotlivé uživatelské akce popsané
m portálu systému IDM.
IDM DAT A SPR AVO VAN Á SYSTÉMEM titul y, atd. je o osobě- jméno, příjmení případně • Oso ba- základní identifikační úda Doručovací, Pracovi ště (je ny adresy typů: Trvalá, Přechodná, ová evid mít e můž a osob sa Adre • možné tent o výčet rozšířit). fon zaměstnání, Mob ilní é kontakty různých typů např. Tele • Kontaktní údaje osoby - libovoln ů. novat libovolné typy kontaktních údaj tele fon, atd. Administ ráto r může defi osoba může mít v rámci jedn é e uživatelských účtů- iden tit. Jedna enc evid jící odu rozh je IDM ém syst Pro ských účtů s různými právy. organizace zaevidováno více uživatel Iden tita - uživatelský účet t hesla, e-mailová énou. Další údaje jsou heslo, platnos dom a in) (log nem jmé m vací lašo Je určena přih i údaji daného uživatele. Identita je rovněž provázána s osobním adresa, informace o platnosti účtu. é kmenové organizační jednotce . • Každá iden tita je zařazena v jedn dočasné pověření - i více í místo (ve výjimečných případechovn prac o azen přiř mít e můž tita • Iden zeno žádné pracovní h uživatelů nemusí mít identita přiřa pracovních míst). V případě externíc místo. heslo v IDM, je šifrováno. • Pokud je pro iden titu evidováno (Security, Distribution, Bez volném počtu uživatelských skupin • Identita může být zařazena v libo Sec urity) ny uživatelské certifikáty • Pro uživatele mohou být evidová tupu a činnostem v jednotlivých y role, opravňující uživatele k přís azen přiř jsou ě) ntit (ide i atel • Uživ děním" z organizační ch. Uživatel může získat role "zdě integrovaných informačních systéme jednotky, pracovního místa či skupiny tního algoritmu pro sy je podporována implementace vlas Pro generování loginu a emailové adre • generování. ČÍSELNÍKY SYSTÉMU IDM některé jsou aktu alizo vány é spravovat řadu číselníků , z nichž nutn je lOM vání ozo prov vné sprá Pro í se zdrojovým systémem alizovány automat icky - synchron izac aktu jsou i část h jejic ě adn příp , icky automat
Nabídka na " Implementace syst ému
identity manageme nt/2015"
"
AUTOCONT struktury a část pracovních míst organizace jsou aktualizovány synchronizací ersonálním systémem) . Jiné číselníky jsou spravovány administrátorem IDM.
1př. část organizační
pro jednotlivé Organizační struktura - číselník hierarchického uspořádání organizačních jednotek
•
organizace, jejichž uživatelé přistupují k některým informačním systémům v prostředí KÚ. Jednotlivým organizačním jednotkám je možné přiřadit role, představující souhrn oprávnění k určitému informačnímu systému. Role přiřazené organizační jednotce jsou automaticky přiřazeny uživatelům zařazeným v příslušné organizační jednotce. je Pracovní místo - číselník pracovních míst v rámci jednotlivých organizací. Pracovní místo jednotce í organizačn definováno pro určitou organizaci evidovanou v IDM, může být přiřazeno souhrn oprávnění příslušné organizace . Pracovnímu místu je možné přiřadit role, představující ky přiřazeny automatic jsou místu u pracovním k určitému informačnímu systému. Role přiřazené
•
uživateli zařazenému na příslušné pracovní místo. Doména - Logické uskupení informací vztahující se nějakému celku, například sdílející společnou jedinečné adresářovou strukturu. (Například doména AD) Uživatel má v rámci domény přihlašovací jméno -login . Aplikace -Informační systém integrovaný v rámci IDM. Role - pojmenovaný souhrn oprávnění k určitému integrovanému informačnímu systému ího informačn o příslušnéh rámci v a definován aplikaci. Oprávnění, která vyplývají z role, jsou
•
• •
•
• • •
systému. Skupina uživatelů - seskupuje uživatele podle určitých kritérií. Skupině uživatelů mohou být . Role při řazené přiřazeny role, představující souhrn oprávnění k určitému informačnímu systému skupiny. skupině uživatelů jsou automatic ky přiřazeny uživateli zařazenému do určité osoby, které mohou údajů h kontaktníc typy Typy kontaktů - administr átor IDM definuje libovolné být pro osobu evidovanou v IDM zaznamenány. Typy adres- administr átor IDM definuje libovolné typy adresních údajů osoby, které mohou být pro osobu evidovanou v IDM zaznamenány. Agendy a činností role
UŽIVATELSKÉ A TRl BUTY . IDM podporuje evidenci vlastních atributů. Tyto atributy je možné přiřazovat k identitám i k číselníkům evidence účely pro jsou IDM V . DM I Tyto atributy slouží k rozšíření základního datového modelu systému základní dat a vazeb v kapitolách Data spravovaná systémem IDM, Číselníky systému IDM, využity z důvodu struktury datového modelu IDM tedy bez potřeby použít uživatelské atributy. To je zejména činnosti u IDM systému podpory intuitivní orientace v těchto položkách na webovém portálu administrátorů i koncových uživatelů systému IDM.
MANAGE MENT ZMĚN é typy Systém IDM nabízí pokročilý mechanismus managementu správy změn. IDM detekuje definovan změny v systému změn a na jednotlivé typy změn identit umožňuje navázat odpovídající pravidla . Veškeré ých událostí na definovan výskyty IDM jsou zaznamenány do auditního logu. IDM podporuje alertovat případy které jsou posílány emailové notifikace . IDM podporuje zabránění hromadným změnám pro například chybného nastavení synchronizace. EMAILOV É NOTIFIKA CE které je Systém IDM nabízí notifikační modul. Při správě identit v systému IDM nastává řada situací, na dat, úpravou torem, potřeba následně reagovat manuálně, ať již vyřešením chybného chování administrá
Nabídka na " Implementace systému identity management/2015"
AUTOCONT případně změnou hesla uživatele před vypršením platnosti. Pro různé definované události je možné
nastavit vlastnosti zpráv, které se odesílají na definované e-mailové adresy podle nastavených atributů. INTEGRACE S LOAP (ACTIVE OIRECTORY) LDAP server využívá systém lOM pro své inicializa ční naplnění. Po inicializaci je tento systém z pohledu integrace s IDM cílový. Tzn. data jsou propagována z lOM do LDAP . V rámci inicializační fáze jsou do lOM přenesena data k organizační struktuře včetně vazeb, hierarchie a začleněných účtech. Dále pak data ke skupinám (Security group a distribution group) včetně začleněných účtů. Následná pravidelná synchronizace z lOM do LOAP umožňuje synchronizaci jiné množiny dat než bylo předmětem iniciačního naplnění. Organizace a jejich organizační strukturu je možné synchronizovat do oddělených LDAP serverů. Stejně tak je možné přímočaře synchronizovat více organizací do jednoho LOAP serveru UNIVERZÁLN Í ROZHRANÍ WEBOVÝCH SLUŽEB lOM poskytuje sadu webových služeb pro integraci s dalšími systémy. Rozhraní poskytuje metody pro načtení organizační struktury z IDM včetně pracovních pozic a osob. Dále pak na čtení uživateslkých skupin a jejich příslušníků, nadřízeného pracovníka, historii identity, seznamu aplikací evidovaných v lOM atd. Přes rozhraní je možné do lOM propisovat seznamy aplikačních rolí pro jednotlivé aplikace a informace o veřejných certifikátech. 5.2.3. LICENČNÍ MODEL ŘEŠENÍ
Licence lOM řešení AC Identita od společnosti AutoCont CZ a.s. pokrývá požadavky ze zadávácí dokumentace. Jedná o multilicenci bez omezení na počet u živatelů a bez omezení na počet připojovaných systémů do systému AC Identita. Licenční model zároveň umo žň uje přístup ke zdrojovým kódům v požadovaném rozsa hu .
Nabídka na ",mplementace syst ému identity management/2015"
