We use cookies on our site to analyze traffic, enhance your experience, and provide you with tailored content.

For more information visit our privacy policy.

Autentizace Vzorová ustanovení

Autentizace. Podává-li Investor Platební příkaz, musí tak být učiněno za využití Autentizačních prvků a řádné identifikace jednající osoby.
Autentizace. Systém musí být kompatibilní s dodanými technologiemi a podporovat několik druhů autentizace uživatelů popsaných níže. Zároveň musí umožňovat zavedení second faktor authentication (2FA) a vše s podporou výrobce alespoň 2 roky.
Autentizace. Autentizace je vyžadována při komunikaci Klienta se společností Citfin při: a) přihlášení do aplikace BankServis za účelem provádění Platebních transakcí nebo Spotových obchodů; b) při poskytování informací o PÚK Klientovi pracovníkem Citfin; c) využití služby Phonebanking; d) využití Služby Citfin API; e) využití Služby Klientské API.
Autentizace. Radius (EAP TLS, PEAP v 0).
Autentizace. Systém musí umožňovat autentizaci vůči: - Externímu zdroji identit - Internímu zdroji identit Požadavky na autentizaci vůči externímu zdroji identit: Pro autentizaci vůči externímu zdroji identit (Shibboleth) musí být použit zabezpečený protokol (HTTPoverSSL), který splňuje požadavky na kryptografii, které jsou definované dále v této zadávací dokumentaci. Požadavky na autentizaci vůči internímu zdroji identit: Systém musí umožnit nadefinování vlastní heslové politiky pro jednotlivé typy lokálních (záložních) účtů, a to minimálně v tomto rozsahu: - stáří hesla, - granulární komplexita hesla (určení kategorií znaků), - délka hesla, - historie hesla (počet opakování). Uložení hesel v DB musí být v souladu s požadavky na kryptografii, které jsou definované dále v této zadávací dokumentaci. Systém musí umožňovat granulární řízení přístupových oprávnění na základě aplikačních rolí. V případě autentizace vůči externímu zdroji identit musí být přidělování přístupových oprávnění (aplikačních rolí) založeno na uživatelských skupinách. Úrovně všech přístupových oprávnění/jednotlivých rolí musí být detailně popsány (např. formou popisu role v administračním rozhraní a v dokumentaci systému). Aplikační servery/moduly (např. web server, DB server, apod.) nesmí vyžadovat pro své spuštění privilegovaná oprávnění (např. typu root, Administrator, NT Authority\System, sysadmin, apod.). Tato privilegovaná oprávnění nesmějí být vyžadována pro běh zmíněných částí systému v průběhu implementaci či provozu systému.
Autentizace. Systém ICZ DESA je vybaven autentizačními mechanismy, které umožňují správu uživatelů lokálně bez napojení na externí autentizační systémy, ale umožňuje také napojení na adresářové služby Microsoft Active Directory. Uživatele lze organizovat do skupin a lze jim přidělovat role.
Autentizace. Politiky Správa Uživatelská obsluha Podpora identifikačních médií založených kryptografických klíčích (certifikátech) -Smart card, USB token apod. Provedení autentizace uživatele vůči Actlve Directory na koncových zařízeních s OS Windows 8 a vyšší s využitím podporovaných idehtifikačnich médií. Správa a distribuce autentizačních politik-minimálně vynucení autentizace identifikačním mádlem jako je výhradní autentizačni metody, uzamčení pracovní stanice při vyjmuti/odpojení autentizačního média Podpora centrálního vydáváni uživatelských certifikátu a jejich uložení na identifikační média uživatelů např. fT nebo personálním oddělením Podpora prodloužení platnosti certifikátu uživatelem, upozornění na blížící se expiraei, řízení oprávnění k prodloužení. Ano, Smart card, USB token s uloženým certifikátem Ano Ano, využití Group Policy Ano Ano Příloha Popis parametrů prvků nabízeného řešení.docx-Odkaz č. 3 Příloha Popis parametrů prvků nabízeného řešení.docx - Odkaz č. 3 Příloha Popis parametrů prvků nabízeného řešéni.docx - Odkaz č.3 Příloha Popis parametrů prvků nabízeného řešení.docx - Odkaz č.3 Příloha Popis parametrů prvků nabízeného řešení.docx-Odkaz č.3 Příloha Popis parametrů prvků Obnova klíče Obnova primárního klíče „ztraceného" certifikátu Ano nabízeného řešení.docx - Odkaz č.3
Autentizace mobilním telefonem Uživatelský portál Signature provider (QSCD)
Autentizace. Umožnit podporu těchto autentizačních metod: vůči internímu seznamu účtů a hesel vedených v systému SD, vůči Active directory, vůči adresářové službě LDAP, vůči MS Azure Active Directory. vůči externímu autentizačnímu mechanismu (autentizační brána), vícefaktorové ověření Umožnit podporu úrovní přístupu na základě množiny přidělených autorizačních rolí. Možnost stanovení: přístupu konkrétních rolí k hierarchickým sekcím systému SD, uživatelských rozhraní jednotlivým uživatelům (rolím), přístupu rolí k seznamům, k detailům položek seznamů (nabídky, záložky), přístupu rolí k formulářům, položkám formulářů (pole, nabídky, záložky), práv rolí k záznamům (zakládání, archivace, modifikace, pouze pro čtení), omezení přístupu k datům - např. na základě lokality, organizace atp.
Autentizace. Pro autentizaci bude možné využít v oblasti intranetu ověřené jméno uživatele v doméně (NTLM). Pro vnější přístup se předpokládá login form. V průběhu realizace bude upřesněno, zda ověření via login form proběhne proti vlastní membership API, nebo proti Microsoft Active Directory (dále jen AD). Aplikace musí být připravena na ověření uživatele proti dalším zdrojům, především využití tzv. SSO modulu, který zajišťuje ověření proti dalším zdrojům a komunikuje na bázi webových služeb.