SSO s použitím klientských certifikátů

Návrh článku do CAcert Wiki

1. Jednotné přihlášení Single Sign-On (SSO)

SSO umožňuje, aby měl uživatel jediné heslo, kterým se přihlašuje k několika spřaženým webovým portálům a/nebo webovým aplikacím. To je pro uživatele velmi pohodlné, nemusí si pamatovat mnoho hesel. Pokud zde neprobíhá šifrování, má ovšem SSO zásadní nevýhodu. Při prozrazení nebo prolomení hesla je možný přístup útočníka ke všem webům/aplikacím přístupným pod tímto heslem. Tato nevýhoda pro většinu lidí představuje závažný důvod, proč SSO nepoužívat.

Existuje však způsob ověření, kdy portály vznesou dotaz na identitu přihlašované osoby službě speciálního ověřovacího portálu. Tato řešení jsou v ČR známa jako MojeID nebo Bankovní identita. Přihlášení tímto způsobem se považuje za bezpečné, protože zmíněná služba využívá kryptografii, často nepřímo, pomocí speciální aplikace (George klíč České spořitelny nebo RB klíč Raiffeisen banky).

2. Klientské certifikáty

Běžné použití klientského certifikátu je šifrovaná komunikace. Je to buď výměna zpráv elektronické pošty nebo používání webu, webového portálu, popř. webové aplikace protokolem https.

Pro spojení prohlížeče s mnoha typy webových portálů stačí mít kořenový certifikát jejich certifikační autority. Spojení je pak založeno na tom, že jak Váš prohlížeč, tak web důvěřují téže certifikační autoritě. Navíc jsou kořenové certifikáty mnoha certifikačních autorit již v prohlížečích předem instalovány.

Pro přístup klienta (osoby) je obvykle nutné, aby měl vystaven a instalován svůj klientský certifikát. Některý zabezpečovací program v počítači klienta vygeneruje CSR (Certificate Signing Request) s veřejným klíčem a odděleně odpovídající privátní klíč. Uživatel pak CSR odešle k podpisu certifikační autoritě a obdrží svůj certifikát. Privátní klíč přitom zůstává v počítači, kde byl vygenerován, a slouží k dešifrování, popř. zašifrování (podle typu komunikace).

Pro komunikaci s poštovními a webovými (i jinými) servery se používají protokoly SSL (Secure Sockets Layer, 1.0, 2.0, 3.0) a TLS (Transport Layer Security, 1.0, 1.1, 1.2, 1.3). Vzhledem k postupnému zastarávání protokolů a jejich zranitelnostem se nyní doporučuje protokol TLS verzí 1.2 a 1.3.

3. Kombinace SSO a klientských certifikátů

Klientský certifikát může být označen příznakem, že je vhodný k přihlášení SSO. Podle CAcert dokumentu Přehled postupů certifikace (Certificate Practice Statement - CPS, COD6), odst. 3.1.1, je to haš náhodného čísla.

Z dokumentu poskytnutého Oracle dále vyplývá, že u SSO je potřebný Single Sign-On server, který přijímá dotazy „federovaných“ partnerů, k nimž se uživatel-osoba chce přihlásit. Ten vyzvedne z databáze kopii uživatelova certifikátu a porovná ji s žádostí. Je tedy třeba, aby byl certifikát uživatele někde uložen a aby k němu měl SSO server přístup.

Výhody jednotného přihlášení (Single Sign-On, SSO) s využitím certifikátu

(Oracle, https://docs.oracle.com/cd/A97329_03/manage.902/a96115/pki.htm)

Ověřování pomocí certifikátu nabízí výhodu, že partnerské aplikace jsou ve výchozím nastavení povoleny PKI, pokud je povolen PKI na serveru Single Sign-On Server. Stejně jako v případě jednotného přihlášení bez certifikátů se tyto aplikace při ověřování spoléhají na soubory cookie. Načtení a kontrola souboru cookie vyžaduje méně výpočetní režie než SSL handshake. U webových aplikací charakterizovaných krátkodobými relacemi je výsledkem významné zlepšení výkonu a propustnosti serveru.

Možnosti autentizace (ověřování)

Oracle Single Sign-On lze konfigurovat pro SSL s klientskými certifikáty i bez nich. První možnost, ověřování na straně serveru, nabízí vysoký stupeň zabezpečení. Heslo uživatele je přesto zranitelné vůči útoku buď odhady, nebo hrubou silou. Na druhé straně ověřování na základě certifikátu na straně klienta i serveru ztěžuje vypátrání a úpravu dat, nebo zosobnění klienta či serveru.

Tok autentizace při jednotném přihlášení SSO s použitím certifikátu

Schéma 4-1 zobrazuje tok ověřování pro Single Sign-On s certifikátem.

Schéma 4-1 Single Sign-On s certifikátem

  1. Uživatel se pomocí jednotného přihlášení pokusí získat přístup k partnerské aplikaci.
  2. Partnerská aplikace přesměruje uživatele na server Single Sign-On pro ověření. Server musí být konfigurován tak, aby alespoň vyžadoval volitelnou certifikaci klienta.
  3. Pokud byl server nakonfigurován pro SSL, dojde k navázání spojení SSL. Prohlížeč vyzve uživatele k zadání hesla, které otevře certifikát prohlížeče a databázi klíčů. Prohlížeč poté odešle certifikát uživatele na přihlašovací adresu URL serveru Single Sign-On.
  4. Modul SSL (mod_ossl) na serveru Single Sign-On předává informace o certifikátu uživatele modulu PL/SQL, který mapuje přezdívku uživatele a případně jeho jméno předplatitele.
  5. Mapovací modul (mod_ossl) předá mapované uživatelské jméno a volitelné jméno předplatitele autentizačnímu modulu.
  6. Autentizační modul používá mapované uživatelské jméno k načtení uživatelského certifikátu uloženého v adresáři; pak porovná tento certifikát s certifikátem prohlížeče přijatým od modulu SSL.
  7. Pokud se oba certifikáty shodují, server Single Sign-On zaznamená, že autentizace byla úspěšná, předáním tokenu URLC, který obsahuje informace o uživateli do aplikace.
  8. Aplikace přesměruje uživatele na požadovanou adresu URL, která poté doručí obsah.

Single Sign-On Certificate-Authentication

(VMware, https://code.vmware.com/web/workspace-one/core-capabilities/Single-Sign-On-Certificate-Authentication)

Přehled ověření jednotným přihlášením (SSO) s certifikátem - k více aplikacím

Z bezpečnostních důvodů mohou podniky vyžadovat ověřování svých koncových bodů a webů API. Jednotné přihlašování prostřednictvím certifikátů umožňuje vývojářům využít přihlašovací údaje pro zpracování ověřování bez výzvy koncovému uživateli aplikace. Integrované ověřování je funkce SDK, která vývojářům umožňuje dosáhnout jednotného přihlášení pro webové požadavky jejich aplikací. Klientské certifikáty uživatele se automaticky předávají koncovému bodu, který je výzvou k ověření certifikátu. Proto již není nutné, aby vývojář ručně programoval ověřování koncového bodu nebo vyzýval uživatele k zadání pověření (jména a hesla).

Single Sign-On (SSO)

(Wikipedie, https://en.wikipedia.org/wiki/Single_sign-on)

Výhody

Mezi výhody používání jednotného přihlášení patří:

SSO sdílí centralizované ověřovací servery, které všechny ostatní aplikace a systémy používají pro účely ověřování, a kombinuje to s technikami, které zajišťují, že uživatelé nemusí aktivně zadávat své přihlašovací údaje více než jednou.

Nevýhody

Někteří používají termín omezené přihlášení (RSO), aby vyjádřili skutečnost, že jednotné přihlášení je nepraktické při řešení potřeby různých úrovní zabezpečeného přístupu v podniku, a proto může být nutný více než jeden ověřovací server.

Protože jednotné přihlášení poskytuje přístup k mnoha prostředkům, jakmile je uživatel jednou ověřen („klíče k zámku“), zvyšuje negativní dopad v případě, že jsou pověření k dispozici jiným lidem a zneužity. Jednotné přihlášení proto vyžaduje zvýšené zaměření na ochranu pověření uživatele a mělo by být v ideálním případě kombinováno se silnými metodami ověřování, jako jsou čipové karty a jednorázové žetony hesel (jednorázová hesla).

Kvůli jednotnému přihlášení (SSO) jsou systémy ověřování vysoce kritické; ztráta jejich dostupnosti může mít za následek odepření přístupu ke všem systémům sjednoceným v rámci jednotného přihlašování. Jednotné přihlašování lze konfigurovat s možnostmi převzetí služeb při selhání relace, aby byl zachován provoz systému. Riziko selhání systému však může způsobit, že je jednotné přihlášení nežádoucí u systémů, ke kterým musí být vždy zaručen přístup, jako jsou bezpečnostní systémy nebo systémy na úrovni závodu.

Kromě toho může použití technik jednotného přihlášení využívajících služeb sociálních sítí, jako je Facebook, způsobit, že webové stránky třetích stran budou nepoužitelné v knihovnách, školách nebo na pracovištích, která blokují stránky sociálních médií z důvodu produktivity. Může to také způsobit potíže v zemích s aktivním režimem cenzury, jako je Čína a její „projekt Zlatého štítu“, kde web třetí strany nemusí být aktivně cenzurován, ale je účinně blokován, pokud je blokováno sociální přihlášení uživatele.

Bezpečnost

V březnu 2012 zveřejnil Microsoft Research rozsáhlou studii [Rui Wang; Shuo Chen & XiaoFeng Wang. "Signing Me onto Your Accounts through Facebook and Google: a Traffic-Guided Security Study of Commercially Deployed Single-Sign-On Web Services"] o bezpečnosti mechanismů sociálního přihlášení. Autoři zjistili 8 závažných logických nedostatků u vysoce postavených poskytovatelů ID a webů spoléhajících se stran, jako je OpenID (včetně Google ID a PayPal Access), Facebook, Janrain, Freelancer, FarmVille a Sears.com. Protože výzkumníci informovali poskytovatele ID a weby spoléhajících se stran před veřejným oznámením o odhalení nedostatků, byly chyby zabezpečení opraveny a nebyla hlášena žádná narušení bezpečnosti.

V květnu 2014 byla zveřejněna zranitelnost zabezpečení s názvem Covert Redirect. [13] Poprvé to oznámil její objevitel Wang Jing, doktorand matematiky z Nanyang Technological University v Singapuru článkem „Covert Redirect Vulnerability Related to OAuth 2.0 and OpenID“. Ve skutečnosti jsou ovlivněny téměř všechny protokoly jednotného přihlášení. Covert Redirect využívá výhod klientů třetí strany, kteří jsou přístupní XSS nebo Open Redirect.

V prosinci 2020 byly objeveny nedostatky federovaných autentizačních systémů, které využili útočníci během narušení dat federální vlády USA v roce 2020.

Soukromí

Jak bylo původně implementováno v protokolech Kerberos a SAML, jednotné přihlášení nedalo uživatelům žádnou možnost přenosu jejich osobních údajů do každého nového prostředku, který uživatel navštívil. To fungovalo dostatečně dobře v jediném podniku, jako je MIT, kde byl vynalezen Kerberos, nebo velké korporace, kde všechny zdroje byly interní weby. Jak se však rozšířily federované služby, jako je služba Active Directory Federation Services, soukromé informace uživatele byly odeslány na přidružené weby, které nebyly pod kontrolou podniku, který data od uživatele shromažďoval. Vzhledem k tomu, že předpisy na ochranu soukromí se nyní zpřísňují s legislativou, jako je GDPR, začaly se novější metody, jako je OpenID Connect, stávat atraktivnějšími; například MIT, původce protokolu Kerberos, nyní podporuje OpenID Connect.

E-mailová adresa

Teoreticky může jednotné přihlášení (SSO) fungovat bez odhalení identifikačních informací, jako je e-mailová adresa, spoléhající se straně (příjemce pověření), ale mnoho poskytovatelů pověření neumožňuje uživatelům konfigurovat, jaké informace se předávají příjemci pověření. Od roku 2019 přihlášení přes Google a Facebook nevyžaduje, aby uživatelé sdíleli e-mailovou adresu s příjemcem pověření. Funkce „Přihlásit se s Apple“ zavedená v systému iOS 13 umožňuje uživateli požadovat jedinečný e-mail relace pokaždé, když se uživatel přihlásí k nové službě, čímž snižuje pravděpodobnost propojení účtu příjemcem pověření.

Single Sign-On with Client CertificatesLocate this document in the navigation structure

(SAP, https://help.sap.com/doc/saphelp_nw73ehp1/7.31.19/en-US/4e/1262e31e3d2287e10000000a15822b/content.htm?no_cache=true)

Použití

AS ABAP umožňuje konfigurovat použití klientských certifikátů pro SSO, když uživatelé přistupují k systému z grafického uživatelského rozhraní SAP. Pro ověřování GUI SAP s klientskými certifikáty je kontext zabezpečení pro ověřování zpřístupněn z GSS API systému AS ABAP. Aby bylo možné povolit použití klientských certifikátů pro SSO, musí být systém AS ABAP nakonfigurován tak, aby používal SNC (Secure Network Communications, bezpečné síťové komunikace).

Integrace

Použití klientských certifikátů pro přihlášení pomocí grafického uživatelského rozhraní SAP využívá kryptografii veřejného klíče a AS ABAP Personal Security Environment (PSE) pro zjištění identity uživatele. Informace o certifikátu klienta se však používají pouze k ověřování uživatelů SAP GUI. Zabezpečení transportní vrstvy, integritu a důvěrnost přihlašovacích údajů ověřování umožňuje SNC používané na AS ABAP.

Předpoklady

Chcete-li povolit jednotné přihlašování SAP GUI s klientskými certifikáty, musí uživatelé vlastnit platné klientské certifikáty. Uživatelé grafického uživatelského rozhraní SAP mohou přijímat klientské certifikáty od zavedené infrastruktury veřejných klíčů.

Klientské počítače SAP GUI a systémy AS ABAP musí používat SAP NetWeaver Single Sign-On nebo externí produkt zabezpečení, který umožňuje vytvoření prostředí Personal Security Environment (PSE). Použití externího bezpečnostního produktu umožňuje Secure Network Communications (SNC).

Aktivity

Abyste uživatelům a systémům AS ABAP umožnili používat jednotné přihlášení s klientskými certifikáty, musíte:

  1. Připravit centrální instanci.
  2. Aktivovat SSO při přihlášení SAP.
  3. Importovat certifikáty veřejného klíče uživatele do AS ABAP.

Zákon o bankovní identitě

(Návrh zákona o bankovní identitě, https://www.epravo.cz/top/clanky/navrh-zakona-upravujici-podminky-pro-vznik-bankovni-identity-110488.html)

V čem spočívá koncept bankovní identity?

Bankovní identita bude nástrojem, který poslouží k digitálnímu ověřování totožnosti klientů bank (fyzických osob a právnických osob, resp. jejich zástupců, kteří jsou fyzickou osobou) pomocí bezpečnostních metod, které umožňuje jejich elektronické bankovnictví. Tento nástroj rovněž nabídne občanům ČR a právnickým osobám, kteří používají internetové bankovnictví, možnost připojit se k službám e-Governmentu a on-line službám soukromého sektoru. Zatímco klienti bank a stát budou moci ověřovat digitální identitu bez poplatků, poskytovatelé různých digitálních služeb budou za identifikaci svých klientů hradit bankám a pobočkám zahraničních bank poplatek za ověření. Účast bank a poboček zahraničních bank na projektu nebude povinná a bude probíhat na bázi dobrovolnosti.

Kromě toho, že navrhovaná úprava umožňuje otevření trhu se službami v oblasti elektronické identifikace, dojde i ke změně fungování tzv. národního bodu pro identifikaci a autentizaci (dále jen „NIA“) ve vztahu k bankám a pobočkám zahraničních bank.

K tomu, aby projekt mohl úspěšně fungovat, upravuje návrh zákona také přístup bank a poboček zahraničních bank do základních registrů ČR. Přístup bude omezen tak, aby banky a pobočky zahraničních bank byly schopny efektivněji zabraňovat legalizaci výnosů z trestné činnosti a financování terorismu a rovněž předcházet případům, kdy by bankovní identita mohla být zneužita.

Reference

CategorySoftware

SSO/CZ (last edited 2021-03-05 12:10:37 by EtienneRuedin)