Analýza SASL, část čtvrtá

Tento díl se bude věnovat pokračování rozboru technologií založených na ověřování ve spolupráci více stran. Součástí bude hlavně rozbor OAUTH2 a technologií na něm založených. Dále bude uveden rozbor SAML. Rozbor technologického předchůdce OAUTH10A je v předchozím článku, který je možné najít na Analýza SASL, třetí díl.

OAUTH2

Druhá generace autentizačního mechanismu má za úkol zajistit rozšíření možností v případě delegování oprávnění. Opět přistupuje k tématu stejným způsobem, pomocí textových nebo JWT tokenů, přenášených pomocí HTTPS (HTTP protokol v SSL/TLS tunelu) jako jediné ochranné vrstvy. Jiná ochrana uživatelských údajů není pro textové tokeny a přenášené autentizační informace k dispozici. Žádost o token navíc nemusí požadovat aplikace, ale může se jednat o další autorizační doménu (delegace oprávnění). Tak je možné oprávnění předávat mezi jednotlivými federovanými doménami. Tento způsob výměny informací je standardizován, tedy je možné delegovat oprávnění na jinou doménu. Zároveň je standardizován způsob správy různých domén. To je významný provozní rozdíl oproti OAUTH1. Z hlediska bezpečnosti jsou rozdíly výrazně menší, změnou je pouze podpora JWT tokenů, které mají vestavěnou podporu pro ochranu důvěrnosti a integrity.
Na začátku se uživatel musí autentizovat a registrovat dané aplikace. Přihlašování probíhá jednoduchým způsobem, kdy uživatel zadá heslo, server uvedené heslo zpracuje a porovná s uloženými daty (uloženými např. pomocí funkce Argon2). Na obrázku je autentizační a autorizační systém spojen do jednoho. Ve všech schématech se používá pouze termín autorizační server, protože OAUTHx řeší přidělování oprávnění. Autentizace se provádí zprostředkovaně přes jiné mechanismy. Při dalších aktivitách je už nutné pouze přihlášení, na základě typu poskytnutého oprávnění systém vybírá mezi následujícími možnými metodami:
Authorization Code Grant: Uživatel pošle autentizační požadavek. Autorizační server zajistí přihlášení pomocí autentizačního serveru a následně vrátí URL a Auth Code. Uživatel uvedené požadavky předá aplikaci, která Auth Code předává autorizačnímu serveru. Po ověření získá dva tokeny, Access Token a Refresh token. Refresh token může používat pro prodloužení přístupu k datům pomocí autorizačního serveru, Access Token zasílá na systém s daty (server). Ten na základě Access Tokenu dovoluje přístup ke zvoleným údajům.
Client Credentials Grant: Uživatel pošle autentizační požadavek. Autorizační server zajistí přihlášení pomocí autentizačního serveru a následně vrátí URL a Access Token. Uživatel uvedené požadavky předá aplikaci, které se spojí s autorizačním systémem a zajistí si tak autorizaci přístupu k datům.
Device Autorization Grant: Uživatel pošle autentizační požadavek. Autorizační server zajistí přihlášení pomocí autentizačního serveru a následně vrátí URL a Device Code. Uživatel uvedené požadavky předá zařízení, které se spojí s autorizačním systémem a zajistí si tak autorizaci přístupu k datům.
Implicit Grant: Uživatel pošle autentizační požadavek. Autorizační server zajistí přihlášení pomocí autentizačního serveru a následně vrátí Access Token. Uživatel uvedené požadavky předá aplikaci, která se již dále neověřuje a tento token použije pro zajištění svého přístupu systému s daty (server). Uvedená metoda se používá jako jistá forma zjednodušeného řešení a je vhodné použít metody jiné.
Resource Owner Password Grant: Uživatel pošle autentizační požadavek. Autorizační server zajistí přihlášení pomocí autentizačního serveru a následně vrátí URL a Device Code. Uživatel uvedené požadavky předá aplikaci, které se spojí s autorizačním systémem a zajistí si tak autorizaci přístupu k datům.
Uvedené metody se liší pouze tokem zpráv a oprávněními přístupu k citlivým údajům (například heslům). Token může být v textovém formátu nebo ve formátu JWT (JSON Web Token). V textovém režimu zůstává využití kryptografie pouze na úrovni transportního kanálu. V případě JWT je možné token digitálně podepsat.
Zpracování tokenů:
Pro Access Token / Bearer Token a pro Refresh Token: V případě JWT je pro symetrický podpis použito HMAC-SHA256, pro asymetrické RSA/RSASSA-PKCS1-v1_5 nebo ECDSA. Pro šifrování obsahu je v případě JWT doporučeno použití AES-GCM. V případě textového tvaru tokenu se šifrování nepoužívá.
Pro Authorization Code: kryptografická ochrana není použita, obsah je generován pomocí bezpečného generátoru náhodnosti. Pro šifrování obsahu je doporučeno v případě JWT použití AES-GCM.

Channel Binding: Ne
Realms: Ano
Kryptoprimitiva: Výběhové (RSA), aktuální (SHA256, ECDSA)
Počet stran při autentizaci: 3 až 4
PQC/QRC: Ne
ZKP: Ne
Podpora crypt interface: Za určitých podmínek
Tokenizace: Ano
Jedinečnost: Ano
Ochrana credentials: TLS
Ochrana proti Replay: Ano
Ochrana proti Relay: Ano
Ochrana proti Hijack: Ano
Ochrana proti Forge: Ano
Podpora MFA: Ano
Ochrana integrity: TLS, pro JWT interní
Typ šifrování: TLS, pro JWT navíc interní

OAUTHBEARER

Jedná se o OAUTHBEARER → Ověřování serveru vůči OAUTH2 serveru. Využívá textový nebo JWT token (JSON Web Token). Tento mechanismus je spojený s OAuth 2.0 a poskytuje oprávnění díky využití tzv. Bearer Tokenu, jinak Access Tokenu. Uvedený token je jedinečný identifikátor a je předložen klientem jako důkaz pro ověření přístupových práv. Token je přenášen pomocí HTTPS, protože neobsahuje žádnou vnitřní ochranu proti odposlechu nebo zneužití. Stejně jako OAUTH2 tokeny může být ve formátu prostého textu, případně JWT. Vazby na OAUTH2 je možné shrnout jako:
- OAUTHBEARER byl navržen pro práci s přístupovými tokeny (Access Tokens) vygenerovanými v rámci protokolu OAuth 2.0.
- Po ověření je možné přes OAuth 2.0 získat Bearer Token pomocí různých grant typů (Authorization Code Grant, Client Credentials Grant, Device Authorization Grant, Implicit Grant nebo Resource Owner Password Grant). Jakmile je token k dispozici, je použit pro ověření proti serveru poskytujícímu data.

Channel Binding: Ne
Realms: Ano
Kryptoprimitiva: Výběhové (RSA), aktuální (SHA256, ECDSA)
Počet stran při autentizaci: 3
PQC/QRC: Ne
ZKP: Ne
Podpora crypt interface: Za určitých podmínek
Tokenizace: Ano
Jedinečnost: Ano
Ochrana credentials: TLS
Ochrana proti Replay: Ano
Ochrana proti Relay: Ano
Ochrana proti Hijack: Ano
Ochrana proti Forge: Ano
Podpora MFA: Ano
Ochrana integrity: TLS, pro JWT interní
Typ šifrování: TLS, pro JWT navíc interní

XOAUTH2

Stejně jako XOAUTH je rozšířením OAUTH technologie pro poštovní servery, protokol XOAUTH2 je specifickým rozšířením OAUTH2. Jedná se o variantu protokolu, vlastní komunikace zůstává prakticky nezměněna. Nahrubo lze technologický vývoj popsat jako OAUTH → OAUTH2 → XOAUTH2. I v tomto případě je protokol XOAUTH2 použit pro ověřování u poštovních serverů, tedy pro protokoly SMTP, IMAP4 a POP3. V tomto případě je možné brát aplikační a resource server jako by byly spojeny do jednoho systému.

Channel Binding: Ne
Realms: Ano
Kryptoprimitiva: Výběhové (RSA), aktuální (SHA256, ECDSA)
Počet stran při autentizaci: 4
PQC/QRC: Ne
ZKP: Ne
Podpora crypt interface: Za určitých podmínek
Tokenizace: Ano
Jedinečnost: Ano
Ochrana credentials: TLS
Ochrana proti Replay: Ano
Ochrana proti Relay: Ano
Ochrana proti Hijack: Ano
Ochrana proti Forge: Ano
Podpora MFA: Ano
Ochrana integrity: TLS, pro JWT interní
Typ šifrování: TLS, pro JWT navíc interní

OPENID20

OpenID je rozšířením autorizačního schématu OAUTH2 o metodu ověření identity a poskytuje službu federovaného autorizačního systému. Podpora bezpečné výměny hesel je opět zoufale slabá. V rámci ověřování podporuje přímo MFA a rate/limit jako formu ochrany před útoky na hesla. Na rozdíl od OAUTH2 již nepodporuje textové tokeny, ale pouze JWT tokeny.
Na začátku se uživatel musí autentizovat a registrovat dané aplikace. Přihlašování probíhá jednoduchým způsobem, kdy uživatel je po žádosti o ověření přesměrován na autentizační server (IDP - Identity Provider), kde zadá heslo, případně využije MFA. Heslo se opět přenáší jako otevřený text, nikoliv chráněným způsobem. IDP Server uvedené heslo a případné další faktory zpracuje a porovná s uloženými daty (hesla uložená např. pomocí funkce Argon2). Následně odešle informace o identitě uživatele. Na rozdíl od OAUTH2 používá už jenom Access Token a Refresh Token, což omezuje možnosti výměny informací na tři základní metody – Authorization Code flow, Hybrid Flow a Implicit flow.
Authorization Code Flow: Po přihlášení je odeslán autorizační kód a stav na autorizační server. Ten vytvoří ID Token, Access Token a Refresh token, které zašle uživateli. Ten poskytuje Access token aplikaci, Refresh token používá pro žádost o nový Access Token. ID token používá k ověření identity žadatele. Tento přístup je podobný Authorization Code Grant a jedná se o preferovanou variantu.
Hybrid Flow je podobný Authorization Code Flow. Na rozdíl od předchozího ale dochází k okamžitému získání Access Tokenu na základě autorizačního kódu, není nutné prokazovat vlastnictví autorizačního kódu. Na jednu stranu to zjednodušuje provoz, na druhou stranu také omezuje možnosti řízení přístupových oprávnění. Z určitého pohledu to je možné vnímat jako bezpečnostní slabinu.
Implicit Flow: Je podobný Implicit Grant. V současnosti není doporučovaný. Při úvodním přihlášení nepoužívá autorizační kód pro získání Access Tokenu, proto zde hrozí vyšší riziko zneužití.
Stejně jako v případě OAUTH2 a OAUTHBEARER mohou být JWT tokeny a jejich obsah chráněny pomocí následujících algoritmů:
Pro Access Token a pro Refresh Token: V případě JWT je pro symetrický podpis použito HMAC-SHA256, pro asymetrické RSA/RSASSA-PKCS1-v1_5 nebo ECDSA. Pro šifrování obsahu je v případě JWT doporučeno použití AES-GCM.
Pro Authorization Code: kryptografická ochrana není použita, obsah je generován pomocí bezpečného generátoru náhodnosti. Pro šifrování obsahu je doporučeno v případě JWT použití AES-GCM.

Channel Binding: Ne
Realms: Ano
Kryptoprimitiva: Výběhové (RSA), aktuální (SHA256, ECDSA)
Počet stran při autentizaci: 3 až 4
PQC/QRC: Ne
ZKP: Ne
Podpora crypt interface: Za určitých podmínek
Tokenizace: Ano
Jedinečnost: Ano
Ochrana credentials: TLS
Ochrana proti Replay: Ano
Ochrana proti Relay: Ano
Ochrana proti Hijack: Ano
Ochrana proti Forge: Ano
Podpora MFA: Ano
Ochrana integrity: TLS, pro JWT interní
Typ šifrování: TLS, pro JWT navíc interní

SAML

Jedná se o otevřený standard zastřešovaný OASIS (Organization for the Advancement of Structured Information Standards). Vlastní SAML jazyk vznikl z AuthXML, ITMP (Information Technology Markup Language), S2ML (Security Services Markup Language), X-TASS (XML Trust Assertion Service Specification). Z hlediska realizace se jedná o XML schéma, umožňující definovat a prokázat několik základních stavů. Je to stav autentizace, autorizace nebo konkrétního atributu. V rámci tohoto protokolu se vyměňují informace na různých úrovních. Pro každou z těchto úrovní je uvedeno pouze pět příkladů. Tento materiál nemá za cíl poskytnout vyčerpávající popis SAML standardu, pouze představu jak pracuje.
Assertions: jedná se o několik typů dokumentů, které obsahují informace důležité pro přihlašování. Jedná se o informace o uživateli a informace vztažené k autentizaci. Většina uvedených informací má omezenou dobu platnosti (Assertion Expiry), omezené využití pro konkrétní Service Providery (Audience restriction) a musí být vždy digitálně podepsány. Vlastní assertion mohou být např. Authentication Assertion (kdy a jak byl uživatel ověřen), Attribute Assertion (parametry uživatele, tedy jméno, skupina, role), Delegation Assertions (delegování oprávnění na jiný subjekt), Subject Confirmation Assertion (způsob ověření uživatele), Session Assertion (jaké jsou parametry a doba trvání relace) a další.
Protocols: jedná se o definici přenosu assertions. Příkladem mohou být Authentication Request Protocol (Service Provider žádá Identity Providera o autentizaci assertions), Artifact Resolution Protocol (umožňuje získání SAML aserce na základě artefaktu), Name Identifier Management Protocol (změna ID uživatele mezi Service Providerem a Identity Providerem), Name Identifier Mapping Protocol (výměna ID uživatele mezi Service Providerem a Identity Providerem), Single Logout Protocol (umožňuje odhlášení ze služeb) a další.
Bindings: definuji požadavky a způsob přenosu. Příkladem HTTP Artifact Binding (používá HTTP pro přenost artefaktů, artefakty obsahují vyjednávání a přenost assertions), HTTP Redirect Binding (používá HTTP přesměrování s parametry v URL), HTTP POST Binding (SAML aserce se posílá jako formulářový POST), PAOS Binding (Reverzní SOAP přes HTTP pro komunikaci mezi klientem a Identity Providerem), SMTP Binding (využívá SMTP pro výměnu zpráv skrze e-mail) a mnoho dalšího.
Profiles: definuje použití assertions za účelem splnění požadavků autentizace a autorizace. Pro ukázku tu jsou Attribute Query Profile (umožňuje SP požádat IdP o další atributy uživatele), Enhanced Client or Proxy (ECP) Profile (umožňuje autentizaci klientem namísto prohlížeče, Mobile SSO Profile (optimalizované pro přihlašování z mobilních zařízení), Single Logout Profile (umožňuje odhlášení uživatele na všech připojených službách), Web Browser SSO Profile (umožňuje uživateli jednou se přihlásit a pak přistupovat k více službám) a spousta dalších.
Security: Definuje různé typy zabezpečení assertions, protokolů a bindings. Jednak se může jednat o ochranu na transportní úrovni vrstva SSL/TLS. Na úrovni zpráv se používá XML encryption, která používá AES-CBC nebo AES-GCM se 128b/256b klíči. Zprávy je možné také digitálně podepsat, k tomu se používá podpis pomocí algoritmu RSA (RSA+SHA256) nebo ECDSA (ECDSA NIST P-256+SHA256).
Vlastní systém používá dvě hlavní metody pro řízení přidělování oprávnění, metodu vynucenou poskytovatelem služby (např. aplikací nebo poskytovatelem služby) a metodu vynucenou poskytovatelem identity.

SP-Initiated SSO (Service Provider Initiated)
- Uživatel požádá o přístup k aplikaci nebo službě (Service Provider)
- Service Provider přesměruje uživatele na Identity Providera s žádostí o autentizaci (SAML AuthnRequest)
- Identity Provider autentizuje uživatele (heslo, MFA, certifikát apod.)
- Identity Provider vytvoří SAML Assertion a přesměruje uživatele zpět na Service Providera
- Service Provider ověří SAML Assertion a přihlásí uživatele
- Aplikace požádá autorizační systém o přístup k datům (OAuth, policy rules)
- Autorizační systém ověří přístup a umožní aplikaci získat data od poskytovatele

IdP-Initiated SSO (Identity Provider Initiated)
- Uživatel se přihlásí k Identity Providerovi přímo
- Identity Provider vytvoří SAML Assertion a přesměruje uživatele na Service Providera
- Service Provider ověří SAML Assertion a přihlásí uživatele
- Aplikace požádá autorizační systém o přístup k datům
- Autorizační systém ověří přístup a umožní aplikaci získat data

SAML dovoluje využít různé typy autentizačních mechanismů. Samozřejmě podporuje metodu PLAIN/LOGIN, která je chráněna pouze pomocí TLS. Dále ověření pomocí digitálních certifikátů RSA nebo ECDSA, Kerberos, smart karty a FIDO2/WebAuthn, případně externí identity poskytované např. pomocí OAuth2, OpenID Connect a další. Mimo vlastní ověření může dojít k poskytnutí ověřovacích informací díky SSO, kde se pro přenost assertion údajů používá jak transportní šifrování, tak šifrování vlastních přenášených assertion (více o šifrování assertion je ve vlastnosti security).

Channel Binding: Ne
Realms: Ano
Kryptoprimitiva: Výběhové (RSA), aktuální (SHA256, ECDSA)
Počet stran při autentizaci: 3 až 5
PQC/QRC: Ne
ZKP: Ne
Podpora crypt interface: Za určitých podmínek
Tokenizace: Ano
Jedinečnost: Ano
Ochrana credentials: TLS
Ochrana proti Replay: Ano
Ochrana proti Relay: Ano
Ochrana proti Hijack: Ano
Ochrana proti Forge: Ano
Podpora MFA: Ano
Ochrana integrity: TLS, pro JWT interní
Typ šifrování: TLS, pro JWT navíc interní

Závěr

Tento díl dokončil přehled používaných mechanismů. Na základě poskytnutých informací je zřejmé, že některé mechanismy není vhodné používat, u jiných je nutné si dát extrémní pozor na nastavení a konfiguraci jak prostředí, tak použitých ochranných vrstev. Přes všechny ochrany je nejčastější metodou pro ověření uživatelů zasílání těchto informací v plaintextu (metoda PLAIN nebo LOGIN), kde jedinou ochranou je TLS vrstva. V takovém případě je ale pro odpovídající ochranu vyžadováno mTLS (Mutual TLS, tedy oboustranné ověření certifikátů v rámci TLS). V jiném případě jakákoliv SSL inspekce dovolí útočníkovi přistupovat k autentizačním údajům. Bohužel jakákoliv forma MFA proti uvedeným typům útoků nebrání.
V dalším díle SASL dil pátý budou rozebírány používané knihovny a bude uvedena kritika a hodnocení jednotlivých schémat, upřesněna rizika a doporučeno jak se uvedeným problémům bránit.

Autor článku:

Jan Dušátko

Jan Dušátko se počítačům a počítačové bezpečnosti věnuje již skoro čtvrt století. V oblasti kryptografie spolupracoval s předními odborníky např. s Vlastimilem Klímou, či Tomášem Rosou. V tuto chvíli pracuje jako bezpečnostní konzultant, jeho hlavní náplní jsou témata související s kryptografií, bezpečností, e-mailovou komunikací a linuxovými systémy.