Kerberos na webovém serveru
Z informací, které jsme si popsali v minulých dílech, můžeme dát dohromady body, které je třeba splnit pro provozování Kerberos SSO na webovém aplikačním serveru. Některé části jsme již podrobně popsali a některým se ještě budeme věnovat. Je jen malý rozdíl, jestli používáme IIS (kde jsou některé věci jednodušší, například odpadá keytab soubor) nebo jiný server. Zde budeme popisovat situaci jaká je například u Apache HTTP Server.
- pro server potřebujeme mít DNS A záznam (host), toto FQDN (adresu) bude uživatel zadávat do prohlížeče (pokud použijeme alias (CNAME), tak můžeme narazit na problém, že některé prohlížeče nepoužijí tento alias, ale navázané jméno hosta), příklad
www.firma.local - servisní účet v Active Directory, nejlépe uživatelský účet bez speciálních práv, na který navážeme službu, u účtu se nesmí měnit heslo (po vytvoření keytab souboru), příklad
firma\wwwsso - na servisní účet registrované SPN služby, které využívá zadané FQDN (registraci provedeme spolu s vytvořením keytabu), příklad
HTTP/www.firma.local - vytvořený keytab soubor pomocí příkazu
ktpass(někdy je třeba, aby se při vytváření keytabu, nacházel účet v defaultním kontejneru Users, následně jej můžeme přesunout), příklad
ktpass -out www.keytab -princ HTTP/www.firma.local@FIRMA.LOCAL -mapUser firma\wwwsso -mapOp set -pass heslo -ptype KRB5_NT_PRINCIPAL -kvno 0 -setupn -crypto All
- keytab soubor nahraný ve složce na webovém serveru a odpovídajícím způsobem provedena konfigurace serveru/aplikace
Pozn.: Vše okolo keytab souboru si vysvětlíme v příštím díle seriálu. Konfiguraci webového serveru popíšeme v dalším.
Kerberos a Single Sign-On s protokolem HTTP
V doménovém prostředí nám SSO autentizace funguje automaticky k řadě služeb, jako je třeba souborové sdílení nebo tiskové služby. V dnešní době velké množství aplikací funguje pomocí webového rozhraní. Bylo by tedy pohodlné se i k těmto webovým aplikacím přihlašovat pomocí SSO. A díky speciálnímu autentizačnímu schématu v rámci HTTP protokolu to možné je.
Webový server Internet Information Services (IIS), jako součást Windows, podporuje SSO pomocí jednoduchého nastavení. Ale podpora je i v dalších serverech, jako Apache HTTP Server nebo Apache Tomcat. V takovém případě řeší Kerberos komunikaci aplikační server a z jeho proměnných získá aplikace uživatelské jméno. Jiná možnost je využít Kerberos protokol přímo v aplikaci (třeba pomocí hotových knihoven). Stejně tak je podpora ve všech moderních webových prohlížečích, ale většinou je potřeba provést malé nastavení.
Pokud využijeme IIS na počítači zařazeném do domény, tak ten může (třeba) pomocí servisního účtu komunikovat přímo s doménovým řadič a řešit Kerberos autentizaci. To v případě Apache nelze, ani když běží na Windows serveru v doméně. Je tu ale jiná možnost a to využití keytab souboru. Pomocí této metody je možno využít Kerberos autentizaci pro různé aplikační servery, i když běží třeba na Linuxu či jiném OS.
Možnost použít Kerberos autentizaci v HTTP protokolu přinesl Microsoft v roce 2001 pomocí HTTP autentizačního schématu Negotiate. Ten byl později popsán v informačním RFC 4559 z roku 2006. Využívá GSSAPI pro zabalení Kerberos protokolu. Standardně se v HTTP provádí autentizace na začátku a tím se autentizuje session. Pro zabezpečení transportní vrstvy je vhodné použít HTTPS.
Integrated Windows Authentication (IWA)
Když chceme využít Kerberos SSO pro autentizaci na webu, tak se (v Microsoft prostředí) používá Integrated Windows Authentication (IWA), přihlášení pomocí našich Windows credentials (pomocí našeho aktuálního přihlášení do Windows). Nejde o žádný standard a ani přímo nejde o autentizační protokol, tento termín pro autentizační metodu používá IIS i Internet Explorer. Pro IWA se používají i jiná označení jako HTTP Negotiate Authentication, Windows NT Challenge/Response Authentication či pouze Windows Authentication. Nepodařilo se mi nalézt žádnou oficiální dokumentaci, která by IWA popisovala/definovala. Nevím, jestli celé IWA znamená pouze HTTP autentizační schéma Negotiate, nebo k němu patří ještě něco dalšího. Minimálně základ je popsaný v informačním dokumentu RFC 4559 - SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows.
IWA používá poskytovatele (Providers) pro různé autentizační metody, podporuje Negotiate a NTLM, od IIS 7.0 je také možnost nastavit samostatně Negotiate:Kerberos. Když na IIS zapneme IWA autentizaci, tak se standardně použije Negotiate (Kerberos a NTLM) a samostatné NTLM. Nastavení IWA v Internet Exploreru zajistí, aby odpovídal na Negotiate výzvy. Pokud IWA vypneme, tak pořád odpovídá na samostatné NTLM. Webservery jako Apache a Tomcat použijí při nastavení Kerberosu Negotiate.
HTTP Negotiate autentizace
Když chceme použít protokol Kerberos, tak se využívá metoda Negotiate. Jde o autentizační balíček, který implementuje mechanismus SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism, RFC 4178), který patří do standardizovaného GSS-API (Generic Security Service Application Program Interface, RFC 2743). Jedná se o obálku, která dovolí vyjednání/výběr vhodného protokolu. V případě Microsoftu se uvnitř Negotiate používá Kerberos v5 a NTLM, ale je možno rozšířit o další protokoly. Kerberos je upřednostněný, takže pokud má klient vše potřebné, tak využije Kerberos, pokud ne, tak se pokusí o NTLM.
Pro HTTP Negotiate (IWA) se v HTTP protokolu využívají HTTP/401 výzvy (Challenges) stejně jako pro další autentizace (třeba Basic či Digest). Popis nalezneme v navrhovaném standardu RFC 7235 - Hypertext Transfer Protocol (HTTP/1.1): Authentication. Znamená to využití stavového kódu HTTP/1.1 401 Unauthorized v HTTP hlavičce. Alespoň tento název uvádí RFC norma (RFC 2616 kapitola 10.4.2 a zmiňovaná RFC 7235), ale v praxi se často setkáme také s HTTP/1.1 401 Authorization Required.
Průběh HTTP autentizace
Komunikace mezi klientem a webovým serverem probíhá při autentizaci následovně (zaměřeno na Kerberos):
- klient posílá HTTP GET požadavek pro získání nějaké stránky, standardně se používá anonymní autentizaci (žádné autorizační údaje se neposílají)
- pokud má server nastaven přístup na danou stránku pouze po ověřené uživatele, tak nevrátí stránku (a kód 200), ale odpoví s kódem 401 a zároveň nabídne podporované autentizační metody (může tam být jedna nebo více, v příkladu je uvedeno IWA, Digest, Basic)
HTTP/1.1 401 Unauthorized WWW-Authenticate: Negotiate WWW-Authenticate: NTLM WWW-Authenticate: Digest realm="" nonce="" ... WWW-Authenticate: Basic realm=""
- klient zkouší ověřovací metody a pro první, kterou podporuje, připraví odpověď. Znovu pošle HTTP GET požadavek na stránku, ale tentokrát doplní do hlavičky autentizační údaje (dle použité metody)
Authorization: Negotiate YIIGKwYGKwYBBQUCoI...
- server ověří zaslané autentizační údaje, a pokud je vše OK, tak vrátí stavový kód 200 a požadovanou stránku. Pokud se používá vzájemná autentizace, tak server v hlavičce znovu použije
WWW-Authenticate: Negotiate, jako při nabízení autentizačních metod, ale nyní doplní svoje údaje.
WWW-Authenticate: Negotiate oYHmzsZsjbVx...
V praxi se někdy používá to, že server nevrátí stránku a kód 200, ale nejprve provede přesměrování na jinou stránku, takže klient dostane kód 302 a adresu stránky, kterou má otevřít.
Autentizace z pohledu uživatele
Pokud proběhne vše správně, tak se použije Kerberos V5, jak jsme si popisovali v dřívějších dílech. Znamená to, že dojde k SSO, uživatel nemusí nic zadávat a ani nemusí poznat, že došlo k autentizaci. Jednou z podmínek je, aby měl přímé připojení do Active Directory. A správně nastavený prohlížeč (to si popíšeme dále v článku). Pokud nesplňuje všechny podmínky, nebo něco selže, tak částečně záleží, jak je napsána webová aplikace. Ve většině případů se zobrazí modální okno Windows Security, které se ptá na jméno a heslo (případně certifikát).
V určitém procentu případů můžeme vyplnit přihlašovací údaje, provede se Kerberos autentizace s DC, a na server se odešle tiket. V tom případě dojde ke korektnímu přihlášení. Většinou se ale v tuto chvíli provede NTLM autentizace a pokud ji nemáme povolenu jako alternativu ke Kerberosu, tak přihlášení selže. Znovu se nám (třikrát po sobě) zobrazí přihlašovací dialog. Jestli vyskakující dialog bude provádět Kerberos nebo NTLM nepoznáme (jedině můžeme zachytávat komunikaci).
Obsah autentizačních dat
V klientském požadavku, který v hlavičce obsahuje řádku Authorization, se za klíčovým slovem Negotiate nachází GSS-API data kódovaná pomocí Base64. Uvnitř se nachází SPNEGO a uvnitř seznam podporovaných metod a Kerberos v5 datový objekt. V objektu je Kerberos zpráva KRB-AP-REQ a v ní Service Ticket.
Komponenty Windows pro autentizaci
V Microsoft OS zajišťuje autentizaci uživatele služba Local Security Authority (LSA). Ta volá rozhraní (bezpečnostní API) Security Support Provider Interface (SSPI), což je proprietární varianta standardního GSS-API. SSPI využívá různé poskytovatele (SSP - Security Support Provider), třeba protokol Kerberos V5 (včetně rozšíření, které umožňuje provést autentizaci pomocí certifikátu na čipové kartě) implementoval pomocí dynamicky linkované knihovny Kerberos SSP (Kerberos.dll). Webový prohlížeč (třeba Internet Explorer) také volá SSPI, to použije Negotiate SSP, které zvolí Kerberos SSP nebo NTLM SSP.
Odkazy
- IIS logging for Windows Integrated authentication
- Integrated Windows Authentication (IIS 6.0)
- HTTP-Based Cross-Platform Authentication by Using the Negotiate Protocol
- Windows Authentication Architecture
- Logon and Authentication Technologies
- Security Support Provider Interface Architecture
- Microsoft Kerberos
- Authentication in IIS
- Security Support Provider Interface (SSPI)
- RFC 4559 - SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows
- RFC 2743 - Generic Security Service Application Program Interface Version 2, Update 1
- RFC 4178 - The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism
- RFC 7235 - Hypertext Transfer Protocol (HTTP/1.1): Authentication
- RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1
Zatím zde nejsou žádné komentáře.