Kerberos protokol a Single sign-on

Single sign-on (SSO) je metoda, která nám dovolí použít jedno přihlášení do více aplikací (pokud se ověřují u stejného zdroje, není nutné znovu vyplňovat stejné přihlašovací údaje). Ve Windows to většinou znamená, že se při přihlášení do počítače autentizujeme vůči Active Directory (doméně). Když je následně potřeba autentizace do dalšího systému, který využívá také účty v doméně (nebo používá mapování svých účtů na doménové), využijí se data, která již máme v systému, pro ověření a přihlášení do další aplikace (aniž by bylo třeba něco zadat).

Ve Windows se používá Integrated Windows Authentication (IWA), která používá protokoly SPNEGO, Kerberos a NTLMSSP. IWA je primárně spojován s webovými prohlížeči a dovolí nám využití SSO do webové aplikace (je třeba podpora v prohlížeči a na webovém serveru). SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism, RFC 2478) vyjednává, zda se použije Kerberos (verze 5, RFC 4120, což je v MS prostředí nástupce NTLM) nebo NTMLSSP (NT LAN Manager - NTLMv1 nebo bezpečnější NTLMv2, ale dnes oboje nedoporučované), případně jiný protokol. Kerberos je bezpečný protokol, který využívá metodu klíčů (ticketů) a jemu se budeme dále věnovat.

Kerberos a Single sign-on - jak funguje

Protokol Kerberos je síťový autentizační protokol, který používá silnou kryptografii pro bezpečné ověření klienta a serveru přes nezabezpečenou síť. Funguje na principu toho, že se klient neověřuje vůči serveru, kde chce získat nějakou službu, ale vůči prostředníkovi KDC. Centrální autentizační prvek zvyšuje bezpečnost a může poskytovat služby více aplikacím. Na druhou stranu se může jednat o single point of failure (takže musíme zajistit redundanci) a jeho ovládnutí ovlivní více systémů (takže jej musíme dobře zabezpečit na fyzické i síťové úrovni). KDC zná šifrovací klíče všech klientů (klienti, servery, aplikace) a ti se ověřují vůči němu, pro vzájemnou komunikaci mezi klienty jsou od KDC poskytnuty pouze nezbytné údaje.

Stručný popis Kerberos protokolu ve Windows:

• autentizace uživatele
  • při první přihlášení uživatel zadá své přihlašovací údaje (budeme uvažovat jméno a heslo)
  • klient provede jednosměrnou hashovací funkci nad heslem a získat secret key
  • klient odešle žádost na Authentication Server (AS) což je součást Key Distribution Center (KDC), ta obsahuje uživatelské údaje v otevřeném textu (neposílá heslo ani secret key)
• získání Ticket-Granting Ticket
  • AS ověří, jestli uživatel existuje a vytvoří si jeho secret key (heslo má u uživatele v AD)
  • jako odpověď odešle klientovi session key (klíč pro budoucí šifrování komunikace mezi KDC a klientem), který je zašifrovaný pomocí secret key klienta
  • a také odešle unikátní klíč Ticket-Granting Ticket (TGT), který zašifruje svým klíčem (KDC secret key)
  • tím, že si klient dokáže rozšifrovat session key se potvrdilo, že je to opravdu on (aniž by bylo třeba odesílat heslo)
  • TGT dále slouží k identifikaci uživatele, obsahuje jméno klienta, adresu, dobu platnosti, session key
  • klient nedokáže TGT rozšifrovat (to může pouze KDC)
  • TGT má omezenou životnost (default 10 hodin), ale může probíhat automatická reautentizace, při každém přihlášení se vytváří nový TGT
  • TGT i session key se na klientovi ukládají do ticket cache
• získání Service Ticket
  • když se nyní chceme přihlásit k nějaké službě v síti, tak aplikace na klientovi použije TGT a požádá KDC o service ticket
  • klient posílá žádost o service ticket na Ticket Granting Service (TGS), další součást KDC, pomocí dvou zpráv
  • jedna zpráva obsahuje klientův TGT a ID služby - Service Principal Name (SPN), TGT je již šifrovaný pomocí KDC secret key (tak jsme jej získali)
  • druhá zpráva je authenticator, skládá se z uživatelovy identifikace a časové známky, je šifrovaný pomocí session key (klient a KDC)
  • dohromady tyto zprávy tvoří credentials uživatele, které jsou platné pouze po dobu logon session, není tedy nutné se znovu ptát uživatele na přihlášení
  • TGS rozšifruje klientův TGT, z něj se dozví session key a pomocí něj rozšifruje druhou zprávu, tím ověřil klienta
  • pokud jsou údaje v pořádku, tak TGS odešle odpověď, která obsahuje část klienta a serveru
  • v klientské části je session key pro komunikaci klienta a serveru (kde je služba), šifrovaný pomocí session key (klient a KDC)
  • v serverové části je service ticket - identifikace uživatele, jeho adresa, doba platnosti a session key (klient a server), šifrováno pomocí secret key služby
  • serverovou část nemůže klient dešifrovat a ani pozměnit
• ověření u služby (serveru)
  • service ticket se potom použije k autentizaci klienta na serveru
  • na server (kam se chceme pomocí SSO přihlásit) se posílá service ticket, stále šifrovaný pomocí secret key služby
  • a také authenticator, který se skládá z uživatelovy identifikace a časové známky, je šifrovaný pomocí session key (klient a server)
• server rozšifruje service ticket, z něho získá session key a pomocí něj rozšifruje authenticator
• tak server získá důvěryhodné údaje o klientovi, když je vše v pořádku, tak odešle zašifrované potvrzení
• potvrzení obsahuje časovou známku od klienta + 1, je zašifrované pomocí session key (klient a server)
• navázání session
  • klient rozšifruje potvrzení a porovná časovou známku, pokud je vše v pořádku, došlo k úspěšné autentizaci
  • ověřil se tedy nejen klient na serveru, ale i server vůči klientovi

Pozn.: Obecně jsme používali dva typy klíčů. Session key pro šifrování komunikace mezi dvěma účastníky, znají jej obě strany. Secret key zná KDC a jedna strana, ověřuje autentičnost.

Zajímavě napsaný popis Kerberosu naleznete na stránkách MS Microsoft Kerberos, bohužel v něm jsou špatně vidět jednotlivé vazby.

Zjednodušený popis SSO k webové aplikaci

Zkusíme si celý proces popsat z praktického a zjednodušeného pohledu. Na začátku se přihlásíme do Windows (dojde k ověření vůči AD a získáme TGT), nyní pomocí webového prohlížeče otevřeme nějakou stránku (budeme označovat jako službu), která podporuje SSO. Prohlížeč získá (pomocí funkcí OS) z AD (pomocí údajů svých a SPN služby - typ a adresa) service ticket (který obsahuje údaje o uživateli), který je zašifrovaný pomocí klíče služby (takže s ním klient nic nenadělá). Ten odešle aplikaci, která se z něj dozví kdo je ověřený uživatel a nastaví jej jako přihlášeného. Klíč pro zašifrování service ticketu zná pouze služba a AD, takže není možné podvržení.

Z toho plyne, že server při ověřování vůbec nemusí komunikovat s AD, stačí mu, že vlastní svůj klíč pro dešifrování. S AD komunikuje pouze klient, který se chce autentizovat na server. Získá zašifrované údaje, které server rozšifruje a tím se mu potvrdila autentičnost obsažených údajů. Celá bezpečnost tkví v šifrování, vždy se používá klíč, aby zprávu rozšifrovala pouze správná strana a pro autentizaci se používají dočasné tickety.

Související články:

LDAP a Active Directory

• Adresářové služby a LDAP [14.09.2007 14:11]
• Autentizace v LDAPu (AD) [28.10.2007 14:32]
• Jak na LDAP a LDAPS v PHP pod Windows [02.11.2007 16:52]
• Autentizace uživatele vůči AD v PHP [06.11.2007 18:18]
• Rozšíření Active Directory Users And Computers o editaci employeeID [03.12.2007 14:25]
• Active Directory komponenty - domain, tree, forest, site [08.02.2008 19:01]
• Převod domény z Windows Server 2003 na Windows Server 2008 R2 [31.03.2010 08:47]
• Kerberos protokol a Single sign-on [15.09.2010 18:33] právě čtete
• Kerberos SSO - nastavení Internet Exploreru a Firefoxu [16.09.2010 15:53]
• Kerberos SSO v PHP aplikaci s Apachem na Linuxu [22.09.2010 17:58]
• Active Directory - fotografie u uživatelů nejen pro Outlook 2010 [20.10.2010 09:55]
• Auditování AD DS objektů ve Windows Server 2008 [26.03.2011 19:23]
• Active Directory Recycle Bin [31.03.2011 15:48]
• Exchange Server, Outlook a certifikáty v GALu [27.12.2011 14:48]